{"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: Modulsystem f\u00fcr mikroservice Architektur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Heute funktionieren in unserem Projekt neben dem monolithischen Code Dutzende von Mikrodiensten. Jeder von ihnen erfordert eine \u00dcberwachung. Es ist problematisch, dies in solch einem Umfang von DevOps-Ingenieuren durchf\u00fchren zu lassen. Wir haben ein \u00dcberwachungssystem entwickelt, das als Dienst f\u00fcr Entwickler fungiert. Sie k\u00f6nnen selbstst\u00e4ndig Metriken in das \u00dcberwachungssystem schreiben, sie nutzen, Dashboards auf deren Grundlage erstellen und Alarme integrieren, die bei Erreichen von Grenzwerten ausgel\u00f6st werden. Von den DevOps-Ingenieuren bleibt nur die Infrastruktur und Dokumentation \u00fcbrig. <\/p>\n

Dieser Beitrag ist eine Transkription meines Vortrags von unserer Sektion<\/a><\/noindex> auf RIT++. Viele hatten uns gebeten, schriftliche Versionen der Vortr\u00e4ge dort zu machen. Wenn Sie auf der Konferenz waren oder das Video angeschaut haben, werden Sie nichts Neues finden. Allen anderen \u2013 herzlich willkommen unter dem Beitrag. 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: Schemas und Pl\u00e4ne <\/h3>\n

\nWie sind wir zu dem 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 Knoten, die f\u00fcr die \u00dcberwachung verantwortlich waren. Es gibt eine ganze Menge verschiedener Cronjobs, Skripte, Daemons, die irgendetwas irgendwo in irgendeiner Weise \u00fcberwachen, Nachrichten senden und Funktionen ausf\u00fchren. Wir dachten, dass eine solche Systematik mit der Zeit weniger tragf\u00e4hig sein wird. Es hat keinen Sinn, sie weiterzuentwickeln: sie ist zu schwerf\u00e4llig.
\nWir haben beschlossen, die \u00dcberwachungselemente auszuw\u00e4hlen, die wir behalten und weiterentwickeln wollen, und diejenigen, von denen wir uns trennen. Es waren 19, die \u00fcbrig blieben. Nur Graphite, Aggregatoren und Grafana als Dashboard blieben \u00fcbrig. Aber wie wird das neue System aussehen? So: <\/p>\n

\"Monitoring
\n
\nWir haben ein Metrik-Speicher: dies sind Graphite, die auf schnellen SSDs basieren, plus bestimmte Aggregatoren f\u00fcr die Metriken. Au\u00dferdem Grafana zur Darstellung der Dashboards und Moira als Alerting-System. Zudem wollten wir ein System zur Erkennung von Anomalien entwickeln. <\/p>\n

Standard: Monitoring 2.0<\/h3>\n

\nSo sah der Plan im Jahr 2015 aus. Wir mussten nicht nur die Infrastruktur und den Dienst selbst vorbereiten, sondern auch die Dokumentation daf\u00fcr. Wir haben einen Unternehmensstandard entwickelt, den wir Monitoring 2.0 genannt haben. Welche Anforderungen gab es an das System? <\/p>\n