{"id":52115,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/monitoring-kak-servis-modulnaya-sistema-dlya-mikroservisnoj-arhitektury","title":{"rendered":"Monitoring als Dienst: Modulares System f\u00fcr Microservices-Architekturen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Heute arbeiten auf unserem Projekt, neben monolithischem Code, zahlreiche Mikrodienste. Jeder von ihnen ben\u00f6tigt umfassende \u00dcberwachung. Dies in solch einem Umfang mit DevOps-Ingenieuren zu erledigen, ist problematisch. Deshalb haben wir ein \u00dcberwachungssystem entwickelt, das als Service f\u00fcr Entwickler fungiert. Sie k\u00f6nnen eigenst\u00e4ndig Metriken in das \u00dcberwachungssystem einpflegen, diese nutzen, Dashboards erstellen und Alarme einstellen, die bei Erreichen bestimmter Grenzwerte ausgel\u00f6st werden. Die DevOps-Ingenieure sind lediglich f\u00fcr die Infrastruktur und Dokumentation zust\u00e4ndig. <\/p>\n

Dieser Beitrag ist eine Aufzeichnung meines Vortrags aus unserer Sektion<\/a><\/noindex> auf der RIT++. Viele hatten gebeten, die schriftlichen Versionen der Vortr\u00e4ge dort zu erstellen. Wenn Sie auf der Konferenz waren oder das Video angesehen haben, werden Sie nichts Neues finden. Allen anderen \u2013 willkommen unter dem Artikel. Ich werde erz\u00e4hlen, wie wir zu diesem System gekommen sind, wie es funktioniert und wie wir planen, es zu aktualisieren. <\/p>\n

\"Monitoring
\n<\/a><\/noindex><\/p>\n

Die Vergangenheit: Pl\u00e4ne und Entw\u00fcrfe <\/h3>\n

\nWie sind wir zum bestehenden \u00dcberwachungssystem gekommen? Um diese Frage zu beantworten, m\u00fcssen wir ins Jahr 2015 zur\u00fcckblicken. So sah es damals aus: <\/p>\n

\"Monitoring
\n
\nWir hatten etwa 24 Knotenpunkte, die f\u00fcr das Monitoring zust\u00e4ndig waren. Hier gibt es eine ganze Reihe verschiedener Cron-Jobs, Skripte und Dienste, die in irgendeiner Weise \u00fcberwachen, Nachrichten senden und Funktionen ausf\u00fchren. Wir haben festgestellt, dass eine solche Systemstruktur mit der Zeit weniger tragf\u00e4hig sein wird. Es macht keinen Sinn, diese weiterzuentwickeln: sie ist einfach zu umst\u00e4ndlich.
\nWir haben uns entschlossen, die Monitoring-Elemente auszuw\u00e4hlen, die wir beibehalten und weiterentwickeln m\u00f6chten, und solche, von denen wir uns trennen werden. Am Ende blieben 19 \u00fcbrig. Es sind nur noch Graphite, Aggregatoren und Grafana als Dashboard \u00fcbrig. Aber wie wird das neue System aussehen? So: <\/p>\n

\"Monitoring
\n
\nWir haben ein Metrics-Repository: das sind Graphite, die auf schnellen SSDs basieren, und bestimmte Aggregatoren f\u00fcr Metriken. Dar\u00fcber hinaus verwenden wir Grafana zur Darstellung von Dashboards und Moira f\u00fcr das Alerting. Au\u00dferdem m\u00f6chten wir ein System zur Anomalieerkennung entwickeln. <\/p>\n

Standard: Monitoring 2.0<\/h3>\n

\nSo sahen die Pl\u00e4ne im Jahr 2015 aus. Aber wir mussten nicht nur die Infrastruktur und den Dienst selbst vorbereiten, sondern auch die dazugeh\u00f6rige Dokumentation. F\u00fcr uns haben wir einen Unternehmensstandard entwickelt, den wir Monitoring 2.0 genannt haben. Welche Anforderungen gab es an das System? <\/p>\n