Icinga configs

From Lsdf
Revision as of 16:03, 16 October 2015 by Jvw (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

This page is a copy from the GridKa Wiki

SCC Icinga Website

Link: https://icinga.scc.kit.edu/icinga-web/


In der linken Spalte ganz oben unter All User die Cronks Tape_Overview und Tape_NOT_OK auswählen.

Tape_Overview

Dieser Cronk zeigt alle Icinga Hosts für den Bereich Tape, d.h. TSM, HPSS, Druva. Icinga Hosts können Hardware-Server oder logische Namen sein. Sie sind in verschiedene Bereiche unterteilt, und zwar: Tape_Hosts, TSM_Server, Tape_Libs, Tape_Storage uns Tape_Projects. Zu jedem Bereich gibt es links unter All User einen eigenen Cronk. Für jeden Icinga Host wird ein Ping ausgeführt. Die IP Adresse des Ping Checks kann über Kästchen mit Pfeil, Details angezeigt werden. Durch Klicken auf den Icinga Host wird ein neuer Tap geöffnet, welcher alle Checks für diesen anzeigt.

Tape_NOT_OK

Dieser Cronk zeigt alle Icinga Checks des Cronks Tape_Overview, deren Status nicht OK ist, d.h. Status ist WARNING, CRITICAL oder UNKNOWN. Listet also alle Icinga Checks für TSM und HPSS, die nicht OK sind. 

• In Spalte „Duration“ wird angezeigt wieviel Wochen(w), Tage(d) oder Stunden(h) der Check bereits auf Warning, Critical oder Unknown steht.
• In Spalte „Info“ erscheint „Worker Symbol“ (Schraubenzieher und –schlüssel) und in Spalte „Comment“ ein Kommentar, wenn Administrator ein Acknowledge für diesen Check gemacht hat, 
  d.h. keine Erinnerungsmails bis sich der Status ändert oder bis zu angegebenem Datum
• In Spalte „Info“ erscheint Lautsprecher mit rotem Balken, wenn Administrator Notifications für diesen Check abgeschaltet hat, 
  d.h. keine Erinnerungsmails und keine Mails bei Statusänderungen bis Administrator Notifications wieder einschaltet
• Achtung: jeweiliges Kommando (Ok setzen, Acknowledge, Mails abstellen) wird immer für alle ausgewählten Probleme ausgeführt
• Um ein Check/Problem auf Ok zu setzen, wird Check ganz links ausgewählt (Haken), dann oben Commands: „Process service check result“, 
  return code=OK, output=Kommentar eingeben, perfdata nicht benötigt
• Bei Trap Checks Historie betrachten (evtl. mehrere Traps/Probleme seit letztem OK) 
• Um Acknowledge zu einem Problem zu machen, wird Problem ganz links ausgewählt (Haken), dann oben Commands: „Acknowledge service check problem with expiration time“, 
  Enddatum für Acknowledge angeben (Wann möchte ich wieder erinnert werden, falls Problem noch besteht?) und Kommentar
• Um Mailing zu einem Problem abzustellen, wird Problem ganz links ausgewählt (Haken), dann oben Commands: „Disable notifications for this service“

Empfehlung Arbeitsweise mit Icinga Cronk Tape_NOT_OK: 

• Check/Problem sollte nicht länger als 1 Tag (nach Wochenende 2-3 Tage) auf Critical stehen, 
  bis ein Administrator es auf Ok setzt (Trap Check) oder ein Acknowledge mit Zeitangabe macht (Program Check) 
• Check/Problem sollte nicht länger als 3 Tage (nach Wochenende 4-5 Tage) auf Warning stehen, 
  bis ein Administrator es auf Ok setzt (Trap Check) oder ein Acknowledge mit Zeitangabe macht (Program Check)
• Falls Check/Problem nicht mehr relevant ist oder Status bzw. Schwellen geändert werden müssen, bitte Karin informieren
• Eventuell weitere Informationen von StorSentry, TapeMon, TSM Manager, HPSS holen

Vorteile:
• Die anderen Administratoren können sofort sehen, dass das Problem schon in Bearbeitung ist
• Reduzierung von Erinnerungsmails


Icinga Checks

Grundsätzlich gibt es zwei verschiedene Arten von Icinga Checks, die im Tape Umfeld durch den Namen unterschieden werden, und zwar:

Trap Check

Alle Icinga Checks, die von Traps beliefert werden, enthalten das Wort Trap im Namen. Jeder Trap mit Status Warning oder Critical erzeugt eine Icinga-Mail, weil es sich um einen neuen Fehler handeln kann (keine Erinnerungsmails). Nach der Lösung bzw. Kenntnisnahme eines Problems geht der Service nicht automatisch wieder auf Ok, sondern muss vom zuständigen Administrator auf Ok gesetzt werden (Commands->Process service check result).

Program Check

Alle Icinga Services ohne das Wort Trap im Namen erhalten regelmäßig Check Ergebnisse und erzeugen nur bei Statusänderungen eine Icinga-Mail. Wenn sich der Status nicht ändert, bleibt das gleiche Problem bestehen und es wird keine neue Mail verschickt (sondern nur Erinnerungsmails, standardmäßig alle 24 h). Nach der Lösung eines Problems geht der Service automatisch wieder auf Ok (bei nächster Ausführung des Check-Programms).


Icinga Mails abstellen

Um das Icinga Mailing für einen Check zeitweise abzustellen gibt es drei Möglichkeiten:

Downtime

Während einer Wartung oder der längerfristigen Bearbeitung eines Problems, bei der zu erwarten ist, dass der Icinga Status zwischen Ok, Warning und Critical wechselt, sollte das Icinga Mailing komplett abgeschaltet werden, indem eine „fixed downtime“ gesetzt wird. Die „fixed downtime“ kann für spezielle Icinga Hosts oder einzelne Icinga Checks gesetzt werden. Dabei wird die Zeitspanne der downtime festgelegt und ein Kommentar eingegeben. (Web-Symbol für Downtime: Halbmond in Spalte Info auf Webseite.) Bei einer Downtime mit Zeitangabe wird das Mailing nach Ablauf automatisch wieder eingeschaltet. Falls die Wartung/Problem früher beendet/gelöst wird, kann die Downtime gelöscht werden. (links: Status->Downtimes, rechts: downtime auswählen, dann Commands: delete service downtime)

Acknowledge

Bei der Bearbeitung eines Problems, bei dem zu erwarten ist, dass der Icinga Status nicht wechselt oder wenn das Problem mit diesem Status keine Aktion erfordert, sollte ein Acknowledge mit Zeitspanne und Kommentar gesetzt werden, um die Kollegen darüber zu informieren. (Web-Symbol für Acknowledge: Schraubenzieher&-schlüssel in Spalte Info auf Webseite.) Durch das Acknowledge werden die Erinnerungsmails abgeschaltet, aber bei Statusänderungen werden Mails verschickt, d.h. es gibt eine Mail wenn der Status von Warning auf Critical wechselt. Sobald der Check wieder Ok ist, den Status wechselt oder die Zeitspanne abgelaufen ist, verschwinden Kommentar und Acknowledge.

Disable Notifications

Falls ein Check momentan nicht relevant ist, aber erwartet wird, dass er in nächster Zeit wieder wichtig wird, kann das Mailing komplett abgeschaltet werden (Commands -> disable notifications for this service). Wenn der Check wieder aktiviert werden soll, muss das Mailing für diesen Check wieder eingeschaltet werden (Commands -> enable notifications for this service).


Icinga Server Checks (Program Checks)

Icinga Check Filesystems

Prüft den Grad der Auslastung der lokalen Filesysteme. Bei Warning/Critical bitte ermitteln welche Dateien bzw. Verzeichnisse den meisten Plattenplatz belegen und Maßnahmen ergreifen. 

Einloggen auf dem betroffenen Rechner
df -h        => report file system disk space usage
du -sh *     => summarize disk usage of each file/directory below

Im config file (z.B. /root/icinga.config) können Prozentwerte für freien Plattenplatz für einzelne oder mehrere Filesysteme angegeben werden.
Falls nichts angegeben wird, gibt es ein Warning ab 20% freien Platz (80% Auslastung) und Critical ab 10% freien Platz (90% Auslastung).

Icinga Check Processes

Prüft, ob wichtige Prozesse auf dem Server laufen.
Im config file (z.B. /root/icinga.config) können die Namen der Linux-Prozesse angegeben werden, die auf dem Server laufen sollen (Abfrage: ps –ef | grep prozessname).


Monitoring Database mss

If Check DB_mss is Warning/Critical start (restart) tape repository scripts for SCC-TapeMon as root. 

No new entries in table DCA, login on ERMM machine (a01-013-114):  
su -
cd /ermm/scripts
nohup /ermm/scripts/getErmmEventTapeRepository.pl &
  
Afterwards or no new entries in table tsslog, login on taperepository machine (scc-taperepository.scc.kit.edu): 
find the running process and kill it: 
ps -ef | grep getTSS
       root     16303 15436  0 14:06 pts/1    00:00:00 /usr/bin/perl /TapeMonitoring/Scripts/getTSSLog.pl
kill -9 process_id
 
Start getTSSLog:
cd /TapeMonitoring/Scripts/
nohup /TapeMonitoring/Scripts/getTSSLog.pl &


Monitoring StorSentry

The host storsentry-test.ka.fzk.de is monitored via Icinga. Three Icinga services are implemented according to the Icinga host storsentry-test. If one service turns to WARNING or CRITICAL please act as described below.

The StorSentry Master (main service) and StorSentry Processor (GUI) are installed at host storsentry-test.ka.fzk.de. They are monitored via Icinga Service Processes for Icinga Host storsentry-test.
The StorSentry Agents are the most important services. If they are down, data of mounts will be lost. The StorSentry Master is mandatory for the StorSentry Agents.
At the moment one StorSentry Agent must be runnning on host storsentry-test.ka.fzk.de to collect the logs from CN and GridKa drives. This agent is monitored via Icinga Service Processes for Icinga Host storsentry-test.
Another StorSentry Agent must be runnning on host scc-tsm-s01.scc.kit.edu to collect the logs from CS drives. This agent is monitored via Icinga Service Processes for Icinga Host scc-tsm-s01.

Icinga Check Processes for storsentry-test / scc-tsm-s01

ssh root@storsentry-test.ka.fzk.de

system processes:
sendmail NOT RUNNING  => /etc/init.d/sendmail start
ntpd     NOT RUNNING  => /etc/init.d/ntpd start

storsentry processes:
StorSentry-master NOT RUNNING => /etc/init.d/storsentry-master start

java -XMs256m     NOT RUNNING => 1. /etc/init.d/storsentry-master start
                              => 2. /etc/init.d/storsentry-agent start
StorSentry-proc   NOT RUNNING => /etc/init.d/storsentry-processor start
mysld_safe        NOT RUNNING => /etc/init.d/storsentry-processor start
user=mysql        NOT RUNNING => /etc/init.d/storsentry-processor start

ssh root@scc-tsm-s01.scc.kit.edu

storsentry processes:
java -XMs256m     NOT RUNNING => 1. check if StorSentry Master is running on storsentry-test.ka.fzk.de,  
                                    start there if necessary
                                 2. /opt/histor/storsentry/agent/bin/agent.sh start

Icinga Check DB_storsentry

Monitors the last entry in database storsentry, table stt_mount and belongs to Icinga Host storsentry-test. Every mount of any tape library should generate an entry in database storsentry, table stt_mount. 

1. check if Icinga Services Processes and Filesystems are ok (Icinga host storsentry-test)
2. check if an SCSI issue occured
Retrieved from "https://wiki.scc.kit.edu/lsdf/index.php?title=Icinga_configs&oldid=3182"