Server Monitoring-System aufsetzen

  • Moin moin,


    ich wollte mal hören was Ihr so für self-hosted Monitoring Software einsetzt und allgemein welche Daten Ihr hiermit sammelt/überwacht? Gerade im Bezug auf die grafische Darstellungen (Metriken) und auch das serverseitige sammeln der dazu benötigten Daten.


    Bei mir ist nämlich das Problem, dass ich meine Server / Webhosting absolut hobbymäßig nutze aber dennoch gerne allgemeine Daten (CPU, RAM, Festplatte, Load, Traffic etc.) zu den Servern sowie deren Dienste zentral in einem Monitoring einbinden möchte und im Falle eines Falls auch über fehlerhafte Dienste / Lastspitzen / timeouts / Totalausfall benachrichtigt werden möchte.


    Die letzten Tage habe ich mir z.B. Grafana angeschaut, was mir schon allein von der visuell aufbereiteten Darstellung aber auch dem Alertsystem sehr zugesagt hat. Der geballte Funktionsumfang von Grafana ist aber für mein Vorhaben eventuell schon zu umfangreich / komplex (z.B. kaum Erfahrung mit SQL querys). Oder gibt es zu den unten aufgeführten Diensten z.B. vorgefertigte Module um das komplette Daschboard und deren durchaus komplexen sql querys nicht komplett selbst bauen müssen. Zudem welchen Unterbau (Datenbank / Datensammler) sollte ich für mein vorhaben am besten verwenden? Oder gibt es für mein Vorhaben bessere Lösungen die nicht ganz so komplex sind aber dennoch "state of the art" sind und die gesammelten Daten "hübsch" darstellen können.


    Setup:

    • RS 1: openVPN, Nextcloud+elasticsearch, nginx, mariadb
    • RS 2 (in Planung): mailcow, nginx, mariadb
    • Beim Webhosting würde es mir reichen wenn die Erreichbarkeit dessen geprüft wird und gegebenenfalls Offlinemeldungen protokolliert werden.


    Ein separater 200er VPS soll dann die Daten sammeln und gleichzeitig dann auch das eigentliche monitoring derer übernehmen.

  • Grafana ist ja auch nur ein graphisches Frontend, das erst mit Daten gefüttert werden muss (z.B. von einem Prometheus Server oder Zabbix).


    Ich empfehle immer gerne Zabbix, das läuft auch auf einem VPS200 gut. Da kann man zur Not immer noch ein Grafana dranhängen, wenn einem die Graphen dort besser gefallen. Zabbix braucht ein wenig Eingewöhnungszeit, aber das bringt schon recht viele Templates mit, die man im ersten Schritt erstmal so nutzen kann.

  • Ich nutze für meine RS netdata und speichere alles in einer InfluxDB. Netdata speichert halt nur im RAM für eine Stunde. dafür sind die ausgelesen Daten sehr umfangreich. Mittels Grafana habe ich dann eine Langezeitübersicht. Netdata kann auch andere Backends nutzen.

  • Ich habe meine Umgebung komplett auf HA gebaut und alles läuft in Docker. Hast du mehrere Systeme zur Verfügung oder wie möchtest du das Thema angehen?


    Für das Monitoring nutze ich mehrere Wege:

    1.) K8S WhiteBox Monitoring:

    Prometheus Operator der alle Nodes und ServiceMonitore scraped sowie mehrere externe System die mit dem Blackbox Exporter Performance Metriken liefern


    2.) K8S BlackBox Monitoring und weitere Hosts:
    HA Cluster in dem Icinga2 mit mehreren Mastern läuft und gegen die alle Server registriert sind. Das Setup ist komplett automatisiert in K8S Deployments und Ansible. Einfach neuen Host angeben und innerhalb von 30 Sekunden ist der mit im Monitoring drinne. Die überwachten Services hab ich mal als Screenshots angehangen. Zu den jeweiligen Diensten gibt's dann direkt Graphen aus InfluxDB welche im Web-Interface angezeigt werden.

  • da ich den ganzen Kram hier auch nur hobbymäßig nutze,

    habe ich einen kleinen vps50 mit munin laufen, der die anderen 3

    Server und sich selbst überwacht. ich hatte eine zeitlang phpservermon

    auf einem micro-WH laufen , welches die Erreichbarkeit der Dienste der

    Server prüft. aber da es mir zu nervig war, mich da immer einzuloggen,

    prüfe ich das nun per bashscript und lasse mir eine Nachricht per Telegram

    senden, wenn ein Dienst nicht laufen sollte.

    Hier prüfe ich aber nur

    *Webserver

    *Mailserver

    *SSH

    *munin

    Ausserdem noch

    CPU

    MEM

    Diskspace

    und die Uptime

    It's me, only me, pure michi

    RS 500 SAS G8 Ostern 2019

    VPS: 50 G7 |B Ostern 2017|200 G8 Aktion

    WH: SmallEi | Adv17 Webhosting Spezial Family | Expert Spezial 2016

  • Ich persönlich habe bisher Prometheus+NodeExporter genutzt und steige gerade auf Icinga2 um. Icinga2 ist ein bisschen pain in the Ass bei der Einrichtung und Gewöhnung, aber ich finde das Arbeiten mit Director und Co. sehr entspannt.


    Das Datenbackend und die Visualisierung wollte ich eigentlich über InfluxDB und Grafana machen, aber da es noch andere Möglichkeiten gibt, will ich mich da vorher nochmal über die anderen Möglichkeiten informieren.


    In Icinga2 kannst du dir dann je nach Anwendungszweck Vorlagen und Templates bauen, die kannst du sowohl für Webhosting, Server, Dienste und alles mögliche nutzen.

    RS Rentier 2019 | CX11-CEPH | VPS Karneval 2020


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)

  • Ich nutze Nagios (XI) und kann das uneingeschränkt weiterempfehlen. Die kostenlose Version unterstützt zwar offiziell nur 7 Hosts, aber wer die vorgegebenen Templates um einen Parameter ergänzt, kann theoretisch so viele Hosts nutzen wie nötig ^^


    Nebenbei läuft noch munin, obwohl das neben Nagios nahezu überflüssig ist. Da gibt es eigentlich fast nichts, was XI nicht auch out-of-the-box anzeigt.


    Wieso dürfen Anhänge im Forum eigentlich nur lächerliche 1 MB groß sein? Das ist zu wenig für ein iOS Screenshot.

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    binichblau: Online-Promillerechner - www.binichblau.de

  • Munin und Monit; Ressourcenverbrauch, auch wenn mehrere Cluster-Knoten gleichzeitig für die Datenaufbereitung zuständig sind und sich damit auch gegenseitig selbst überwachen, hält sich in Grenzen.

    Hier wäre ich aber durchaus sehr an Erfahrungsberichten von "Umsteigern" beider Hilfswerkzeuge auf größere/flexiblere/komplexere freie Lösungen interessiert, welche den obengenannten Einsatz mit mehreren unabhängigen Überwachungs-Instanzen ("Active/Active"-Modus) beibehalten haben.

  • Ich persönlich habe bisher Prometheus+NodeExporter genutzt und steige gerade auf Icinga2 um. Icinga2 ist ein bisschen pain in the Ass bei der Einrichtung und Gewöhnung, aber ich finde das Arbeiten mit Director und Co. sehr entspannt.


    Das Datenbackend und die Visualisierung wollte ich eigentlich über InfluxDB und Grafana machen, aber da es noch andere Möglichkeiten gibt, will ich mich da vorher nochmal über die anderen Möglichkeiten informieren.


    In Icinga2 kannst du dir dann je nach Anwendungszweck Vorlagen und Templates bauen, die kannst du sowohl für Webhosting, Server, Dienste und alles mögliche nutzen.

    Dem kann ich nur zustimmen... Am Anfang hab ich mich sehr schwer getan, nachdem ich dann die Logik verstanden habe macht es nun Spaß in kurzer Zeit neue Checks mit einzubauen. Das Docker setup ist mittlerweile so weit gereift, dass nur noch 7 Dateien applyen muss und es wird automatisch das HA-Cluster mit Icingaweb und Director erzeugt.



    ...

    Hier wäre ich aber durchaus sehr an Erfahrungsberichten von "Umsteigern" beider Hilfswerkzeuge auf größere/flexiblere/komplexere freie Lösungen interessiert, welche den obengenannten Einsatz mit mehreren unabhängigen Überwachungs-Instanzen ("Active/Active"-Modus) beibehalten haben.


    Wie darf ich mir Active / Active vorstellen? In Prometheus würde ich dann einfach 2mal die gleiche Konfig deployen. Bei Icinga2 teilen sich die Master die Arbeit auf und führen das im Backend dann zum vollständigen Mosaik zusammen.


    Prometheus mag ich solange, wie ich innerhalb von Kubernetes bin und mithilfe von ServiceMonitor relativ einfach ans Ziel komme. Auf Hosts selber wäre mir das viel zu viele Ports freischalten und der NodeExporter kann nichtmal BasicAuth von sich aus, so wie die meisten Exporter.

  • Nutze aktuell nen TIG Stack, also Telegraf zum abgreifen der Metrics, InfluxDB als Realtime DB und Grafana zum optisch schön angucken.


    Alles läuft auf einem kleinen VPS. Grafana ist via ngnix proxy von außen erreichbar. Auf den anderen VPS und RS läuft natürlich nur Telegraf. Die Übertragung der ganzen Telegraf Clients erfolgt verschlüsselt via cloudLAN (das kostenlose reicht mehr als aus)


    Sonst macht der VPS eigentlich nix, außer via acme.sh Zertifikate für alle VPS/RS/NAS/etc zu verwalten 👌😊

  • Den Tick Stack hatte ich vorher auch im Betrieb als ich noch im Versuch war mit 1 zentralen Lösung alles zu erschlagen. Da hatte ich ne ähnliche Konstruktion im Einsatz, allerdings hatte ich am Ende Probleme mit der Skalierbarkeit InfluxDB in der kostenlosen Version. Das aktuelle Setup sieht so aus:


    1.) K8S Cluster 1:

    - Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors

    - Automatisch provisioniertes Grafana inkl Dashboards mit Prometheus als Datenquelle


    2.) K8S Cluster 2:

    - Icinga2 mit 2 Mastern und Mysql HA

    - InfluxDB für schöne Graphen zu den Werten

    - Automatisch provisioniertes Grafana inkl Dashboards mit InfluxDB und Prometheus als Datenquelle

    - Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors


    3.) K8S Cluster 3:

    - Graylog mit ElasticSearch

    - Prometheus mit 2 Tagen Retention, dynamische Konfiguration per ServiceMonitors

    - Zentrales Prometheus das alle anderen Prometheus absaugt und dezeit 120 Tage die Daten vorhält. ( braucht so 12 GB Ram momentan alleine....)

    - Automatisch provisioniertes Grafana inkl Dashboards mit Prometheusen als Datenquelle


    Die Nodes sind Debian preseeded und mit Ansible anschließend standardisiert K8S Deployed. Jedes der Cluster lässt sich dank Backups, Ansible und den ganzen Deployments innerhalb von ~1 - 2 Stunden neu erzeugen.


    Leider kann prometheus ja nicht mehrere Instanzen mit gleicher Konfiguration starten und die teilen sich die Arbeit wie bei Icinga2. Evtl ziehe ich noch Icinga2 und das zentrale Prometheus zusammen und lasse die 3 Icinga2 DeadManSwitch miteinander spielen ;-)

  • Ich packe es mal in diesen Thread rein:


    Seit kurzem (=gestern:D) setze ich nun doch munin zur Überwachung meiner Server ein.

    Gefällt mir recht gut, insbesondere wegen der unkomplizierten Installation und Bedienung.


    Meine Frage an die Munin-Experten hier:

    Defaultmäßig wird mysql nicht mit überwacht. Das würde ich gerne, zumindest für einen der Server, noch mit aufnehmen.

    Die Infos im Netz, die ich dazu gefunden habe sind leider nicht sehr konsistent und wohl auch tw. veraltet.


    Gibt es eine gute, knackige, vor allem aktuelle Beschreibung, wie man (unter Ubuntu 18 oder 20) das Monitoring von mysql/mariadb in munin aktiviert?

  • (Pfade beziehen sich auf Debian/Ubuntu!)


    aRaphael Du musst nur die entsprechenden Plugins aus /usr/share/munin/plugins mittels Symlink in /etc/munin/plugins verlinken. Eventuell noch notwendige Konfigurationen über /etc/munin/plugin-conf.d vornehmen. Munin-Node neu starten nicht vergessen!


    Testen kannst Du verlinkte Plugins vor dem Neustart des Nodes über munin-run. Wenn Du mehr Plugins haben möchtest, solltest Du das Paket munin-plugins-extra installieren. Falls das noch immer nicht genügt, findet man im Internet zahlreiche weitere Plugins. Die notwendigen Konfigurationen sieht man spätestens, wenn man den Code der Plugins ansieht.

  • Nein. Die Plugins und deren Konfiguration werden am Node verwaltet. Aber selbstverständlich können Master und Node auch am gleichen Server laufen. Die Konfiguration ist trotzdem für beide Komponenten getrennt.


    Hinweis am Rande: Du kannst am Master aber trotzdem einzelne Werte der Nodes anpassen. Zum Beispiel Warnschwellen oder ob bestimmte Daten in Grafiken landen sollen. Das ist normalerweise aber nur der letzte Ausweg, wenn es anders nicht geht. Am Master kann man sogar virtuelle Grafiken konfigurieren, in denen Daten von mehreren verschiedenen Nodes oder Plugins auftauchen.

  • Wie ist das mit dem Datenbankzugriff? Den werden die Plugins doch wohl benötigen?

    Debian (und ich vermute mal Ubuntu auch) verwendet für administrative Tasks die Datei /etc/mysql/debian.cnf. Früher mit einem eigenen Account/Passwort, mittlerweile über ein lokales Socket ohne Passwort. Wenn Du mittels mysql --defaults-file=/etc/mysql/debian.cnf drauf kommst, sollte alles passen.


    In der Datei /etc/munin/plugin-conf.d/munin-node sollte normalerweise bereits eine passende Konfiguration für Munin existieren:

    Code
    1. [mysql*]
    2. user root
    3. env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
    4. env.mysqluser root
    5. env.mysqlconnection DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf

    Wenn Du ein anderes Plugin verwendest, kann für dieses vielleicht eine andere Konfiguration notwendig sein. Für die üblichen mysql_* Plugins reicht das aber.