{"id":32322,"date":"2019-10-31T21:46:21","date_gmt":"2019-10-31T18:46:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk\/"},"modified":"2019-10-31T21:46:21","modified_gmt":"2019-10-31T18:46:21","slug":"kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Wie wir das Monitoring mit Prometheus, Clickhouse und ELK aufgebaut haben","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mein Name ist Anton Baderin. Ich arbeite im Zentrum f\u00fcr Hochtechnologien und besch\u00e4ftige mich mit Systemadministration. Vor einem Monat fand unsere Unternehmenskonferenz statt, auf der wir unsere gesammelten Erfahrungen mit der IT-Community unserer Stadt teilten. Ich sprach \u00fcber das Monitoring von Webanwendungen. Das Material war f\u00fcr Fachkr\u00e4fte auf Junior- oder Mittelstufe gedacht, die diesen Prozess nicht von Grund auf aufgebaut haben.<\/p>\n

<\/p>\n

\"Wie<\/p>\n

<\/p>\n

Der Grundpfeiler jeder Monitoring-L\u00f6sung ist die Erf\u00fcllung der Gesch\u00e4ftsziele. Monitoring ohne einen klaren Zweck interessiert niemanden. Was m\u00f6chte das Gesch\u00e4ft? Dass alles schnell und fehlerfrei funktioniert. Das Gesch\u00e4ft verlangt nach Proaktivit\u00e4t, damit wir selbst Probleme im Service feststellen und schnellstm\u00f6glich beheben. Das sind im Wesentlichen die Herausforderungen, die ich im vergangenen Jahr in einem Projekt eines unserer Kunden angegangen bin.<\/p>\n

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

\u00dcber das Projekt<\/h2>\n

<\/p>\n

Das Projekt ist eines der gr\u00f6\u00dften Loyalty-Programme im Land. Wir helfen Einzelhandelsketten, die Verkaufsfrequenz durch verschiedene Marketinginstrumente wie Bonuskarten zu erh\u00f6hen. Insgesamt umfasst das Projekt 14 Anwendungen, die auf zehn Servern laufen.<\/p>\n

<\/p>\n

W\u00e4hrend meiner Vorstellungsgespr\u00e4che habe ich immer wieder festgestellt, dass Administratoren nicht immer die richtige Herangehensweise an das Monitoring von Webanwendungen haben: Viele fokussieren sich weiterhin auf die Betriebssystemmetriken und \u00fcberwachen gelegentlich die Dienste.<\/p>\n

<\/p>\n

In meinem Fall basierte das Monitoring-System des Kunden auf Icinga. Diese L\u00f6sung erf\u00fcllte jedoch nicht die oben genannten Anforderungen. Oft informierte uns der Kunde selbst \u00fcber Probleme, und es fehlte uns h\u00e4ufig an Daten, um die Ursachen zu ermitteln.<\/p>\n

<\/p>\n

Dar\u00fcber hinaus war uns klar, dass eine weitere Entwicklung nicht vielversprechend w\u00e4re. Ich denke, diejenigen, die mit Icinga vertraut sind, werden mich verstehen. Also haben wir beschlossen, das Monitoring-System f\u00fcr Webanwendungen im Projekt komplett neu zu gestalten.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Wir haben uns f\u00fcr Prometheus entschieden, basierend auf drei Hauptkriterien:<\/p>\n

<\/p>\n

    \n
  1. Eine riesige Anzahl an verf\u00fcgbaren Metriken. In unserem Fall sind es 60.000. Nat\u00fcrlich muss erw\u00e4hnt werden, dass die \u00fcberwiegende Mehrheit davon nicht genutzt wird (wahrscheinlich etwa 95%). Auf der anderen Seite sind sie alle relativ g\u00fcnstig. F\u00fcr uns ist dies eine andere Extreme im Vergleich zu dem zuvor verwendeten Icinga. Dort war das Hinzuf\u00fcgen von Metriken besonders schmerzhaft: die verf\u00fcgbaren waren teuer (man muss nur den Quellcode eines beliebigen Plugins ansehen). Jedes Plugin war ein Skript in Bash oder Python, dessen Ausf\u00fchrung in Bezug auf die ben\u00f6tigten Ressourcen nicht g\u00fcnstig war.<\/li>\n
  2. Dieses System verbraucht relativ wenig Ressourcen. F\u00fcr all unsere Metriken gen\u00fcgen 600 MB RAM, 15 % eines Kerns und ein paar Dutzend IOPS. Nat\u00fcrlich m\u00fcssen Metrik-Exporteure laufen, aber alle sind in Go geschrieben und ebenfalls nicht ressourcenhungrig. Ich denke nicht, dass das in der heutigen Zeit ein Problem ist. <\/li>\n
  3. Erm\u00f6glicht den \u00dcbergang zu Kubernetes. Angesichts der Pl\u00e4ne des Kunden ist die Wahl offensichtlich. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    Fr\u00fcher haben wir keine Logs gesammelt oder verarbeitet. Die M\u00e4ngel sind allen bekannt. Wir haben uns f\u00fcr ELK entschieden, da wir bereits Erfahrung mit diesem System hatten. Dort speichern wir nur die Anwendungsprotokolle. Die Hauptkriterien f\u00fcr die Auswahl waren die Volltextsuche und ihre Geschwindigkeit.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Zun\u00e4chst fiel die Wahl auf InfluxDB. Wir wussten, dass wir Logs von Nginx, Statistiken aus pg_stat_statements und historische Daten von Prometheus sammeln mussten. Influx gefiel uns nicht, da es manchmal viel Speicher verbrauchte und abst\u00fcrzte. Au\u00dferdem wollten wir Anfragen nach remote_addr gruppieren, aber in dieser DB war die Gruppierung nur nach Tags m\u00f6glich. Tags sind teuer (Speicher), ihre Anzahl ist begrenzt.<\/p>\n

    <\/p>\n

    Wir begannen die Suche von neuem. Wir ben\u00f6tigten eine analytische Basis mit minimalem Ressourcenverbrauch, idealerweise mit Datenkompression auf der Festplatte.<\/p>\n

    <\/p>\n

    Clickhouse erf\u00fcllt all diese Kriterien, und wir haben unsere Wahl nie bereut. Wir schreiben keine au\u00dfergew\u00f6hnlich gro\u00dfen Datenmengen in ihn (die Anzahl der Einf\u00fcgungen liegt bei etwa f\u00fcnftausend pro Minute).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic war historisch gesehen immer bei uns, da es die Wahl des Kunden war. Bei uns wird es als APM eingesetzt.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Wir verwenden Zabbix ausschlie\u00dflich zur \u00dcberwachung verschiedener API-Blackboxen.<\/p>\n

    <\/p>\n

    Ansatz zur \u00dcberwachung definieren<\/h2>\n

    <\/p>\n

    Wir wollten die Aufgabe aufschl\u00fcsseln und dadurch unseren Ansatz zur \u00dcberwachung systematisieren.<\/p>\n

    <\/p>\n

    Daf\u00fcr habe ich unser System in folgende Ebenen unterteilt:<\/p>\n

    <\/p>\n