{"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\/fr\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Comment nous avons construit la surveillance sur Prometheus, Clickhouse et ELK","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Je m'appelle Anton Baderin. Je travaille au Centre des Hautes Technologies et je m'occupe de l'administration syst\u00e8me. Il y a un mois, notre conf\u00e9rence d'entreprise a eu lieu, o\u00f9 nous avons partag\u00e9 notre exp\u00e9rience accumul\u00e9e avec la communaut\u00e9 IT de notre ville. J'ai parl\u00e9 de la surveillance des applications web. Le mat\u00e9riel \u00e9tait destin\u00e9 \u00e0 un niveau junior ou interm\u00e9diaire, qui n'avait pas mis en place ce processus depuis le d\u00e9but.<\/p>\n

<\/p>\n

\"Comment<\/p>\n

<\/p>\n

La pierre angulaire de tout syst\u00e8me de surveillance est la r\u00e9solution des probl\u00e8mes d'entreprise. La surveillance pour la surveillance n'int\u00e9resse personne. Que veut l'entreprise ? Que tout fonctionne rapidement et sans erreurs. L'entreprise souhaite de la proactivit\u00e9, afin que nous puissions identifier les probl\u00e8mes dans le fonctionnement du service et les r\u00e9soudre aussi rapidement que possible. C'est, en substance, les d\u00e9fis que j'ai relev\u00e9s tout au long de l'ann\u00e9e pr\u00e9c\u00e9dente pour le projet d'un de nos clients.<\/p>\n

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

\u00c0 propos du projet<\/h2>\n

<\/p>\n

Le projet est l'un des plus grands programmes de fid\u00e9lit\u00e9 du pays. Nous aidons les cha\u00eenes de vente au d\u00e9tail \u00e0 augmenter la fr\u00e9quence des ventes par divers outils marketing tels que les cartes de fid\u00e9lit\u00e9. Au total, le projet comprend 14 applications qui fonctionnent sur dix serveurs.<\/p>\n

<\/p>\n

Au cours des entretiens, j'ai souvent remarqu\u00e9 que les administrateurs ne s'approchent pas toujours correctement de la surveillance des applications web : beaucoup se limitent encore aux m\u00e9triques du syst\u00e8me d'exploitation et surveillent occasionnellement les services.<\/p>\n

<\/p>\n

Dans mon cas, la solution de surveillance du client reposait auparavant sur Icinga. Elle ne r\u00e9pondait en rien aux d\u00e9fis susmentionn\u00e9s. Souvent, le client nous informait lui-m\u00eame des probl\u00e8mes et il nous manquait souvent des donn\u00e9es pour comprendre la cause.<\/p>\n

<\/p>\n

De plus, il \u00e9tait clair qu'il n'y avait pas d'avenir pour son d\u00e9veloppement ult\u00e9rieur. Je pense que ceux qui connaissent Icinga comprendront. Donc, nous avons d\u00e9cid\u00e9 de retravailler compl\u00e8tement le syst\u00e8me de surveillance des applications web pour le projet.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Nous avons choisi Prometheus sur la base de trois indicateurs principaux :<\/p>\n

<\/p>\n

    \n
  1. Un grand nombre de m\u00e9triques disponibles. Dans notre cas, il y en a 60 000. Bien s\u00fbr, il convient de noter que la grande majorit\u00e9 d'entre elles ne sont pas utilis\u00e9es (probablement environ 95 %). D'autre part, elles sont toutes relativement bon march\u00e9. Pour nous, c'est l'autre extr\u00eame, compar\u00e9 \u00e0 Icinga que nous utilisions auparavant. Dans celui-ci, l'ajout de m\u00e9triques posait un r\u00e9el probl\u00e8me : celles existantes \u00e9taient co\u00fbteuses (il suffit de regarder le code source de n'importe quel plugin). Chaque plugin \u00e9tait un script en Bash ou en Python, dont l'ex\u00e9cution n'est pas bon march\u00e9 en termes de ressources consomm\u00e9es.<\/li>\n
  2. Ce syst\u00e8me consomme relativement peu de ressources. Pour toutes nos m\u00e9triques, 600 Mo de RAM, 15 % d'un c\u0153ur et quelques dizaines d'IOPS suffisent. Bien s\u00fbr, il faut ex\u00e9cuter des exportateurs de m\u00e9triques, mais tous sont \u00e9crits en Go et ne sont pas non plus tr\u00e8s gourmands. Je ne pense pas que ce soit un probl\u00e8me dans les r\u00e9alit\u00e9s modernes. <\/li>\n
  3. Permet de passer \u00e0 Kubernetes. \u00c9tant donn\u00e9 les plans du client, le choix est \u00e9vident. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    Nous ne collectons ni ne traitons les logs auparavant. Les inconv\u00e9nients sont clairs pour tout le monde. Nous avons choisi ELK, car nous avions d\u00e9j\u00e0 de l'exp\u00e9rience avec ce syst\u00e8me. Nous n'y stockons que les logs des applications. Les principaux crit\u00e8res de choix \u00e9taient la recherche full-text et sa rapidit\u00e9.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Au d\u00e9part, nous avons opt\u00e9 pour InfluxDB. Nous \u00e9tions conscients de la n\u00e9cessit\u00e9 de collecter les logs Nginx, les statistiques de pg_stat_statements et de stocker les donn\u00e9es historiques de Prometheus. L'Influx ne nous a pas plu, car il commen\u00e7ait p\u00e9riodiquement \u00e0 consommer une grande quantit\u00e9 de m\u00e9moire et s'effondrait. De plus, nous voulions regrouper les requ\u00eates par remote_addr, mais cette SGBD ne permet le regroupement que par tags. Les tags sont co\u00fbteux (en m\u00e9moire), leur nombre est conditionnellement limit\u00e9.<\/p>\n

    <\/p>\n

    Nous avons recommenc\u00e9 les recherches. Il nous fallait une base analytique avec une consommation minimale de ressources, de pr\u00e9f\u00e9rence avec compression des donn\u00e9es sur disque.<\/p>\n

    <\/p>\n

    Clickhouse r\u00e9pond \u00e0 tous ces crit\u00e8res, et nous n'avons jamais regrett\u00e9 notre choix. Nous n'\u00e9crivons pas des volumes de donn\u00e9es exceptionnels (le nombre d'inserts est d'environ cinq mille par minute).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic a historiquement \u00e9t\u00e9 avec nous, car c'\u00e9tait le choix du client. Nous l'utilisons comme APM.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Nous utilisons Zabbix exclusivement pour surveiller la Black Box de diverses API.<\/p>\n

    <\/p>\n

    D\u00e9finition de l'approche de monitoring<\/h2>\n

    <\/p>\n

    Nous souhaitions d\u00e9composer la t\u00e2che pour syst\u00e9matiser l'approche de monitoring.<\/p>\n

    <\/p>\n

    Pour cela, j'ai divis\u00e9 notre syst\u00e8me en plusieurs niveaux :<\/p>\n

    <\/p>\n