{"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\/pt\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Como constru\u00edmos a monitora\u00e7\u00e3o com Prometheus, Clickhouse e ELK","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Meu nome \u00e9 Anton Baderin. Trabalho no Centro de Altas Tecnologias e sou respons\u00e1vel pela administra\u00e7\u00e3o de sistemas. H\u00e1 um m\u00eas, nossa confer\u00eancia corporativa foi conclu\u00edda, onde compartilhamos experi\u00eancias acumuladas com a comunidade de TI da nossa cidade. Falei sobre monitoramento de aplica\u00e7\u00f5es web. O material foi destinado a profissionais de n\u00edvel j\u00fanior ou m\u00e9dio, que ainda n\u00e3o implementaram esse processo do zero.<\/p>\n

<\/p>\n

\"Como<\/p>\n

<\/p>\n

A pedra angular de qualquer sistema de monitoramento \u00e9 resolver os problemas dos neg\u00f3cios. Monitorar apenas por monitorar n\u00e3o interessa a ningu\u00e9m. E o que o neg\u00f3cio quer? Que tudo funcione rapidamente e sem erros. O neg\u00f3cio quer proatividade, que identifiquemos problemas no funcionamento do servi\u00e7o e os solucionemos o mais r\u00e1pido poss\u00edvel. Essas s\u00e3o, na verdade, as quest\u00f5es que resolvi durante o ano passado em um projeto de um dos nossos clientes.<\/p>\n

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

Sobre o projeto<\/h2>\n

<\/p>\n

O projeto \u00e9 um dos maiores programas de fidelidade do pa\u00eds. Ajudamos redes de varejo a aumentar a frequ\u00eancia de vendas por meio de diversas ferramentas de marketing, como cart\u00f5es de b\u00f4nus. No total, o projeto envolve 14 aplica\u00e7\u00f5es que operam em dez servidores.<\/p>\n

<\/p>\n

Durante as entrevistas, percebi repetidamente que os administradores nem sempre abordam corretamente o monitoramento de aplica\u00e7\u00f5es web: muitos ainda se limitam a m\u00e9tricas do sistema operacional, monitorando servi\u00e7os apenas ocasionalmente.<\/p>\n

<\/p>\n

No meu caso, anteriormente o sistema de monitoramento do cliente era baseado no Icinga. Isso n\u00e3o resolvia as quest\u00f5es mencionadas anteriormente. Muitas vezes, o cliente nos informava sobre problemas e frequentemente n\u00e3o t\u00ednhamos dados suficientes para descobrir a causa.<\/p>\n

<\/p>\n

Al\u00e9m disso, havia uma compreens\u00e3o clara da falta de perspectivas para seu desenvolvimento futuro. Acho que aqueles que conhecem o Icinga v\u00e3o entender. Assim, decidimos reestruturar completamente o sistema de monitoramento de aplica\u00e7\u00f5es web no projeto.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Escolhemos o Prometheus com base em tr\u00eas indicadores principais:<\/p>\n

<\/p>\n

    \n
  1. Um grande n\u00famero de m\u00e9tricas dispon\u00edveis. No nosso caso, s\u00e3o 60 mil. Claro, vale mencionar que a grande maioria delas n\u00e3o utilizamos (provavelmente cerca de 95%). Por outro lado, todas s\u00e3o relativamente baratas. Para n\u00f3s, esse \u00e9 outro extremo, em compara\u00e7\u00e3o com o Icinga que us\u00e1vamos anteriormente. Naquele sistema, adicionar m\u00e9tricas era especialmente dif\u00edcil: as que existiam eram caras (basta olhar o c\u00f3digo-fonte de qualquer plugin). Qualquer plugin era um script em Bash ou Python, cuja execu\u00e7\u00e3o n\u00e3o \u00e9 barata em termos de recursos consumidos.<\/li>\n
  2. Este sistema consome uma quantidade relativamente pequena de recursos. Para todas as nossas m\u00e9tricas, s\u00e3o suficientes 600 MB de mem\u00f3ria RAM, 15% de um n\u00facleo e algumas dezenas de IOPS. Claro, \u00e9 necess\u00e1rio executar os exporters de m\u00e9tricas, mas todos eles s\u00e3o escritos em Go e tamb\u00e9m n\u00e3o s\u00e3o exigentes. N\u00e3o acho que isso seja um problema nas circunst\u00e2ncias atuais. <\/li>\n
  3. Oferece a possibilidade de migra\u00e7\u00e3o para o Kubernetes. Considerando os planos do cliente, a escolha \u00e9 \u00f3bvia. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    Anteriormente, n\u00e3o colet\u00e1vamos nem process\u00e1vamos logs. As desvantagens s\u00e3o claras para todos. Optamos pelo ELK, uma vez que j\u00e1 t\u00ednhamos experi\u00eancia com este sistema. Armazenamos apenas os logs das aplica\u00e7\u00f5es. Os principais crit\u00e9rios de escolha foram a busca em texto completo e a sua rapidez.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Inicialmente, a escolha recaiu sobre o InfluxDB. N\u00f3s perceb\u00edamos a necessidade de coletar logs do Nginx, estat\u00edsticas do pg_stat_statements e armazenar dados hist\u00f3ricos do Prometheus. N\u00e3o gostamos do Influx, pois ele ocasionalmente come\u00e7ava a consumir muita mem\u00f3ria e ca\u00eda. Al\u00e9m disso, quer\u00edamos agrupar solicita\u00e7\u00f5es por remote_addr, mas o agrupamento neste SGBD \u00e9 apenas por tags. As tags s\u00e3o caras (em termos de mem\u00f3ria), e sua quantidade \u00e9 limitadamente condicional.<\/p>\n

    <\/p>\n

    Come\u00e7amos a busca do zero. Precis\u00e1vamos de uma base anal\u00edtica com consumo m\u00ednimo de recursos, preferencialmente com compress\u00e3o de dados no disco.<\/p>\n

    <\/p>\n

    Clickhouse atende a todos esses crit\u00e9rios, e nunca nos arrependemos da escolha. N\u00e3o escrevemos grandes volumes de dados nele (o n\u00famero de inser\u00e7\u00f5es \u00e9 de cerca de cinco mil por minuto).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    O NewRelic tem sido nosso parceiro historicamente, pois foi a escolha do cliente. Aqui, \u00e9 usado como APM.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Usamos o Zabbix exclusivamente para monitorar a Black Box de v\u00e1rias APIs.<\/p>\n

    <\/p>\n

    Definindo a abordagem de monitoramento<\/h2>\n

    <\/p>\n

    Quer\u00edamos decompor a tarefa e, assim, sistematizar a abordagem ao monitoramento.<\/p>\n

    <\/p>\n

    Dividi nossa sistema nos seguintes n\u00edveis:<\/p>\n

    <\/p>\n