{"id":38927,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix \u00e9 um sistema de monitoramento. Como qualquer outro sistema, ele enfrenta tr\u00eas problemas principais de todos os sistemas de monitoramento: coleta e processamento de dados, armazenamento de hist\u00f3rico e sua limpeza.<\/p>\n<p>As etapas de recebimento, processamento e grava\u00e7\u00e3o de dados consomem tempo. Um pouco, mas para um grande sistema isso pode resultar em grandes atrasos. O problema de armazenamento \u00e9 uma quest\u00e3o de acesso aos dados. Eles s\u00e3o usados para relat\u00f3rios, verifica\u00e7\u00f5es e gatilhos. Os atrasos no acesso aos dados tamb\u00e9m afetam o desempenho. Quando os bancos de dados crescem, \u00e9 necess\u00e1rio remover dados obsoletos. A remo\u00e7\u00e3o \u00e9 uma opera\u00e7\u00e3o pesada que tamb\u00e9m consome parte dos recursos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOs problemas de atrasos na coleta e no armazenamento no Zabbix s\u00e3o resolvidos com cache: v\u00e1rios tipos de caches, cache no banco de dados. Para resolver o terceiro problema, o cache n\u00e3o \u00e9 adequado, por isso o Zabbix utiliza o TimescaleDB. Sobre isso falar\u00e1 <strong>Andrey Gushchin<\/strong> \u2014 engenheiro de suporte t\u00e9cnico <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrey est\u00e1 no suporte do Zabbix h\u00e1 mais de 6 anos e lida diretamente com o desempenho.<\/p>\n<p>Como funciona o TimescaleDB, que desempenho pode oferecer em compara\u00e7\u00e3o com o PostgreSQL comum? Qual \u00e9 o papel do Zabbix para o banco de dados TimescaleDB? Como iniciar do zero e como migrar do PostgreSQL, e qual configura\u00e7\u00e3o oferece o melhor desempenho? Tudo isso est\u00e1 a seguir.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Por que no hosting comum a administra\u00e7\u00e3o do PrestaShop \u00e9 lenta, e no seu n\u00e3o \u00e9?\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Desafios de desempenho<\/h2>\n<p>\nTodo sistema de monitoramento enfrenta desafios de desempenho espec\u00edficos. Vou falar sobre tr\u00eas deles: coleta e processamento de dados, armazenamento, limpeza de hist\u00f3rico.<\/p>\n<p><strong>Coleta e processamento de dados r\u00e1pidos. <\/strong>Um bom sistema de monitoramento deve coletar rapidamente todos os dados e process\u00e1-los de acordo com express\u00f5es de gatilho \u2014 de acordo com seus crit\u00e9rios. Ap\u00f3s o processamento, o sistema tamb\u00e9m deve salvar rapidamente esses dados no banco de dados para uso posterior.<\/p>\n<p><strong>Armazenamento de hist\u00f3rico. <\/strong>Um bom sistema de monitoramento deve armazenar o hist\u00f3rico no banco de dados e fornecer acesso f\u00e1cil \u00e0s m\u00e9tricas. O hist\u00f3rico \u00e9 necess\u00e1rio para ser utilizado em relat\u00f3rios, gr\u00e1ficos, gatilhos, limites e elementos de dados calculados para alertas.<\/p>\n<p><strong>Limpeza de hist\u00f3rico. <\/strong>\u00c0s vezes, chega o dia em que voc\u00ea n\u00e3o precisa mais armazenar m\u00e9tricas. Para que voc\u00ea precisa de dados coletados h\u00e1 5 anos, um ou dois meses: alguns n\u00f3s foram removidos, alguns hosts ou m\u00e9tricas j\u00e1 n\u00e3o s\u00e3o necess\u00e1rios porque se tornaram obsoletos e deixaram de ser coletados. Um bom sistema de monitoramento deve armazenar dados hist\u00f3ricos e de tempos em tempos exclu\u00ed-los para evitar o crescimento excessivo do banco de dados.<\/p>\n<blockquote><p>A limpeza de dados obsoletos \u00e9 uma quest\u00e3o cr\u00edtica que afeta significativamente o desempenho do banco de dados.<\/p><\/blockquote>\n<p><\/p>\n<h2>Cache no Zabbix<\/h2>\n<p>\nNo Zabbix, a primeira e a segunda chamadas s\u00e3o resolvidas por meio de cache. A mem\u00f3ria RAM \u00e9 utilizada para coletar e processar dados. Para armazenamento, utiliza-se a hist\u00f3ria em gatilhos, gr\u00e1ficos e elementos de dados calculados. Do lado do banco de dados, h\u00e1 um certo caching para as consultas principais, como gr\u00e1ficos.<\/p>\n<p>O cache no pr\u00f3prio servidor Zabbix \u00e9:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nVamos analis\u00e1-los em mais detalhes.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nEste \u00e9 o cache principal onde armazenamos m\u00e9tricas, hosts, elementos de dados, gatilhos - tudo o que \u00e9 necess\u00e1rio para o PreProcessing e para a coleta de dados.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTudo isso \u00e9 mantido no ConfigurationCache para evitar fazer requisi\u00e7\u00f5es desnecess\u00e1rias ao banco de dados. Ap\u00f3s a inicializa\u00e7\u00e3o do servidor, atualizamos esse cache, criamos e periodicamente atualizamos as configura\u00e7\u00f5es.<\/p>\n<h3>Coleta de dados<\/h3>\n<p>\nO esquema \u00e9 bastante amplo, mas o principal nele s\u00e3o <strong>coletadores<\/strong>. Esses s\u00e3o diferentes 'pollers' - processos de coleta. Eles s\u00e3o respons\u00e1veis por diferentes tipos de coleta: coletam dados via SNMP, IPMI, e transmitem tudo isso para o PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Os coletadores est\u00e3o destacados com uma linha laranja.<\/em><\/p>\n<p>No Zabbix, existem elementos de dados calculados e agregados que s\u00e3o necess\u00e1rios para agregar verifica\u00e7\u00f5es. Se tivermos esses dados, coletamos informa\u00e7\u00f5es diretamente do ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nTodos os coletadores usam o ConfigurationCache para receber tarefas. Em seguida, eles as transmitem para o PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO PreProcessing utiliza o ConfigurationCache para obter os passos do PreProcessing. Ele processa esses dados de v\u00e1rias maneiras.<\/p>\n<p>Ap\u00f3s o processamento dos dados com o PreProcessing, os armazenamos no HistoryCache para process\u00e1-los. Aqui termina a coleta de dados e passamos para o processo principal no Zabbix - <strong>history syncer<\/strong>, uma vez que se trata de uma arquitetura monol\u00edtica.<\/p>\n<p><em>Nota: O PreProcessing \u00e9 uma opera\u00e7\u00e3o bastante pesada. A partir da vers\u00e3o 4.2, foi deslocado para o proxy. Se voc\u00ea tem um Zabbix muito grande com um grande n\u00famero de elementos de dados e frequ\u00eancia de coleta, isso facilita muito o trabalho.<\/em><\/p>\n<h3>ValueCache, hist\u00f3rico e cache de tend\u00eancias<\/h3>\n<p><\/p>\n<blockquote><p>O sincronizador de hist\u00f3rico \u00e9 o processo principal que processa at\u00f4mica cada elemento de dados, ou seja, cada valor.<\/p><\/blockquote>\n<p>\nO sincronizador de hist\u00f3rico pega valores do HistoryCache e verifica na Configura\u00e7\u00e3o a presen\u00e7a de gatilhos para c\u00e1lculos. Se existirem, ele realiza o c\u00e1lculo.<\/p>\n<p>O sincronizador de hist\u00f3rico cria um evento, uma escalada, para gerar alertas, se necess\u00e1rio conforme a configura\u00e7\u00e3o, e registra. Se houver gatilhos para processamento posterior, ele memoriza esse valor no ValueCache, para n\u00e3o acessar a tabela de hist\u00f3ria. Assim, o ValueCache \u00e9 preenchido com os dados necess\u00e1rios para o c\u00e1lculo dos gatilhos e elementos calcul\u00e1veis.<\/p>\n<p>O sincronizador de hist\u00f3rico grava todos os dados no banco de dados, que os armazena no disco. O processo de processamento termina nesse ponto.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cache no Banco de Dados<\/h3>\n<p>\nNo lado do banco de dados, existem v\u00e1rios caches quando voc\u00ea deseja visualizar gr\u00e1ficos ou relat\u00f3rios de eventos:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> no lado do MySQL;<\/li>\n<li><code>shared_buffers<\/code> no lado do PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> no lado do Oracle;<\/li>\n<li><code>shared_pool<\/code> no lado do DB2.<\/li>\n<\/ul>\n<p>\nExistem muitos outros caches, mas estes s\u00e3o os principais para todos os bancos de dados. Eles permitem manter na mem\u00f3ria os dados que s\u00e3o frequentemente necess\u00e1rios para consultas. Cada um com suas pr\u00f3prias tecnologias para isso.<\/p>\n<h3>A performance do banco de dados \u00e9 criticamente importante<\/h3>\n<p>\nO servidor Zabbix continuamente coleta dados e os grava. Ao reiniciar, ele tamb\u00e9m l\u00ea do hist\u00f3rico para preencher o ValueCache. Utiliza scripts e relat\u00f3rios <strong>API do Zabbix<\/strong>, que \u00e9 baseado na interface Web. A API do Zabbix acessa o banco de dados e obt\u00e9m os dados necess\u00e1rios para gr\u00e1ficos, relat\u00f3rios, listas de eventos e problemas recentes.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara visualiza\u00e7\u00e3o \u2014 <strong>Grafana<\/strong>. Entre nossos usu\u00e1rios, essa \u00e9 uma solu\u00e7\u00e3o popular. Ela pode enviar requisi\u00e7\u00f5es diretamente atrav\u00e9s da API do Zabbix tanto para o banco de dados, criando uma certa concorr\u00eancia na obten\u00e7\u00e3o de dados. Portanto, uma configura\u00e7\u00e3o mais refinada e boa do banco de dados \u00e9 necess\u00e1ria para corresponder \u00e0 r\u00e1pida entrega de resultados e testes.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nA terceira chamada de performance no Zabbix \u00e9 a limpeza do hist\u00f3rico atrav\u00e9s do Housekeeper. Ele respeita todas as configura\u00e7\u00f5es \u2014 nos elementos de dados, est\u00e1 indicado quanto tempo manter a din\u00e2mica de mudan\u00e7as (tend\u00eancias) em dias.<\/p>\n<p>O TrendsCache \u00e9 calculado em tempo real. Quando os dados chegam, n\u00f3s os agregamos em uma hora e os registramos em tabelas para a din\u00e2mica de mudan\u00e7as das tend\u00eancias.<\/p>\n<p>O Housekeeper \u00e9 iniciado e remove informa\u00e7\u00f5es do banco de dados com comandos \"select\" comuns. Isso nem sempre \u00e9 eficiente, como pode ser visto nos gr\u00e1ficos de desempenho dos processos internos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO gr\u00e1fico vermelho mostra que o History syncer est\u00e1 constantemente ocupado. O gr\u00e1fico laranja acima \u00e9 o Housekeeper, que est\u00e1 sempre sendo iniciado. Ele aguarda o banco de dados remover todas as linhas que ele designou.<\/p>\n<p>Quando \u00e9 apropriado desabilitar o Housekeeper? Por exemplo, se h\u00e1 um \"Item ID\" e \u00e9 necess\u00e1rio remover as \u00faltimas 5.000 linhas dentro de um determinado per\u00edodo. Claro, isso ocorre atrav\u00e9s de \u00edndices. Mas geralmente o dataset \u00e9 muito grande, e o banco de dados ainda assim l\u00ea do disco e carrega no cache. Essa opera\u00e7\u00e3o \u00e9 sempre muito custosa para o banco de dados e, dependendo do tamanho da base, pode causar problemas de desempenho.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>O Housekeeper pode ser simplesmente desabilitado. Na interface web, h\u00e1 uma configura\u00e7\u00e3o em \"Administra\u00e7\u00e3o geral\" para o Housekeeper. Desabilitamos o gerenciamento interno do Housekeeping para o hist\u00f3rico interno de tend\u00eancias e ele n\u00e3o gerencia mais isso.<\/p>\n<p>Housekeeper desativado, os gr\u00e1ficos se estabilizaram \u2014 quais problemas podem surgir nesse caso e o que pode ajudar a resolver o terceiro chamado de desempenho?<\/p>\n<h2>Particionamento \u2014 particionamento ou seccionamento.<\/h2>\n<p>\nGeralmente, o particionamento \u00e9 configurado de maneiras diferentes em cada banco de dados relacional que mencionei. Cada um possui sua pr\u00f3pria tecnologia, mas s\u00e3o semelhantes, de modo geral. A cria\u00e7\u00e3o de uma nova parti\u00e7\u00e3o frequentemente leva a certos problemas.<\/p>\n<p>Geralmente, as parti\u00e7\u00f5es s\u00e3o configuradas de acordo com o \"setup\" \u2014 a quantidade de dados gerados em um \u00fanico dia. Normalmente, o Particionamento \u00e9 estabelecido para um dia, esse \u00e9 o m\u00ednimo. Para tend\u00eancias, uma nova parti\u00e7\u00e3o \u00e9 feita por 1 m\u00eas.<\/p>\n<p>Os valores podem mudar em caso de um \"setup\" muito grande. Se o \"setup\" for pequeno \u2014 at\u00e9 5.000 nvps (novos valores por segundo), m\u00e9dio \u2014 de 5.000 a 25.000, e grande \u2014 acima de 25.000 nvps. Essas s\u00e3o instala\u00e7\u00f5es grandes e muito grandes que exigem um ajuste cuidadoso do banco de dados.<\/p>\n<p>Em instala\u00e7\u00f5es muito grandes, um segmento de um dia pode n\u00e3o ser ideal. Eu vi parti\u00e7\u00f5es no MySQL de 40 GB ou mais por dia. Esse \u00e9 um volume muito grande de dados que pode levar a problemas, e precisa ser reduzido.<\/p>\n<h3>O que o Particionamento proporciona?<\/h3>\n<p>\n<strong>Particionamento de tabelas<\/strong>. Muitas vezes, estes s\u00e3o arquivos separados no disco. O plano de consultas escolhe uma parti\u00e7\u00e3o de forma mais otimizada. Normalmente, a parti\u00e7\u00e3o \u00e9 utilizada por intervalo \u2014 isso tamb\u00e9m \u00e9 verdadeiro para o Zabbix. N\u00f3s usamos l\u00e1 um \"timestamp\" \u2014 o tempo desde o in\u00edcio da era. Para n\u00f3s, s\u00e3o n\u00fameros comuns. Voc\u00ea define o in\u00edcio e o fim do dia \u2014 esta \u00e9 a parti\u00e7\u00e3o.<\/p>\n<p><strong>Remo\u00e7\u00e3o r\u00e1pida<\/strong> \u2014 <code>DELETE<\/code>. Um arquivo\/subtabela \u00e9 selecionado, em vez de uma amostra de linhas para exclus\u00e3o.<\/p>\n<p><strong>Acelera significativamente a sele\u00e7\u00e3o de dados<\/strong> <code>SELECT<\/code> \u2014 usa uma ou mais parti\u00e7\u00f5es, em vez de toda a tabela. Se voc\u00ea solicitar dados de dois dias atr\u00e1s, eles s\u00e3o recuperados do banco de dados mais rapidamente, pois \u00e9 necess\u00e1rio carregar no cache e fornecer apenas um arquivo, em vez de uma tabela grande.<\/p>\n<p>Frequentemente, muitos bancos de dados tamb\u00e9m aceleram <code>INSERT<\/code> \u2014 inser\u00e7\u00f5es na tabela filha.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nPara a vers\u00e3o 4.2, observamos o TimescaleDB. Esta \u00e9 uma extens\u00e3o para PostgreSQL com uma interface nativa. A extens\u00e3o funciona eficientemente com dados de s\u00e9ries temporais, mantendo as vantagens dos bancos de dados relacionais. O TimescaleDB tamb\u00e9m realiza parti\u00e7\u00f5es automaticamente.<\/p>\n<p>No TimescaleDB existe o conceito de <strong>hipertabela<\/strong> (hypertable), que voc\u00ea cria. Nela est\u00e3o <strong>chunks<\/strong> \u2014 parti\u00e7\u00f5es. Os chunks s\u00e3o fragmentos gerenciados automaticamente da hipertabela, que n\u00e3o afetam outros fragmentos. Cada chunk possui seu pr\u00f3prio intervalo de tempo.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/91a24560ff12aa17f98689e3445f50e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB vs PostgreSQL<\/h3>\n<p>\nO TimescaleDB funciona realmente de forma eficiente. Os criadores da extens\u00e3o afirmam que utilizam um algoritmo de processamento de consultas mais adequado, em particular, <code>inserts<\/code>. \u00c0 medida que os tamanhos das inser\u00e7\u00f5es de conjunto de dados aumentam, o algoritmo mant\u00e9m desempenho constante.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAp\u00f3s 200 milh\u00f5es de linhas, o PostgreSQL geralmente come\u00e7a a ter uma queda significativa e perde desempenho at\u00e9 0. O TimescaleDB permite inserir \"inserts\" de forma eficiente com qualquer volume de dados.<\/p>\n<h3>Instala\u00e7\u00e3o<\/h3>\n<p>\nA instala\u00e7\u00e3o do TimescaleDB \u00e9 bastante simples para quaisquer pacotes. No <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">documenta\u00e7\u00e3o<\/a><\/noindex> est\u00e1 tudo detalhadamente descrito \u2014 ele depende dos pacotes oficiais do PostgreSQL. O TimescaleDB tamb\u00e9m pode ser constru\u00eddo e compilado manualmente.<\/p>\n<p>Para o banco de dados Zabbix, ativamos simplesmente a extens\u00e3o:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nVoc\u00ea ativa <code>a extens\u00e3o<\/code> e a cria para o banco de dados Zabbix. O \u00faltimo passo \u00e9 a cria\u00e7\u00e3o da hipertabela.<\/p>\n<h3>Migra\u00e7\u00e3o de tabelas de hist\u00f3rico para o TimescaleDB<\/h3>\n<p>\nPara isso existe uma fun\u00e7\u00e3o especial <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECIONE create_hypertable('history', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('history_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('history_log', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('history_text', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('history_str', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('trends', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECIONE create_hypertable('trends_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nATUALIZE config SET db_extension='timescaledb', hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nA fun\u00e7\u00e3o tem tr\u00eas par\u00e2metros. O primeiro \u2014<strong> a tabela no banco de dados<\/strong>, para a qual precisa ser criada uma hipertabela. O segundo \u2014 <strong>campo<\/strong>, pelo qual deve ser criado <code>chunk_time_interval<\/code> \u2014 o intervalo dos chunks das parti\u00e7\u00f5es a serem usadas. No meu caso, o intervalo \u00e9 de um dia \u2014 86.400.<\/p>\n<p>O terceiro par\u00e2metro \u2014 <code><strong>migrar_dados<\/strong><\/code>. Se definido como <code>verdadeiro<\/code>, todos os dados atuais s\u00e3o transferidos para os chunks previamente criados. Eu mesmo usei <code>migrar_dados<\/code>. Eu tinha cerca de 1 TB, o que levou mais de uma hora. Mesmo em alguns casos durante os testes, eu removi dados hist\u00f3ricos desnecess\u00e1rios de tipos de caracteres para n\u00e3o transferi-los.<\/p>\n<p>O \u00faltimo passo \u2014\u00a0<code><strong>ATUALIZA\u00c7\u00c3O<\/strong><\/code>: em <code>db_extension<\/code> definimos como <code>timescaledb<\/code>, para que o banco de dados entenda que existe essa extens\u00e3o. O Zabbix a ativa e usa corretamente a sintaxe e as consultas j\u00e1 para o banco de dados \u2014 aquelas funcionalidades necess\u00e1rias para o TimescaleDB.<\/p>\n<h2>Configura\u00e7\u00e3o do hardware<\/h2>\n<p>\nEu usei dois servidores. O primeiro \u2014 <strong>uma m\u00e1quina VMware<\/strong>. Ela \u00e9 bastante pequena: 20 processadores Intel\u00ae Xeon\u00ae CPU E5-2630 v4 @ 2.20GHz, 16 GB de RAM e um disco SSD de 200 GB.<\/p>\n<p>Instalei o PostgreSQL 10.8 com o Debian 10.8-1.pgdg90+1 e sistema de arquivos xfs. Configurei o m\u00ednimo necess\u00e1rio para usar precisamente esse banco de dados, exceto pelo que ser\u00e1 usado pelo pr\u00f3prio Zabbix.<\/p>\n<p>Nessa mesma m\u00e1quina, estava o servidor Zabbix, o PostgreSQL e <strong>agentes de carga<\/strong>. Eu tinha 50 agentes ativos que usavam <code>LoadableModule<\/code>, para gerar resultados variados rapidamente: n\u00fameros, strings. Eu alimentava o banco de dados com uma grande quantidade de dados.<\/p>\n<p>Inicialmente, a configura\u00e7\u00e3o continha <strong>5.000 itens<\/strong> de dados por host. Quase cada item continha um gatilho, para parecer com instala\u00e7\u00f5es reais. Em alguns casos, havia mais de um gatilho. Para um n\u00f3 de rede, havia <strong>3.000-7.000 gatilhos<\/strong>.<\/p>\n<p>O intervalo de atualiza\u00e7\u00e3o dos itens de dados \u2014 <strong>4-7 segundos<\/strong>Eu regulei a carga usando n\u00e3o apenas 50 agentes, mas tamb\u00e9m adicionei mais. Al\u00e9m disso, usei elementos de dados din\u00e2micos para ajustar a carga e reduzi o intervalo de atualiza\u00e7\u00e3o para 4 segundos.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nA primeira execu\u00e7\u00e3o nesse hardware foi com PostgreSQL puro \u2014 35 mil valores por segundo. Como pode ser visto, a inser\u00e7\u00e3o de dados leva fra\u00e7\u00f5es de segundo \u2014 tudo est\u00e1 bom e r\u00e1pido. A \u00fanica coisa \u00e9 que o disco SSD de 200 GB enche rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste \u00e9 o dashboard padr\u00e3o de desempenho do Zabbix \u2014 servidores.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO primeiro gr\u00e1fico azul mostra a quantidade de valores por segundo. O segundo gr\u00e1fico \u00e0 direita mostra a carga dos processos de coleta. O terceiro \u2014 a carga dos processos internos de coleta: history syncers e o Housekeeper, que estava sendo executado aqui por um tempo consider\u00e1vel.<\/p>\n<p>O quarto gr\u00e1fico mostra o uso do HistoryCache. Isso \u00e9 um tipo de buffer antes da inser\u00e7\u00e3o no banco de dados. O quinto gr\u00e1fico verde mostra a utiliza\u00e7\u00e3o do ValueCache, ou seja, quantos hits houve no ValueCache para gatilhos \u2014 isso chega a milhares de valores por segundo.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nDepois, aumentei a carga para 50 mil valores por segundo nesse mesmo hardware.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAo carregar com o Housekeeper, a inser\u00e7\u00e3o de 10 mil valores levou de 2 a 3 segundos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>O Housekeeper j\u00e1 come\u00e7a a interferir no trabalho.<\/em><\/p>\n<p>Pelo terceiro gr\u00e1fico, pode-se ver que, de forma geral, a carga dos trapper e history syncers ainda est\u00e1 em 60%. No quarto gr\u00e1fico, o HistoryCache, durante a execu\u00e7\u00e3o do Housekeeper, j\u00e1 come\u00e7a a se preencher bastante. Ele se encheu em 20% \u2014 isso \u00e9 cerca de 0,5 GB.<\/p>\n<h3>PostgreSQL. 80.000 nvps<\/h3>\n<p>\nDepois, aumentei a carga para 80 mil valores por segundo. Isso equivale a cerca de 400 mil elementos de dados e 280 mil gatilhos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>A inser\u00e7\u00e3o com uma carga de trinta history syncers j\u00e1 \u00e9 bastante alta.<\/em><\/p>\n<p>Tamb\u00e9m aumentei v\u00e1rios par\u00e2metros: history syncers, caches.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo meu hardware, a carga dos history syncers aumentou ao m\u00e1ximo. O HistoryCache se preencheu rapidamente com dados \u2014 havia dados acumulados no buffer para processamento.<\/p>\n<p>Durante todo esse tempo, observei como a CPU, a mem\u00f3ria RAM e outros par\u00e2metros do sistema estavam sendo utilizados, e percebi que a utiliza\u00e7\u00e3o dos discos estava no m\u00e1ximo.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConsegui utilizar <strong>a capacidade m\u00e1xima do disco<\/strong> neste hardware e nesta m\u00e1quina virtual. Com essa intensidade, o PostgreSQL come\u00e7ou a descartar dados com bastante frequ\u00eancia, e o disco j\u00e1 n\u00e3o conseguia acompanhar a leitura e grava\u00e7\u00e3o.<\/p>\n<h3>Servidor dois<\/h3>\n<p>\nEu peguei outro servidor, que j\u00e1 tinha 48 processadores e 128 GB de mem\u00f3ria RAM. O otimizei \u2013 instalei 60 history syncer e cheguei a um desempenho aceit\u00e1vel.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe fato, isso j\u00e1 \u00e9 o limite de desempenho, onde \u00e9 necess\u00e1rio fazer algo.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nMeu principal objetivo \u00e9 verificar as capacidades do TimescaleDB sob a carga do Zabbix. 80 mil valores por segundo \u00e9 muito, com uma frequ\u00eancia de coleta de m\u00e9tricas (exceto para o Yandex, claro) e um 'setup' bastante grande.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEm cada gr\u00e1fico h\u00e1 um pico \u2014 isso \u00e9 exatamente a migra\u00e7\u00e3o de dados. Depois dos picos no servidor Zabbix, o perfil de carga do history syncer mudou consideravelmente \u2014 caiu tr\u00eas vezes.<\/p>\n<blockquote><p>TimescaleDB permite inserir dados quase 3 vezes mais r\u00e1pido e usar menos HistoryCache.<\/p><\/blockquote>\n<p>\nPortanto, voc\u00ea receber\u00e1 os dados em tempo h\u00e1bil.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nDepois, aumentei o n\u00famero de elementos de dados para 500 mil. O principal objetivo era verificar as capacidades do TimescaleDB \u2014 recebi um valor calculado de 125 mil valores por segundo.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste \u00e9 um 'setup' funcional, que pode operar por um longo tempo. Mas como meu disco era de apenas 1,5 TB, eu o enchi em poucos dias.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO mais importante \u00e9 que, ao mesmo tempo, novas parti\u00e7\u00f5es do TimescaleDB estavam sendo criadas.<\/p>\n<p>Para o desempenho, isso \u00e9 completamente impercept\u00edvel. Quando parti\u00e7\u00f5es s\u00e3o criadas no MySQL, por exemplo, tudo \u00e9 diferente. Normalmente, isso acontece \u00e0 noite, pois bloqueia a inser\u00e7\u00e3o geral, o trabalho com tabelas e pode criar degrada\u00e7\u00e3o no servi\u00e7o. No caso do TimescaleDB, isso n\u00e3o acontece.<\/p>\n<p>Para exemplificar, mostrarei um gr\u00e1fico de muitos na comunidade. Na imagem, o TimescaleDB est\u00e1 ativado, e gra\u00e7as a isso a carga no uso de io.weight no processador diminuiu. O uso dos elementos dos processos internos tamb\u00e9m foi reduzido. E isso \u00e9 uma m\u00e1quina virtual comum em discos comuns, e n\u00e3o em SSDs.<\/p>\n<p><img decoding=\"async\" alt=\"Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n<p>\n<strong>TimescaleDB \u00e9 uma boa solu\u00e7\u00e3o para 'setups' pequenos<\/strong>, que esbarram na performance do disco. Ela permitir\u00e1 continuar funcionando bem at\u00e9 a migra\u00e7\u00e3o do banco de dados para hardware mais r\u00e1pido.<\/p>\n<p>TimescaleDB \u00e9 f\u00e1cil de configurar, oferece aumento de desempenho, funciona bem com Zabbix e <strong>tem vantagens em rela\u00e7\u00e3o ao PostgreSQL<\/strong>.<\/p>\n<p>Se voc\u00ea est\u00e1 utilizando o PostgreSQL e n\u00e3o planeja mud\u00e1-lo, recomendo <strong>usar o PostgreSQL com a extens\u00e3o TimescaleDB em conjunto com o Zabbix<\/strong>. Essa solu\u00e7\u00e3o funciona de forma eficiente para 'setups' medianos.<\/p>\n<blockquote>\n<p>Quando dizemos 'alto desempenho' \u2014 nos referimos a <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. N\u00e3o vai demorar muito para conhecer as tecnologias e pr\u00e1ticas que permitem que os servi\u00e7os atendam milh\u00f5es de usu\u00e1rios. Lista <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">de relat\u00f3rios<\/a><\/noindex> para os dias 7 e 8 de novembro j\u00e1 est\u00e1 pronta, mas <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetups<\/a><\/noindex> podem ser sugeridos ainda.<\/p>\n<p>Siga a nossa <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">newsletter<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, em que revelamos dicas da pr\u00f3xima confer\u00eancia e descubra como aproveitar ao m\u00e1ximo.<\/p>\n<\/blockquote>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/470902\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Alto desempenho e particionamento nativo: Zabbix com suporte a TimescaleDB | ProHoster","description":"Zabbix \u00e9 um sistema de monitoramento.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster","og:description":"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38927","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 21:14:06","updated":"2026-01-23 23:59:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}