Ola a todos! No seu último artigo Escribín sobre a organización dun sistema de monitorización modular para a arquitectura de microservizos. Nada se para, o noso proxecto está en constante crecemento, e tamén o número de métricas almacenadas. Como organizamos a transición de Graphite+Whisper a Graphite+ClickHouse en condicións de alta carga, lea sobre as expectativas desta e os resultados da migración baixo o corte.

Antes de contarvos como organizamos a transición do almacenamento de métricas en Graphite+Whisper a Graphite+ClickHouse, gustaríame darvos información sobre os motivos para tomar esa decisión e sobre as desvantaxes de Whisper coas que convivimos durante moito tempo.

Problemas de grafito+susurro

1. Alta carga no subsistema de discos

No momento da transición, chegaban aproximadamente 1.5 millóns de métricas por minuto. Con tal fluxo, a utilización do disco nos servidores foi de ~30%. En xeral, isto era bastante aceptable: todo funcionaba de forma estable, escribíase rapidamente, líase rapidamente... Ata que un dos equipos de desenvolvemento lanzou unha nova función e comezou a enviarnos 10 millóns de métricas por minuto. Foi entón cando o subsistema de disco se endureceu e vimos unha utilización do 100%. O problema resolveuse rapidamente, pero quedou un residuo.

2. Falta de replicación e coherencia

O máis probable é que, como todos os que usan ou usan Graphite+Whisper, vertemos o mesmo fluxo de métricas en varios servidores de Graphite á vez para crear tolerancia a fallos. E non houbo problemas especiais con isto, ata o momento en que un dos servidores fallou por algún motivo. Ás veces conseguimos recoller un servidor caído o suficientemente rápido e carbon-c-relay conseguiu cargar nel as métricas da súa caché, pero ás veces non. E despois houbo un buraco nas métricas, que enchemos con rsync. O procedemento foi bastante longo. A única graza salvadora foi que isto ocorreu moi poucas veces. Tamén tomamos periodicamente un conxunto de métricas aleatorias e comparámolas con outras do mesmo tipo en nós veciños do clúster. En preto do 5% dos casos, varios valores eran diferentes, polo que non estabamos moi contentos.

3. Gran pegada

Dado que escribimos en Graphite non só infraestrutura, senón tamén métricas empresariais (e agora tamén métricas de Kubernetes), moitas veces temos unha situación na que a métrica contén só uns poucos valores e o ficheiro .wsp créase tendo en conta toda a retención. período e ocupa unha cantidade de espazo previamente asignada, que para nós era de ~2 MB. O problema agrávase aínda máis polo feito de que ao longo do tempo aparecen moitos ficheiros similares e, ao crear informes sobre eles, a lectura de puntos baleiros leva moito tempo e recursos.

Gustaríame sinalar inmediatamente que os problemas descritos anteriormente pódense tratar mediante varios métodos e con distintos graos de eficacia, pero cantos máis datos comeza a recibir, máis empeoran.

Tendo todo o anterior (tendo en conta o anterior Artigo), así como un aumento constante no número de métricas recibidas, o desexo de transferir todas as métricas a un intervalo de almacenamento de 30 segundos. (ata 10 segundos se é necesario), decidimos probar Graphite+ClickHouse como unha alternativa prometedora a Whisper.

Grafito+ClickHouse. Expectativas

Visitando varias reunións dos mozos de Yandex, lendo un par de artigos sobre Habré, despois de revisar a documentación e atopar compoñentes sensatos para vincular ClickHouse en Graphite, decidimos tomar medidas.

Gustaríame recibir o seguinte:

reducir a utilización do subsistema do disco do 30% ao 5%;
reducir a cantidade de espazo ocupado de 1 TB a 100 GB;
poder recibir 100 millóns de métricas por minuto no servidor;
replicación de datos e tolerancia a fallos fóra da caixa;
non se sente neste proxecto durante un ano e faga a transición nun prazo razoable;
cambiar sen tempo de inactividade.

Bastante ambicioso, non?

Grafito+ClickHouse. Compoñentes

Para recibir datos a través do protocolo Graphite e gravalos posteriormente en ClickHouse, seleccionei carbon-clickhouse (golang).

A última versión de ClickHouse, a versión estable 1.1.54253, foi escollida como base de datos para almacenar series temporais. Houbo problemas ao traballar con el: unha montaña de erros verteu nos rexistros e non estaba totalmente claro que facer con eles. En discusión con Roman Lomonosov (autor de carbon-clickhouse, graphite-clickhouse e moitos, moitos máis) escolleuse o máis vello versión 1.1.54236. Os erros desapareceron - todo comezou a funcionar cun estrondo.

Seleccionouse para ler datos de ClickHouse grafito-clickhouse (golang). Como API para Graphite − carbonapi (golang). ClickHouse utilizouse para organizar a replicación entre táboas gardián. Para as métricas de enrutamento, deixamos ao noso querido relé de carbono-c (C) (ver artigo anterior).

Grafito+ClickHouse. Estrutura da táboa

"grafito" é unha base de datos que creamos para monitorizar táboas.

“graphite.metrics” - táboa co motor ReplicatedReplacingMergeTree (replicado Substituíndo MergeTree). Esta táboa almacena os nomes das métricas e as rutas a elas.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

“graphite.data” - táboa co motor ReplicatedGraphiteMergeTree (replicado GraphiteMergeTree). Esta táboa almacena os valores métricos.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics" é unha táboa cuberta condicionalmente co motor ReplicatedReplacingMergeTree. Esta táboa rexistra os nomes de todas as métricas que se atoparon durante o día. Os motivos da súa creación descríbense na sección "Problemas" ao final deste artigo.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

“graphite.data_stat”: unha táboa cuberta segundo a condición, co motor ReplicatedAggregatingMergeTree (replicado AgregandoMergeTree). Esta táboa rexistra o número de métricas entrantes, divididas en 4 niveis de anidamento.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Grafito+ClickHouse. Diagrama de interacción de compoñentes

Grafito+ClickHouse. Migración de datos

Como lembramos das expectativas deste proxecto, a transición a ClickHouse debería realizarse sen tempo de inactividade; en consecuencia, tivemos que cambiar dalgunha maneira todo o noso sistema de vixilancia ao novo almacenamento da forma máis transparente posible para os nosos usuarios.
Así o fixemos.

Engadiuse unha regra a carbon-c-relay para enviar un fluxo adicional de métricas ao carbon-clickhouse dun dos servidores que participan na replicación das táboas ClickHouse.
Escribimos un pequeno script en Python que, usando a biblioteca whisper-dump, lía todos os ficheiros .wsp do noso almacenamento e enviaba estes datos ao carbon-clickhouse descrito anteriormente en 24 fíos. O número de valores métricos aceptados en carbon-clickhouse alcanzou os 125 millóns/min, e ClickHouse nin sequera suou.
Creamos unha fonte de datos separada en Grafana para depurar as funcións utilizadas nos paneis existentes. Identificamos unha lista de funcións que utilizamos, pero non se implementaron en carbonapi. Engadimos estas funcións e enviamos PR aos autores de carbonapi (especial agradecemento a eles).
Para cambiar a carga de lectura na configuración do equilibrador, cambiamos os puntos finais de graphite-api (interface API para Graphite+Whisper) a carbonapi.

Grafito+ClickHouse. resultados

reduciu a utilización do subsistema do disco do 30% ao 1%;
reduciu a cantidade de espazo ocupado de 1 TB a 300 GB;
temos a capacidade de recibir 125 millóns de métricas por minuto no servidor (picos no momento da migración);
transferiu todas as métricas a un intervalo de almacenamento de trinta segundos;
replicación de datos recibidos e tolerancia a fallos;
cambiou sen tempo de inactividade;
Levou unhas 7 semanas completalo todo.

Grafito+ClickHouse. Problemas

No noso caso, houbo algunhas trampas. Isto é o que atopamos despois da transición.

ClickHouse non sempre rele as configuracións sobre a marcha; ás veces é preciso reiniciala. Por exemplo, no caso da descrición do clúster de zookeeper na configuración de ClickHouse, non se utilizou ata que se reiniciou o servidor clickhouse.
As solicitudes ClickHouse grandes non pasaron, polo que en graphite-clickhouse a nosa cadea de conexión ClickHouse ten este aspecto:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse lanza moitas veces novas versións de versións estables; poden conter sorpresas: teña coidado.
Os contedores creados de forma dinámica en kubernetes envían un gran número de métricas cunha vida útil curta e aleatoria. Non hai moitos puntos para tales métricas e non hai problemas co espazo. Pero ao crear consultas, ClickHouse recolle un gran número destas mesmas métricas da táboa de "métricas". No 90% dos casos, non hai datos sobre eles máis aló da xanela (24 horas). Pero o tempo pásase buscando estes datos na táboa de "datos" e, finalmente, chega a un tempo de espera. Para solucionar este problema, comezamos a manter unha vista separada con información sobre as métricas que se atopaban durante o día. Así, ao crear informes (gráficos) para contedores creados de forma dinámica, consultamos só aquelas métricas que se atopaban nunha determinada xanela, e non durante todo o tempo, o que acelerou significativamente a construción de informes sobre eles. Para a solución descrita anteriormente, recollín grafito-clickhouse (garfo), que inclúe a implementación de traballar coa táboa date_metrics.

Grafito+ClickHouse. Etiquetas

Coa versión 1.1.0 Graphite fíxose oficial etiquetas de soporte. E estamos a pensar activamente en que e como facer para apoiar esta iniciativa na pila de grafito+clickhouse.

Grafito+ClickHouse. Detector de anomalías

Baseándonos na infraestrutura descrita anteriormente, implementamos un prototipo de detector de anomalías e funciona. Pero máis sobre el no seguinte artigo.

Subscríbete, preme a frecha cara arriba e sé feliz!

Fonte: www.habr.com

Almacenamento de métricas: como cambiamos de Graphite+Whisper a Graphite+ClickHouse