Posts mit dem Label monitoring werden angezeigt. Alle Posts anzeigen
Posts mit dem Label monitoring werden angezeigt. Alle Posts anzeigen

Donnerstag, 17. März 2016

Einfaches Monitoring mit Glances


Hier ein kleines aber sehr interessantes Monitoring Programm: Glances

Eine ausgewachsene Monitoring Lösung war mir zu komplex, und ein bisschen mehr als "htop" sollte es schon sein. Diese Lücke füllt Glances. Man kann es als Daemon laufen lassen, oder natürlich unkompliziert per screen in den Hintergrund verbannen.

Auf einem Blick sieht man die CPU Auslastung, Datendurchsatz der Netzwerkschnittstelle, Datendurchsatz der Festplatten sowie Mountpoints samt Belegung.

Die Installation ist denkbar einfach:
apt-get install glances

Anschliessend direkt starten mit:
glances

Wenn man es als Dienst laufen lassen möchte, muss man die Datei
/etc/default/glances
bearbeiten.

Donnerstag, 10. März 2016

Logmanagement mit Graylog

Jeder Admin kennt das: von Server zu Server hangeln um die Logdateien zusammenzusetzen und den Zusammenhang zu verstehen. Oder wieviele Ereignisse von Typ X in welchem Zeitraum aufgetreten sind.

Aktuell gibt es 3 bekannte LogManagementsysteme: Splunk - closed source, sehr kostspielig; ELK - OpenSource Software, bestehend aus ElasticSearch, Logstash, Kibana und Graylog - OpenSource, mein Favorit, da hier wieder alles aus einem Guss kommt (mehr oder weniger).
Man kann jetzt den guten alten Weg gehen und sich einen (r)syslogserver aufsetzen und alle Logs dahin schicken lassen. Um diese dann zu analysieren oder auszuwerten muss man etwas grep/awk Akrobatik zeigen um da etwas gescheites heraus zu bekommen, vor allem dann, wenn man auch Firewall-Logs bekommt.

Genau hier setzt Graylog an. Man erstellt einen Input, welcher aus dem Port/TCP/UDP und aus der Art (Syslog, KAFKA, GELF, etc) besteht, fertig. Nun kann Graylog auf dem Port Daten empfangen, diese sollten idealerweise im RFC 5424 Format ankommen. Da man das Format nicht immer bestimmen kann (Bsp: Firewalls) oder Graylog das Format nicht gut umsetzen kann, kann man ankommende Nachrichten noch zerstückeln und Datenfelder zuordnen. Jedoch kann man pro Input nur eine Art von Syslog nutzen, deswegen sollte man auch mehrere Streams erstellen und sein Syslog anpassen. So sollte man mail und auth jeweils in einen anderen Input zukommen lassen um die Daten auch besser analysieren zu können. Graylog hat dafür eine gute einfache Query-Engine.

Mit Graylog kann man sich jetzt schön schnelle Statistiken anzeigen lassen, bspw möchte man sich die SSH Logins der letzen X Stunden anzeigen lassen oder wissen, welche IP von welcher IP am meisten "besucht" wird, etc. Desweiteren kann Graylog auch die Daten analysieren. Wenn Schwellenwerte erreicht werden, kann es eine Mail senden. Zum Beispiel, wenn eine bestimmte IP innerhalb von 2min 200mal versucht eine IP zu erreichen, wenn SSH-Logins eine Schwelle erreichen oder wenn ein bestimmter HTTP-Code zurückkommt, etc.

Das ist nur ein kurzer Einblick in Graylog, man kann sich auch eigene Dashboards bauen und diesen Usern/Gruppen zuweisen.

Ich hoffe, ich konnte euch einen kleinen Einblick geben und sofern Interesse besteht, werde ich zu Graylog noch weiterführendes schreiben.

Donnerstag, 4. Februar 2016

Monitoring mal anders..

Kurzvorstellung von zabbix


Jeder von euch kennt die verschiedensten Monitoringlösungen, das bekannteste (und evtl auch das weit verbreiteste?) dürfte wohl nagios/icinga sein. Darüber hinaus gibt es unter anderem noch Shinken, CheckMK, Zenoss, bloonix, Prometheus, PRTG, WhatsUp um nur einige zu nennen. Ich möchte euch hier meinen persönlichen Favoriten vorstellen: Zabbix. Warum Zabbix? Nunja, zuerst Zabbix ist um einiges performanter und ressourcenschonender als viele andere Monitoringsysteme, da es in C geschrieben ist. Zabbix bietet eine einfache Bedienung, da vieles über das integrierte Webfrontend konfiguriert werden kann. SNMP, TelNet, Portabfragen, SSH Abfragen uvm bietet Zabbix out-of-the-box. Zu den interessanteren Dingen gehören eher Webmonitoring oder Low-Level-Discovery.

Zabbix selbst kann man recht gut skalieren, da man einzelne Teile auf verschiedene Server installieren kann, darunter den Zabbix-Server, den Zabbix Proxy, das Zabbix Webfrontend und die Datenbank. Da alle gesammelten Daten und bis auf ein paar Ausnahmen auch die gesamte Konfiguration von Zabbix in einer Datenbank liegt, steht und fällt mit der Datenbankperformance auch die ganze Performance von Zabbix selbst. Ein Vorteil ist jedoch, dass man sich relativ einfach Reporte und Statistiken erzeugen kann (Beispielsweise mit Pentaho Reports) und man muss schon mehrere tausend Hosts haben und relativ lange die Daten speichern um an einen Engpass zu kommen.

Zabbix kann Webseiten überwachen und man kann damit Szenarien erstellen, somit ist es möglich einen User zu simulieren Bsp: user kommt auf Seite, loggt sich ein surft noch ein paar Unterseiten an, bei jedem Scenario kann man den zu erwartenden Statuscode und den zu erwartenden Text angeben der auf der Seite sein soll. Wenn das nicht der Fall ist, kann man sich entsprechend Alarme ausgeben lassen.

Mittels Low-Level-Discovery (LLD) kann man speziellen Abfragen relativ einfach mehrere Sensoren „scannen“ ohne diese direkt hinzufügen zu müssen, ein kleines Beispiel: Eine SNMP Abfrage ab.cd.1.2.xx listet mir alle Temperatursensoren mit Namen auf wobei ab.cd.1.3.xx mir die entsprechenden Werte anzeigt, in Zabbix kann man damit relativ einfach so sich die Sensoren mit Namen und Werten anzeigen lassen.

Durch das integrierte Frontend kann man sich auch sehr einfach die Graphen zu Werten anzeigen lassen oder mehrere Graphen gleichzeitig anzeigen lassen (Bsp, load, used memory, iowait), so lassen sich schneller Zusammenhänge von Problemen erkennen. Kurz alles was in einer Zahl in Zabbix ankommt, kann man sich auch problemlos als Graphen darstellen lassen.

Selbstverständlich kann Zabbix auch alarmieren und nach Eskalation handeln; ein (fiktives) Beispiel: Apache2-Server reagiert nicht mehr → Zabbix startet den Dienst neu → geht immer noch nicht, Zabbix schickt eine Nachricht an den Support → nach 30min immer noch nichts → Zabbix startet per IPMI eine Gruppe von Servern neu → zugleich schickt Zabbix eine neue Nachricht an den Support mit „Ich war schneller ;)“ . Etwas praxisnaher: die USV fällt aus, wir werden benachrichtigt, dass die USV an ist und werden alle 5minuten über den Voltage-Verlauf informiert (mit Graph als Anhang).


Ich hoffe, ich konnte euch einen kleinen Einblick geben und sofern Interesse besteht, werde ich zu Zabbix noch weiterführendes schreiben.