{"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\/it\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Come abbiamo costruito il monitoraggio su Prometheus, Clickhouse e ELK","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mi chiamo Anton Baderin. Lavoro presso il Centro Tecnologie Avanzate e mi occupo di amministrazione di sistemi. Un mese fa si \u00e8 conclusa la nostra conferenza aziendale, dove abbiamo condiviso l'esperienza accumulata con la comunit\u00e0 IT della nostra citt\u00e0. Ho parlato del monitoraggio delle applicazioni web. Il materiale era destinato a un pubblico di livello junior o middle, che non aveva impostato questo processo da zero.<\/p>\n

<\/p>\n

\"Come<\/p>\n

<\/p>\n

La pietra angolare di qualsiasi sistema di monitoraggio \u00e8 la risoluzione delle problematiche aziendali. Il monitoraggio fine a se stesso non interessa a nessuno. Cosa desidera il business? Che tutto funzioni rapidamente e senza errori. Il business vuole proattivit\u00e0, che possiamo identificare autonomamente i problemi nel funzionamento del servizio e risolverli il pi\u00f9 velocemente possibile. Queste sono, in sostanza, le sfide che ho affrontato per tutto lo scorso anno nel progetto di uno dei nostri clienti.<\/p>\n

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

Il progetto<\/h2>\n

<\/p>\n

Il progetto \u00e8 uno dei programmi di fedelt\u00e0 pi\u00f9 grandi del paese. Aiutiamo le reti di vendita al dettaglio ad aumentare la frequenza delle vendite tramite vari strumenti di marketing come le carte fedelt\u00e0. In totale, il progetto comprende 14 applicazioni, che operano su dieci server.<\/p>\n

<\/p>\n

Durante i colloqui di lavoro, ho notato pi\u00f9 volte che gli amministratori non sempre si approcciano correttamente al monitoraggio delle applicazioni web: molti si fermano ancora alle metriche del sistema operativo, monitorando raramente i servizi.<\/p>\n

<\/p>\n

Nel mio caso, in precedenza il sistema di monitoraggio del cliente si basava su Icinga. Questo non affrontava le problematiche sopra menzionate. Spesso il cliente ci comunicava autonomamente i problemi e non di rado ci mancavano i dati per risalire alla causa.<\/p>\n

<\/p>\n

Inoltre, c'era una chiara comprensione della mancanza di prospettive per il suo ulteriore sviluppo. Penso che chi conosce Icinga mi capir\u00e0. Pertanto, abbiamo deciso di riprogettare completamente il sistema di monitoraggio delle applicazioni web nel progetto.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Abbiamo scelto Prometheus sulla base di tre indicatori principali:<\/p>\n

<\/p>\n

    \n
  1. Un numero enorme di metriche disponibili. Nel nostro caso sono 60.000. Certo, \u00e8 da sottolineare che la stragrande maggioranza di esse non viene utilizzata (probabilmente circa il 95%). D'altra parte, sono tutte relativamente economiche. Per noi, questa \u00e8 l'altra extremit\u00e0, rispetto a quanto utilizzato precedentemente con Icinga. Aggiungere metriche in quell'ultima era particolarmente doloroso: quelle esistenti costavano molto (basta guardare il codice sorgente di qualsiasi plugin). Ogni plugin era uno script in Bash o Python, il cui avvio non \u00e8 economico in termini di risorse consumate.<\/li>\n
  2. Questo sistema consuma una quantit\u00e0 relativamente ridotta di risorse. Per tutte le nostre metriche, bastano 600 MB di memoria RAM, il 15% di un core e alcune decine di IOPS. Certo, dobbiamo avviare gli exporter di metriche, ma sono tutti scritti in Go e non si distinguono per affamato di risorse. Non credo che nelle attuali condizioni sia un problema. <\/li>\n
  3. Consente il passaggio a Kubernetes. Considerati i piani del cliente, la scelta \u00e8 evidente. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    In precedenza non raccoglievamo n\u00e9 elaboravamo log. Gli svantaggi sono chiari a tutti. Abbiamo scelto ELK, poich\u00e9 avevamo gi\u00e0 esperienza con questo sistema. Conserviamo l\u00ec solo i log delle applicazioni. I criteri principali di scelta sono stati la ricerca full-text e la sua velocit\u00e0.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Inizialmente la scelta \u00e8 ricaduta su InfluxDB. Eravamo consapevoli della necessit\u00e0 di raccogliere i log di Nginx, le statistiche da pg_stat_statements e di conservare dati storici di Prometheus. Non ci \u00e8 piaciuto Influx, poich\u00e9 ogni tanto iniziava a consumare una grande quantit\u00e0 di memoria e crollava. Inoltre, volevamo raggruppare le richieste per remote_addr, mentre il raggruppamento in questo DB \u00e8 solo per tag. I tag costano (memoria), il loro numero \u00e8 limitato.<\/p>\n

    <\/p>\n

    Abbiamo ricominciato le ricerche. Avevamo bisogno di una base analitica con un consumo minimo di risorse, preferibilmente con compressione dei dati su disco.<\/p>\n

    <\/p>\n

    Clickhouse soddisfa tutti questi criteri, e non ci siamo mai pentiti della scelta. Non scriviamo volumi di dati eccezionali in esso (il numero di inserimenti \u00e8 di circa cinquemila al minuto).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic \u00e8 storicamente con noi, poich\u00e9 era la scelta del cliente. Lo utilizziamo come APM.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Utilizziamo Zabbix esclusivamente per il monitoraggio della Black Box di varie API.<\/p>\n

    <\/p>\n

    Definizione dell'approccio al monitoraggio<\/h2>\n

    <\/p>\n

    Volevamo decomporre il compito e in tal modo sistematizzare l'approccio al monitoraggio.<\/p>\n

    <\/p>\n

    Per questo ho suddiviso il nostro sistema nei seguenti livelli:<\/p>\n

    <\/p>\n