{"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 al Centro Tecnologie Avanzate e mi occupo di amministrazione di sistema. Un mese fa si \u00e8 conclusa la nostra conferenza aziendale, dove abbiamo condiviso esperienze con la comunit\u00e0 IT della nostra citt\u00e0. Ho parlato del monitoraggio delle applicazioni web. Il materiale era rivolto a un pubblico di livello junior o middle, che non ha strutturato questo processo da zero.<\/p>\n

<\/p>\n

\"Come<\/p>\n

<\/p>\n

Il fondamento di qualsiasi sistema di monitoraggio \u00e8 risolvere le esigenze del business. Monitorare solo per farlo non interessa a nessuno. E cosa desidera il business? Che tutto funzioni rapidamente e senza errori. Il business vuole proattivit\u00e0, che possiamo identificare i problemi nel servizio e risolverli nel minor tempo possibile. Queste, in sostanza, sono le sfide che ho affrontato nell'ultimo anno su un progetto di uno dei nostri clienti.<\/p>\n

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

Informazioni sul progetto<\/h2>\n

<\/p>\n

Il progetto \u00e8 uno dei pi\u00f9 grandi programmi di fidelizzazione nel paese. Aiutiamo le catene di vendita al dettaglio a incrementare la frequenza delle vendite attraverso vari strumenti di marketing come le carte fedelt\u00e0. In totale, il progetto comprende 14 applicazioni che funzionano su dieci server.<\/p>\n

<\/p>\n

Durante il processo di colloqui ho notato pi\u00f9 volte che gli amministratori non sempre approcciano correttamente il monitoraggio delle applicazioni web: molti si fermano ancora alle metriche del sistema operativo e monitorano sporadicamente i servizi.<\/p>\n

<\/p>\n

Nel mio caso, in precedenza il sistema di monitoraggio del cliente si basava su Icinga. Questo non risolveva i problemi menzionati sopra. Spesso il cliente ci segnalava i problemi e frequentemente ci mancavano i dati per risalire alla causa.<\/p>\n

<\/p>\n

Inoltre, era chiaro che lo sviluppo futuro di questo sistema non era promettente. Penso che chi conosca Icinga capir\u00e0. Cos\u00ec, abbiamo deciso di riprogettare completamente il sistema di monitoraggio delle applicazioni web per il 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'enorme quantit\u00e0 di metriche disponibili. Nel nostro caso sono 60.000. Ovviamente, va notato che la stragrande maggioranza di esse non viene utilizzata (probabilmente circa il 95%). D'altra parte, sono tutte relativamente economiche. Per noi \u00e8 una situazione completamente diversa rispetto a Icinga, che utilizzavamo in precedenza. In essa l'aggiunta di metriche era particolarmente dolorosa: quelle esistenti costavano care (basta guardare il codice sorgente di qualsiasi plugin). Qualsiasi 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 RAM, il 15% di un core e una manciata di IOPS. Certo, occorre avviare gli esportatori di metriche, ma sono tutti scritti in Go e non sono neppure particolarmente affamati di risorse. Non credo che oggi sia un problema. <\/li>\n
  3. Consente la transizione a Kubernetes. Considerando i piani del cliente, la scelta \u00e8 ovvia. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    In precedenza non raccogevamo n\u00e9 trattavamo i log. Gli svantaggi sono evidenti a tutti. Abbiamo scelto ELK, avendo gi\u00e0 esperienza con questo sistema. Conserviamo solo i log delle applicazioni. I criteri principali per la scelta sono stati la ricerca full-text e la sua velocit\u00e0.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Inizialmente la nostra scelta era caduta su InfluxDB. Eravamo consapevoli della necessit\u00e0 di raccogliere i log di Nginx, le statistiche da pg_stat_statements e conservare i dati storici di Prometheus. Non ci piaceva Influx, poich\u00e9 occasionalmente iniziava a consumare grandi quantit\u00e0 di memoria e crollava. Inoltre, volevamo raggruppare le richieste per remote_addr, ma il raggruppamento in questo DBMS \u00e8 solo per tag. I tag sono costosi (dal punto di vista della memoria) e il loro numero \u00e8 limitato.<\/p>\n

    <\/p>\n

    Abbiamo iniziato a cercare di nuovo. Avevamo bisogno di una base analitica con un consumo minimo di risorse e, preferibilmente, con compressione dei dati sul disco.<\/p>\n

    <\/p>\n

    Clickhouse soddisfa tutti questi criteri e non ci siamo mai pentiti della scelta. Non scriviamo volumi eccezionali di dati 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, essendo stata la scelta del cliente. Lo usiamo come APM.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

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

    <\/p>\n

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

    <\/p>\n

    Desideravamo decomporre il compito e sistematizzare cos\u00ec l'approccio al monitoraggio.<\/p>\n

    <\/p>\n

    Per fare ci\u00f2, ho suddiviso il nostro sistema nei seguenti livelli:<\/p>\n

    <\/p>\n