Zabbix é um sistema de monitoramento. Como qualquer outro sistema, ele enfrenta três problemas principais de todos os sistemas de monitoramento: coleta e processamento de dados, armazenamento de histórico e limpeza.
As etapas de recebimento, processamento e registro de dados levam tempo. Não muito, mas para um sistema grande isso pode resultar em grandes atrasos. O problema de armazenamento é um problema de acesso a dados. Eles são usados para relatórios, verificações e gatilhos. As latências no acesso aos dados também afetam o desempenho. Quando os bancos de dados crescem, os dados irrelevantes precisam ser excluídos. A remoção é uma operação difícil que também consome alguns recursos.
Problemas de atrasos durante a coleta e armazenamento no Zabbix são resolvidos através do cache: vários tipos de caches, cache no banco de dados. Para resolver o terceiro problema, o cache não é adequado, então o Zabbix usou o TimescaleDB. Ele vai te contar sobre isso Andrey Gushchin - Engenheiro de Suporte Técnico . Andrey apoia Zabbix há mais de 6 anos e tem experiência direta com performance.
Como funciona o TimescaleDB, que desempenho ele pode oferecer em comparação com o PostgreSQL normal? Qual o papel do Zabbix no banco de dados TimescaleDB? Como começar do zero e como migrar do PostgreSQL e qual configuração tem melhor desempenho? Sobre tudo isso sob o corte.
Desafios de produtividade
Cada sistema de monitoramento enfrenta desafios específicos de desempenho. Falarei sobre três deles: coleta e processamento de dados, armazenamento e limpeza de histórico.
Coleta e processamento rápido de dados. Um bom sistema de monitoramento deve receber rapidamente todos os dados e processá-los de acordo com expressões de gatilho – de acordo com seus critérios. Após o processamento, o sistema também deve salvar rapidamente esses dados no banco de dados para uso posterior.
Armazenamento de histórico. Um bom sistema de monitoramento deve armazenar o histórico em um banco de dados e fornecer fácil acesso às métricas. O histórico é necessário para ser usado em relatórios, gráficos, acionadores, limites e itens de dados de alerta calculados.
Limpando histórico. Às vezes chega um dia em que você não precisa armazenar métricas. Por que você precisa de dados que foram coletados há 5 anos, um mês ou dois: alguns nós foram excluídos, alguns hosts ou métricas não são mais necessários porque estão desatualizados e não são mais coletados. Um bom sistema de monitoramento deve armazenar dados históricos e excluí-los de tempos em tempos para que o banco de dados não cresça.
A limpeza de dados obsoletos é um problema crítico que afeta bastante o desempenho do banco de dados.
Cache no Zabbix
No Zabbix, a primeira e a segunda chamadas são resolvidas usando cache. RAM é usada para coletar e processar dados. Para armazenamento – histórico em gatilhos, gráficos e elementos de dados calculados. No lado do banco de dados há algum cache para seleções básicas, por exemplo, gráficos.
O cache no lado do próprio servidor Zabbix é:
- Cache de configuração;
- ValorCache;
- HistóricoCache;
- TendênciasCache.
Vamos considerá-los em mais detalhes.
Cache de configuração
Este é o cache principal onde armazenamos métricas, hosts, itens de dados, gatilhos - tudo o que precisamos para pré-processamento e coleta de dados.
Tudo isso fica armazenado no ConfigurationCache para não criar consultas desnecessárias no banco de dados. Após a inicialização do servidor, atualizamos esse cache, criamos e atualizamos periodicamente as configurações.
Coleta de dados
O diagrama é bastante grande, mas o principal nele é colecionadores. Estes são vários “pollers” - processos de montagem. Eles são responsáveis por diferentes tipos de montagem: coletam dados via SNMP, IPMI e transferem tudo para o Pré-Processamento.
Os coletores estão destacados em laranja.
O Zabbix calculou itens de agregação necessários para agregar verificações. Se os tivermos, buscaremos os dados deles diretamente do ValueCache.
Pré-processamento HistoryCache
Todos os coletores usam ConfigurationCache para receber trabalhos. Em seguida, eles os transferem para o Pré-processamento.
O PreProcessing usa o ConfigurationCache para receber etapas do PreProcessing. Ele processa esses dados de várias maneiras.
Após processar os dados usando PreProcessing, nós os salvamos no HistoryCache para processamento. Isso encerra a coleta de dados e passamos para o processo principal no Zabbix - sincronizador de histórico, por se tratar de uma arquitetura monolítica.
Nota: O pré-processamento é uma operação bastante difícil. Com a versão 4.2, ele foi movido para proxy. Se você tiver um Zabbix muito grande, com um grande número de elementos de dados e frequência de coleta, isso tornará o trabalho muito mais fácil.
ValueCache, histórico e cache de tendências
O sincronizador de histórico é o principal processo que processa atomicamente cada elemento de dados, ou seja, cada valor.
O sincronizador de histórico obtém valores do HistoryCache e verifica a configuração quanto à presença de gatilhos para cálculos. Se existirem, ele calcula.
O sincronizador de histórico cria um evento, escalonamento para criar alertas, se exigido pela configuração, e registros. Se houver gatilhos para processamento posterior, ele armazena esse valor no ValueCache para não acessar a tabela de histórico. É assim que o ValueCache é preenchido com dados necessários para calcular gatilhos e elementos calculados.
O sincronizador de histórico grava todos os dados no banco de dados e no disco. O processo de processamento termina aqui.
Cache no banco de dados
No lado do banco de dados existem vários caches quando você deseja visualizar gráficos ou relatórios de eventos:
Innodb_buffer_poolno lado do MySQL;shared_buffersno lado PostgreSQL;effective_cache_sizedo lado da Oracle;shared_poolno lado do DB2.
Existem muitos outros caches, mas estes são os principais para todos os bancos de dados. Eles permitem armazenar dados na RAM que geralmente são necessários para consultas. Eles têm suas próprias tecnologias para isso.
O desempenho do banco de dados é crítico
O servidor Zabbix coleta dados constantemente e os grava. Quando reiniciado, ele também lê o histórico para preencher o ValueCache. Usa scripts e relatórios API Zabbix, que é construído em uma interface da Web. A API Zabbix acessa o banco de dados e recupera os dados necessários para gráficos, relatórios, listas de eventos e problemas mais recentes.
Para visualização - grafana. Esta é uma solução popular entre nossos usuários. Ele pode enviar solicitações diretamente através da API do Zabbix e para o banco de dados, e cria uma certa competição pelo recebimento de dados. Portanto, é necessário um ajuste mais preciso e melhor do banco de dados para corresponder à entrega rápida de resultados e testes.
Governanta
O terceiro desafio de desempenho no Zabbix é limpar o histórico usando o Housekeeper. Segue todas as configurações - os elementos de dados indicam quanto tempo armazenar a dinâmica das mudanças (tendências) em dias.
Calculamos o TrendsCache instantaneamente. Quando os dados chegam, nós os agregamos por uma hora e os registramos em tabelas para a dinâmica das mudanças de tendência.
O Housekeeper inicia e apaga informações do banco de dados usando os habituais “selects”. Isso nem sempre é eficaz, como pode ser visto nos gráficos de desempenho dos processos internos.
O gráfico vermelho mostra que o sincronizador do histórico está constantemente ocupado. O gráfico laranja na parte superior é o Housekeeper, que está em constante execução. Ele espera que o banco de dados exclua todas as linhas especificadas.
Quando você deve desativar o Housekeeper? Por exemplo, existe um “Item ID” e você precisa deletar as últimas 5 mil linhas dentro de um determinado tempo. Claro, isso acontece por índice. Mas geralmente o conjunto de dados é muito grande e o banco de dados ainda lê o disco e o coloca no cache. Esta é sempre uma operação muito cara para o banco de dados e, dependendo do tamanho do banco de dados, pode levar a problemas de desempenho.
A governanta é fácil de desativar. Na interface Web existe uma configuração em “Administração geral” para Governanta. Desativamos o Housekeeping interno para o histórico de tendências internas e ele não o gerencia mais.
A governanta foi desligada, os gráficos ficaram nivelados - que problemas poderia haver neste caso e o que poderia ajudar a resolver o terceiro desafio de desempenho?
Particionamento - particionamento ou particionamento
Normalmente, o particionamento é configurado de maneira diferente em cada banco de dados relacional listado. Cada um tem sua própria tecnologia, mas são semelhantes em geral. A criação de uma nova partição geralmente leva a certos problemas.
Normalmente, as partições são configuradas dependendo da “configuração” - a quantidade de dados criados em um dia. Via de regra o Particionamento é emitido em um dia, este é o mínimo. Para tendências de um novo lote - 1 mês.
Os valores podem mudar caso o “setup” seja muito grande. Se uma “configuração” pequena é de até 5 nvps (novos valores por segundo), uma média é de 000 a 5, então uma grande está acima de 000 nvps. Estas são instalações grandes e muito grandes que requerem uma configuração cuidadosa do banco de dados.
Em instalações muito grandes, um período de um dia pode não ser o ideal. Tenho visto partições MySQL de 40 GB ou mais por dia. Esta é uma quantidade muito grande de dados que pode causar problemas e precisa ser reduzida.
O que o particionamento oferece?
Tabelas de particionamento. Freqüentemente, são arquivos separados no disco. O plano de consulta seleciona uma partição de forma mais otimizada. Normalmente o particionamento é usado por intervalo - isso também vale para o Zabbix. Usamos “timestamp” lá – tempo desde o início da era. Esses são números comuns para nós. Você define o início e o fim do dia - esta é uma partição.
Remoção rápida - DELETE. Um arquivo/subtabela é selecionado, em vez de uma seleção de linhas para exclusão.
Acelera significativamente a recuperação de dados SELECT - usa uma ou mais partições, em vez da tabela inteira. Se você estiver acessando dados com dois dias de idade, eles serão recuperados do banco de dados mais rapidamente porque você só precisa carregar um arquivo no cache e devolvê-lo, não uma tabela grande.
Muitas vezes, muitos bancos de dados também são acelerados INSERT — inserções na tabela filho.
Escala de tempoDB
Para a versão 4.2, voltamos nossa atenção para TimescaleDB. Esta é uma extensão para PostgreSQL com interface nativa. A extensão funciona de forma eficaz com dados de séries temporais, sem perder os benefícios dos bancos de dados relacionais. TimescaleDB também particiona automaticamente.
TimescaleDB tem um conceito hipertabela (hipertabela) que você cria. Contém pedaços - partições. Chunks são fragmentos de hipertabela gerenciados automaticamente que não afetam outros fragmentos. Cada pedaço tem seu próprio intervalo de tempo.
TimescaleDB x PostgreSQL
TimescaleDB funciona de forma muito eficiente. Os fabricantes da extensão afirmam usar um algoritmo de processamento de consultas mais correto, em particular inserts . À medida que o tamanho da inserção do conjunto de dados aumenta, o algoritmo mantém um desempenho constante.
Após 200 milhões de linhas, o PostgreSQL geralmente começa a cair significativamente e perde desempenho para 0. O TimescaleDB permite inserir “inserções” com eficiência para qualquer quantidade de dados.
Instalação
Instalar o TimescaleDB é bastante fácil para qualquer pacote. EM tudo é descrito em detalhes - depende dos pacotes oficiais do PostgreSQL. TimescaleDB também pode ser construído e compilado manualmente.
Para o banco de dados Zabbix simplesmente ativamos a extensão:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Você ativa extension e crie-o para o banco de dados Zabbix. A última etapa é criar uma hipertabela.
Migrando tabelas de histórico para TimescaleDB
Existe uma função especial para isso create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
A função possui três parâmetros. Primeiro - tabela no banco de dados, para o qual você precisa criar uma hipertabela. Segundo - campo, de acordo com o qual você precisa criar chunk_time_interval — intervalo de pedaços de partição a serem usados. No meu caso, o intervalo é de um dia - 86.
Terceiro parâmetro - migrate_data. Se você definir true, todos os dados atuais serão transferidos para blocos pré-criados. eu mesmo usei migrate_data. Eu tinha cerca de 1 TB, o que demorou mais de uma hora. Mesmo em alguns casos, durante o teste, excluí dados históricos de tipos de caracteres que não eram necessários para armazenamento, para não transferi-los.
Último passo - UPDATE: em db_extension стР° РІРёРј timescaledbpara que o banco de dados entenda que esta extensão existe. O Zabbix o ativa e usa corretamente a sintaxe e as consultas ao banco de dados - recursos necessários para o TimescaleDB.
Configuração de hardware
Usei dois servidores. Primeiro - Máquina VMware. É bem pequeno: 20 processadores Intel® Xeon® CPU E5-2630 v 4 a 2.20 GHz, 16 GB de RAM e um SSD de 200 GB.
Instalei o PostgreSQL 10.8 nele com o sistema operacional Debian 10.8-1.pgdg90+1 e o sistema de arquivos xfs. Configurei tudo minimamente para usar esse banco de dados específico, menos o que o próprio Zabbix irá usar.
Na mesma máquina havia um servidor Zabbix, PostgreSQL e agentes de carga. Eu tinha 50 agentes ativos que estavam usando LoadableModulepara gerar resultados diferentes muito rapidamente: números, strings. Enchi o banco de dados com muitos dados.
Inicialmente a configuração continha 5 elementos dados por host. Quase todos os elementos continham um gatilho para torná-los semelhantes a instalações reais. Em alguns casos houve mais de um gatilho. Para um nó da rede havia 3-000 gatilhos.
Intervalo de atualização de item de dados - segundo 4-7. Regulei a carga em si usando não apenas 50 agentes, mas adicionando mais. Além disso, usando elementos de dados, ajustei dinamicamente a carga e reduzi o intervalo de atualização para 4 s.
PostgreSQL. 35 nvps
Minha primeira execução neste hardware foi em PostgreSQL puro - 35 mil valores por segundo. Como você pode ver, a inserção de dados leva frações de segundo - tudo é bom e rápido. A única coisa é que um disco SSD de 200 GB fica cheio rapidamente.
Este é um painel padrão de desempenho do servidor Zabbix.
O primeiro gráfico azul é o número de valores por segundo. O segundo gráfico à direita é o carregamento dos processos de construção. A terceira é carregar processos de construção internos: sincronizadores de histórico e Housekeeper, que já estão em execução aqui há algum tempo.
O quarto gráfico mostra o uso do HistoryCache. Este é um tipo de buffer antes de inserir no banco de dados. O quinto gráfico verde mostra o uso do ValueCache, ou seja, quantos acertos do ValueCache para gatilhos são vários milhares de valores por segundo.
PostgreSQL. 50 nvps
Depois aumentei a carga para 50 mil valores por segundo no mesmo hardware.
Ao carregar do Housekeeper, a inserção de 10 mil valores demorava de 2 a 3 segundos.
A governanta já está começando a atrapalhar o trabalho.
O terceiro gráfico mostra que, em geral, a carga nos trappers e sincronizadores de histórico ainda está em 60%. No quarto gráfico, o HistoryCache já está começando a preencher ativamente durante a operação do Housekeeper. Está 20% cheio, o que equivale a cerca de 0,5 GB.
PostgreSQL. 80 nvps
Depois aumentei a carga para 80 mil valores por segundo. São aproximadamente 400 mil elementos de dados e 280 mil gatilhos.
O custo de carregamento de trinta sincronizadores de histórico já é bastante alto.
Também aumentei vários parâmetros: sincronizadores de histórico, caches.
No meu hardware, o carregamento dos sincronizadores de histórico aumentou ao máximo. O HistoryCache encheu-se rapidamente de dados - os dados para processamento foram acumulados no buffer.
Durante todo esse tempo observei como o processador, a RAM e outros parâmetros do sistema eram usados e descobri que a utilização do disco estava no máximo.
Eu consegui o uso capacidades máximas de disco neste hardware e nesta máquina virtual. Com tanta intensidade, o PostgreSQL começou a liberar dados de forma bastante ativa e o disco não tinha mais tempo para gravar e ler.
Segundo servidor
Peguei outro servidor, que já tinha 48 processadores e 128 GB de RAM. Eu ajustei - configurei para 60 sincronizadores de histórico e obtive um desempenho aceitável.
Na verdade, esse já é o limite de produtividade onde algo precisa ser feito.
Escala de tempoDB. 80 nvps
Minha principal tarefa é testar os recursos do TimescaleDB em relação à carga do Zabbix. 80 mil valores por segundo é muito, a frequência de coleta de métricas (exceto Yandex, é claro) e uma “configuração” bastante grande.
Há uma queda em cada gráfico – esta é precisamente a migração de dados. Após falhas no servidor Zabbix, o perfil de carregamento do sincronizador de histórico mudou bastante – caiu três vezes.
TimescaleDB permite inserir dados quase 3 vezes mais rápido e usar menos HistoryCache.
Conseqüentemente, você receberá os dados em tempo hábil.
Escala de tempoDB. 120 nvps
Depois aumentei o número de elementos de dados para 500 mil.A principal tarefa foi testar as capacidades do TimescaleDB - recebi um valor calculado de 125 mil valores por segundo.
Esta é uma “configuração” funcional que pode funcionar por muito tempo. Mas como meu disco tinha apenas 1,5 TB, enchi-o em alguns dias.
O mais importante é que ao mesmo tempo foram criadas novas partições TimescaleDB.
Isso é completamente imperceptível para o desempenho. Quando partições são criadas no MySQL, por exemplo, tudo é diferente. Isso geralmente acontece à noite porque bloqueia a inserção geral, trabalha com tabelas e pode gerar degradação do serviço. Este não é o caso do TimescaleDB.
Como exemplo, mostrarei um gráfico de muitos na comunidade. Na imagem, o TimescaleDB está habilitado, graças ao qual a carga de uso de io.weight no processador diminuiu. O uso de elementos de processos internos também diminuiu. Além disso, esta é uma máquina virtual comum em discos panquecas comuns, não um SSD.
Descobertas
TimescaleDB é uma boa solução para pequenas “instalações”, que afetam o desempenho do disco. Isso permitirá que você continue trabalhando bem até que o banco de dados seja migrado para o hardware o mais rápido possível.
TimescaleDB é fácil de configurar, oferece ganhos de desempenho, funciona bem com Zabbix e tem vantagens sobre o PostgreSQL.
Se você usa PostgreSQL e não planeja alterá-lo, recomendo use PostgreSQL com a extensão TimescaleDB em conjunto com Zabbix. Esta solução funciona de forma eficaz até uma “configuração” média.
Quando dizemos “alto desempenho” queremos dizer . Você não terá que esperar muito para aprender sobre as tecnologias e práticas que permitem que os serviços atendam milhões de usuários. Lista para 7 e 8 de novembro já compilamos, mas aqui mais pode ser sugerido.
Assine nosso и , na qual revelamos as características da próxima conferência e descobrimos como aproveitá-la ao máximo.
Fonte: habr.com