Systemmetriken: Wissen was war und ist (part 1)

wenn es um die frage der systemüberwachung geht, gilt es die frage zu
klären, was ist genau gewünscht. zum einen gibt es die überwachung und dann die statistik Verfassung. beides kann gemeinsam betrachtet werden, sollte aber meiner Meinung nach getrennt sein.

reine überwachung gibt es entweder lokal via monit, god oder bluepill. aber gerade in grösseren umgebungen hat sich das zentralisierte überwachen via nagios bzw. incinga oder einem der anderen vertreter wie zabbix durchgesetzt. der zentralisierte Ansatz bietet den vorteil einer einheitlichen konfiguration und auch einer zentralen erfassung aller daten. aber natürlich ist die damit gewonnene übersicht mit dem preis der komplexeren anforderungen gezahlt. meist wird dedizierter server benötigt. das kann und will nicht jemand leisten. hier bietet sich der hybrid mmonit an, welcher eine übersicht der sich bei ihm meldenden monit instanzen zeigt und hier auch statistiken baut.

aber was ist jetzt mit den ganzen statistischen daten, sogenannten metriken über die systeme? den natürlich ist nicht nur der ist zustand von interesse, sondern auch die vergangenheit. gerade wenn es darum geht die fehler in hochkomplexen systemen zu finden. oder um voraussagen zu machen, wann eine hardware unter umständen nicht mehr ausreicht.
jede der angesprochenen überwachungslösungen bietet auch die Möglichkeit statistiken über die überwachten server und dienste zu erstellen. je nach system sind diese jedoch sehr beschränkt bzw. nicht wirklich einfach zu konfigurieren, bieten aber in vielen szenarien ausreichende information.

aber es werden nicht immer alle stellen überwacht über die Statistiken sprich metriken gesammelt werden sollen. jetzt kann einen Ansatz wählen wo dies nicht vorkommt, oder aber die erfassung der metriken von der systemüberwachung lösen.

hat man sich dafür entschieden gilt es ers einmal den wald etwas zu lichten und aussortieren, welches system bietet welche Möglichkeiten und was will ich einsetzen. hierbei sollten die eigenen fähigkeiten, die hardware vorraussetzungen und aber auch das gewünschte Ergebnis berücksichtigt werden.

der grobe blick

in kleineren umgebungen und bei allen denen ein grober blick ausreicht bieten sich lösungen wie munin oder cacti an, gerade wenn relativ zügig eine übersicht erstellt werden soll. beide Systeme haben vor und nachteile, bieten aber eigentlich alles was man braucht, wenn der grobe überblick ausreicht. deswegen grob weil beide darauf ausgelegt sind ihre messpunkte im 5 minuten abstand abzufragen.

munin ist leichter zu erweitern, da ein daemon auf den servern läuft, welcher lokale scripte ausführt. diese werden von einer zentralen stelle eingesammelt und zu statischen webseiten verarbeitet. die lokalen scripte können in jeder versprache verfasst werden, was einem beim erstellen von eigenem viel freiheit läßt. die gesammelten Informationen werden einmal pro host (nach dessen fqdn) dargestellt und es lassen sich auf dem zentralen server auch metriken zusammenfassen.

für cacti wird ein kompletter LAMP stack benötigt, die daten können über sehr viele unterschiedliche wege in das system kommen. snmp oder lokal laufende scripte sind hier neben noch einigem anderen möglich. hier liegt der vorteil das auch netzwerkkomponente erfasst werden könnten, da diese meist snmp sprechen. das erstellen neuer graphen und Übersichten ist wesentlich komplexer und nicht immer intuitiv. zwar werden viele vorkonfigurierte templates angeboten (und lassen sich finden) jedoch ist das erstellen eigener graphen und templates durchaus nicht gerade trivial.

beide systeme sammeln ihre daten auf dem zentralen server und sind genau an dieser stelle nicht skalierbar. das bedeutet hat der zentrale server ein problem mit seinen leistungsreserven, kann hier nur über mehr und stärkeres blech skaliert werden. auch werden die messpunkte immer sequenziell abgefragt und es finde keine parallele abarbeitung statt. zwar ist dies in zukünftigen versionen angedacht, aber ein halbwegs stabiler betrieb aus meiner sicht noch nicht möglich.

viele mögen an dieser stelle sagen, das es ihnen vollständig ausreicht, jedoch sollte bedacht werden das eine migration meist mit dem Verlust der gesammelten daten einher geht. sollte die migration gelingen (und es kommt nicht zu einer doppelnutzung) ist dies meistens mit sehr viel aufwand verbunden. bleibt der zu überwachende hardware schwarm aber beständig und ist nicht schwankungen (stichwort cloud) unterworfen, ist es vom arbeitsaufwand sicherlich vorzuziehen. den alles folgende ist sicherlich nur schwer mit basis sysop kenntnissen umzusetzen.

das ganze ist nicht in stein geschlagen, sondern spiegeln nur meine persönlichen erfahrungen.

weiteres dann in part 2.