🥇O monitoramento está morto? — Monitoramento de longa duração

Desde 2008, nossa empresa se dedica principalmente ao gerenciamento de infraestrutura e suporte técnico 400 horas por dia para projetos web: temos mais de 15 clientes, o que representa cerca de 15% do comércio eletrônico russo. Consequentemente, uma arquitetura muito diversificada é suportada. Se algo cair, somos obrigados a consertar em XNUMX minutos. Mas para entender que ocorreu um acidente, é necessário monitorar o projeto e responder aos incidentes. Como fazer isso?

Acredito que há um problema na organização de um sistema de monitoramento adequado. Se não houvesse problemas, então meu discurso consistiria em uma tese: “Por favor, instale Prometheus + Grafana e plugins 1, 2, 3”. Infelizmente, não funciona mais assim. E o principal problema é que todos continuam acreditando em algo que existia em 2008, em termos de componentes de software.

Relativamente à organização do sistema de monitorização, atrevo-me a dizer que... não existem projectos com monitorização competente. E a situação é tão ruim que, se algo cair, corre-se o risco de passar despercebido – afinal, todos têm certeza de que “está tudo monitorado”.
Talvez tudo esteja sendo monitorado. Mas como?

Todos nós já encontramos uma história como a seguinte: um certo devops, um certo administrador está trabalhando, uma equipe de desenvolvimento chega até eles e diz - “estamos liberados, agora monitore”. Monitorar o quê? Como funciona?

OK. Nós monitoramos à moda antiga. E já está mudando, e acontece que você monitorou o serviço A, que virou serviço B, que interage com o serviço C. Mas a equipe de desenvolvimento te diz: “Instale o software, ele deve monitorar tudo!”

Então, o que mudou? - Tudo mudou!

2008 Tudo está bem

Existem alguns desenvolvedores, um servidor, um servidor de banco de dados. Tudo vai a partir daqui. Temos algumas informações, instalamos zabbix, Nagios, cacti. E então definimos alertas claros sobre a CPU, sobre a operação do disco e sobre o espaço em disco. Também fazemos algumas verificações manuais para garantir que o site responda e que os pedidos cheguem ao banco de dados. E é isso – estamos mais ou menos protegidos.

Se compararmos a quantidade de trabalho que o administrador fez para fornecer o monitoramento, então 98% dele foi automático: quem faz o monitoramento deve entender como instalar o Zabbix, como configurá-lo e configurar alertas. E 2% - para verificações externas: se o site responde e faz uma solicitação ao banco de dados, se novos pedidos chegaram.

2010 A carga está crescendo

Estamos começando a dimensionar a web, adicionando um mecanismo de busca. Queremos ter certeza de que o catálogo de produtos contém todos os produtos. E essa pesquisa de produto funciona. Que o banco de dados esteja funcionando, que os pedidos estejam sendo feitos, que o site responda externamente e responda de dois servidores e o usuário não seja expulso do site enquanto ele é rebalanceado para outro servidor, etc. Existem mais entidades.

Além disso, a entidade associada à infraestrutura continua a ser a maior na cabeça do gestor. Ainda fica na minha cabeça a ideia de que quem faz o monitoramento é quem vai instalar o zabbix e poder configurá-lo.

Mas, ao mesmo tempo, surge trabalho na realização de verificações externas, na criação de um conjunto de scripts de consulta do indexador de pesquisa, um conjunto de scripts para verificar se a pesquisa muda durante o processo de indexação, um conjunto de scripts que verificam se as mercadorias são transferidas para o serviço de entrega, etc e assim por diante.

Nota: escrevi “um conjunto de scripts” 3 vezes. Ou seja, o responsável pelo monitoramento não é mais aquele que simplesmente instala o zabbix. Esta é uma pessoa que começa a codificar. Mas nada mudou na cabeça da equipe ainda.

Mas o mundo está mudando, tornando-se cada vez mais complexo. Uma camada de virtualização e vários novos sistemas são adicionados. Eles começam a interagir uns com os outros. Quem disse “cheira a microsserviços?” Mas cada serviço ainda se parece com um site individualmente. Podemos recorrer a ele e compreender que ele fornece as informações necessárias e funciona por conta própria. E se você é um administrador constantemente envolvido em um projeto que vem se desenvolvendo há 5-7-10 anos, esse conhecimento se acumula: aparece um novo nível - você percebeu, aparece outro nível - você percebeu...

Mas raramente alguém acompanha um projeto durante 10 anos.

Currículo do monitor

Suponha que você chegou a uma nova startup que contratou imediatamente 20 desenvolvedores, escreveu 15 microsserviços e você é um administrador que ouve: “Construa CI/CD. Por favor." Você construiu CI/CD e de repente ouve: “É difícil a gente trabalhar com produção em um “cubo”, sem entender como a aplicação vai funcionar nele. Faça-nos uma caixa de areia no mesmo “cubo”.
Você faz uma caixa de areia neste cubo. Eles imediatamente dizem: “Queremos um banco de dados de estágio que seja atualizado todos os dias desde a produção, para que possamos entender que funciona no banco de dados, mas ao mesmo tempo não estraga o banco de dados de produção”.

Você vive em tudo isso. Faltam 2 semanas para o lançamento, eles te dizem: “Agora vamos monitorar tudo isso...” Isto é. monitorar a infraestrutura do cluster, monitorar a arquitetura de microsserviços, monitorar o trabalho com serviços externos...

E meus colegas tiram da cabeça o esquema usual e dizem: “Bom, está tudo claro aqui! Instale um programa que monitore tudo isso.” Sim, sim: Prometheus + Grafana + plug-ins.
E acrescentam: “Você tem duas semanas, certifique-se de que tudo está seguro”.

Em muitos projetos que vemos, uma pessoa é alocada para monitoramento. Imagine que queremos contratar uma pessoa para fazer monitoramento por 2 semanas, e escrevemos um currículo para ela. Que competências esta pessoa deverá ter, tendo em conta tudo o que dissemos até agora?

Ele deve compreender o monitoramento e as especificidades da operação da infraestrutura férrea.
Ele deve entender as especificidades do monitoramento do Kubernetes (e todo mundo quer ir para o “cubo”, porque você pode abstrair de tudo, esconder, porque o administrador cuidará do resto) - ele mesmo, sua infraestrutura, e entender como monitorar aplicativos dentro.
Ele deve compreender que os serviços se comunicam entre si de maneiras especiais e conhecer as especificidades de como os serviços interagem entre si. É bem possível ver um projeto onde alguns serviços se comunicam de forma síncrona, pois não há outra forma. Por exemplo, o backend vai via REST, via gRPC até o serviço de catálogo, recebe uma lista de produtos e a devolve. Você não pode esperar aqui. E com outros serviços funciona de forma assíncrona. Transfira o pedido para o serviço de entrega, envie uma carta, etc.
Você provavelmente já nadou com tudo isso? E o administrador, que precisa monitorar isso, ficou ainda mais confuso.
Ele deve ser capaz de planejar e planejar corretamente - à medida que há cada vez mais trabalho.
Ele deve, portanto, criar uma estratégia a partir do serviço criado para entender como monitorá-lo especificamente. Ele precisa de um entendimento da arquitetura do projeto e de seu desenvolvimento + um entendimento das tecnologias utilizadas no desenvolvimento.

Vamos lembrar de um caso absolutamente normal: alguns serviços estão em PHP, alguns serviços estão em Go, alguns serviços estão em JS. De alguma forma, eles trabalham um com o outro. É daí que vem o termo “microsserviço”: existem tantos sistemas individuais que os desenvolvedores não conseguem entender o projeto como um todo. Uma parte da equipe escreve serviços em JS que funcionam por conta própria e não sabe como funciona o resto do sistema. A outra parte escreve serviços em Python e não interfere no funcionamento de outros serviços; eles ficam isolados em sua própria área. O terceiro é escrever serviços em PHP ou qualquer outra coisa.
Todas essas 20 pessoas estão divididas em 15 serviços, e só há um administrador que deve entender tudo isso. Parar! acabamos de dividir o sistema em 15 microsserviços porque 20 pessoas não conseguem entender o sistema inteiro.

Mas precisa ser monitorado de alguma forma...

Qual é o resultado? Como resultado, há uma pessoa que surge com tudo o que toda a equipe de desenvolvedores não consegue entender e, ao mesmo tempo, também deve saber e ser capaz de fazer o que indicamos acima - infraestrutura de hardware, infraestrutura Kubernetes, etc.

O que posso dizer... Houston, temos problemas.

Monitorar um projeto de software moderno é um projeto de software em si

A partir da falsa crença de que monitoramento é software, desenvolvemos uma crença em milagres. Mas milagres, infelizmente, não acontecem. Você não pode instalar o zabbix e esperar que tudo funcione. Não adianta instalar o Grafana e torcer para que tudo dê certo. A maior parte do tempo será gasta na organização de verificações do funcionamento dos serviços e da sua interação entre si, verificando o funcionamento dos sistemas externos. Na verdade, 90% do tempo não será gasto na escrita de scripts, mas no desenvolvimento de software. E deve ser feito por uma equipe que entende o trabalho do projeto.
Se nesta situação uma pessoa for colocada em monitoramento, então um desastre acontecerá. Que é o que acontece em todos os lugares.

Por exemplo, existem vários serviços que se comunicam via Kafka. O pedido chegou, mandamos uma mensagem sobre o pedido para Kafka. Existe um serviço que escuta informações sobre o pedido e envia a mercadoria. Existe um serviço que escuta informações sobre o pedido e envia uma carta ao usuário. E então aparecem mais vários serviços e começamos a ficar confusos.

E se você também passar isso para o administrador e desenvolvedores na fase em que falta pouco tempo para o lançamento, a pessoa precisará entender todo esse protocolo. Aqueles. Um projeto desta escala leva um tempo significativo e isso deve ser levado em consideração no desenvolvimento do sistema.
Mas muitas vezes, especialmente em startups, vemos como o monitoramento é adiado para mais tarde. “Agora vamos fazer uma Prova de Conceito, vamos lançar com ela, deixar cair – estamos prontos para o sacrifício. E então monitoraremos tudo.” Quando (ou se) o projeto começar a ganhar dinheiro, a empresa quer adicionar ainda mais recursos - porque começou a funcionar, então precisa ser implementado ainda mais! E você está no ponto em que primeiro precisa monitorar tudo o que foi anterior, o que não leva 1% do tempo, mas muito mais. E, a propósito, os desenvolvedores serão necessários para monitorar e será mais fácil deixá-los trabalhar em novos recursos. Como resultado, novos recursos são escritos, tudo fica bagunçado e você fica em um impasse sem fim.

Então, como acompanhar um projeto desde o início e o que fazer se você pegar um projeto que precisa ser acompanhado, mas não sabe por onde começar?

Primeiro, você precisa planejar.

Digressão lírica: muitas vezes começam com o monitoramento da infraestrutura. Por exemplo, temos o Kubernetes. Vamos começar instalando o Prometheus com Grafana, instalando plugins para monitoramento do “cubo”. Não apenas os desenvolvedores, mas também os administradores têm a infeliz prática de: “Vamos instalar este plugin, mas o plugin provavelmente sabe como fazê-lo”. As pessoas gostam de começar com coisas simples e diretas, em vez de ações importantes. E o monitoramento da infraestrutura é fácil.

Primeiro, decida o que e como você deseja monitorar e depois selecione uma ferramenta, porque outras pessoas não podem pensar por você. E deveriam? Outras pessoas pensaram consigo mesmas sobre um sistema universal - ou nem pensaram quando este plugin foi escrito. E só porque este plugin tem 5 mil usuários não significa que ele tenha alguma utilidade. Talvez você se torne o 5001º simplesmente porque já havia 5000 pessoas lá antes.

Se você começar a monitorar a infraestrutura e o backend do seu aplicativo parar de responder, todos os usuários perderão a conexão com o aplicativo móvel. Um erro aparecerá. Eles virão até você e dirão “O aplicativo não está funcionando, o que você está fazendo aqui?” - “Estamos monitorando.” — “Como você monitora se não vê que o aplicativo não está funcionando?!”

Acredito que você precisa começar o monitoramento exatamente a partir do ponto de entrada do usuário. Se o usuário não perceber que o aplicativo está funcionando, é isso, é uma falha. E o sistema de monitoramento deve alertar sobre isso primeiro.
E só então poderemos monitorar a infraestrutura. Ou faça isso em paralelo. É mais fácil com infraestrutura - aqui podemos finalmente instalar o zabbix.
E agora você precisa ir às raízes do aplicativo para entender onde as coisas não estão funcionando.

A minha ideia principal é que a monitorização deve ocorrer em paralelo com o processo de desenvolvimento. Se você distrair a equipe de monitoramento para outras tarefas (criação de CI/CD, sandbox, reorganização da infraestrutura), o monitoramento começará a atrasar e você poderá nunca acompanhar o desenvolvimento (ou, mais cedo ou mais tarde, terá que interrompê-lo).

Tudo por níveis

É assim que vejo a organização de um sistema de monitoramento.

1) Nível de aplicação:

monitorar a lógica de negócios do aplicativo;
monitorar métricas de saúde dos serviços;
monitoramento de integração.

2) Nível de infraestrutura:

monitoramento em nível de orquestração;
monitoramento de software de sistema;
monitoramento do nível de ferro.

3) Novamente o nível de aplicação - mas como um produto de engenharia:

coleta e monitoramento de logs de aplicativos;
MAPA;
rastreamento.

4) Alerta:

organização de um sistema de alerta;
organização de um sistema de plantão;
organização de uma “base de conhecimento” e fluxo de trabalho para processamento de incidentes.

É importante: chegamos ao alerta não depois, mas imediatamente! Não há necessidade de iniciar o monitoramento e “de alguma forma mais tarde” descobrir quem receberá alertas. Afinal, qual é a tarefa do monitoramento: entender onde no sistema algo está funcionando errado e informar as pessoas certas sobre isso. Se você deixar isso para o fim, as pessoas certas saberão que algo está errado apenas dizendo “nada está funcionando para nós”.

Camada de Aplicação - Monitoramento de Lógica de Negócios

Estamos falando aqui de verificar se o aplicativo funciona para o usuário.

Este nível deve ser feito durante a fase de desenvolvimento. Por exemplo, temos um Prometheus condicional: ele vai para o servidor que faz as verificações, puxa o endpoint e o endpoint vai e verifica a API.

Quando frequentemente solicitados a monitorar a página inicial para garantir que o site esteja funcionando, os programadores fornecem um identificador que pode ser usado sempre que precisarem para garantir que a API esteja funcionando. E os programadores neste momento ainda pegam e escrevem /api/test/helloworld
A única maneira de garantir que tudo funcione? - Não!

A criação de tais verificações é essencialmente tarefa dos desenvolvedores. Os testes unitários devem ser escritos pelos programadores que escrevem o código. Porque se você vazar para o administrador, “Cara, aqui está uma lista de protocolos API para todas as 25 funções, monitore tudo!” - nada vai dar certo.
Se você imprimir “olá mundo”, ninguém jamais saberá que a API deveria funcionar e funciona. Cada alteração na API deve levar a uma alteração nas verificações.
Se você já tem esse problema, interrompa os recursos e aloque os desenvolvedores que farão essas verificações, ou aceite as perdas, aceite que nada foi verificado e falhará.

Dicas técnicas:

Certifique-se de organizar um servidor externo para organizar as verificações - você deve ter certeza de que seu projeto está acessível ao mundo exterior.
Organize verificações em todo o protocolo da API, não apenas em endpoints individuais.
Crie um endpoint do prometheus com os resultados do teste.

Camada de aplicação – monitoramento de métricas de integridade

Agora estamos falando sobre métricas externas de saúde dos serviços.

Decidimos monitorar todos os “handles” da aplicação por meio de verificações externas, que chamamos de um sistema de monitoramento externo. Mas essas são as “alças” que o usuário “vê”. Queremos ter certeza de que nossos próprios serviços funcionam. Há uma história melhor aqui: o K8s faz exames de saúde, para que pelo menos o próprio “cubo” possa ser convencido de que o serviço está funcionando. Mas metade dos cheques que vi têm a mesma impressão “olá mundo”. Aqueles. Então ele puxa uma vez após a implantação e responde que está tudo bem - só isso. E o serviço, se disponibilizar uma API própria, tem um número enorme de pontos de entrada para essa mesma API, que também precisa de ser monitorizada, porque queremos saber se funciona. E já estamos monitorando lá dentro.

Como implementar isso corretamente tecnicamente: cada serviço expõe um endpoint sobre seu desempenho atual, e nos gráficos do Grafana (ou de qualquer outra aplicação) vemos o status de todos os serviços.

Cada alteração na API deve levar a uma alteração nas verificações.
Crie um novo serviço imediatamente com métricas de integridade.
Um administrador pode ir até os desenvolvedores e perguntar “adicione alguns recursos para que eu entenda tudo e adicione informações sobre isso ao meu sistema de monitoramento”. Mas os desenvolvedores geralmente respondem: “Não adicionaremos nada duas semanas antes do lançamento”.
Deixe os gerentes de desenvolvimento saberem que haverá tais perdas, avise também a gestão dos gerentes de desenvolvimento. Porque quando tudo cair, alguém ainda vai ligar e exigir monitorar o “serviço em constante queda” (c)
A propósito, aloque desenvolvedores para escrever plugins para Grafana - isso será uma boa ajuda para administradores.

Camada de Aplicação - Monitoramento de Integração

O monitoramento de integração concentra-se no monitoramento das comunicações entre sistemas críticos para os negócios.

Por exemplo, existem 15 serviços que se comunicam entre si. Estes não são mais sites separados. Aqueles. não podemos extrair o serviço por conta própria, obter /helloworld e entender que o serviço está em execução. Como o serviço web de pedidos deve enviar informações sobre o pedido para o barramento - do barramento, o serviço de armazém deve receber essa mensagem e trabalhar com ela posteriormente. E o serviço de distribuição de e-mail deve processar isso de alguma forma, etc.

Assim, não conseguimos compreender, cutucando cada serviço individual, que tudo funciona. Porque temos um determinado ônibus através do qual tudo se comunica e interage.
Portanto, esta etapa deve marcar a etapa de testes dos serviços para interação com outros serviços. É impossível organizar o monitoramento da comunicação monitorando o intermediário de mensagens. Se existe um serviço que emite dados e um serviço que os recebe, ao monitorar a corretora veremos apenas dados que voam de um lado para o outro. Mesmo que de alguma forma conseguíssemos monitorar internamente a interação desses dados - que um determinado produtor poste os dados, alguém os leia, esse fluxo continue indo para o Kafka - isso ainda não nos dará informações se um serviço enviou a mensagem em uma versão , mas o outro serviço não esperava esta versão e a ignorou. Não saberemos disso, pois os serviços nos dirão que tudo está funcionando.

O que eu recomendo fazer:

Para comunicação síncrona: o endpoint faz solicitações a serviços relacionados. Aqueles. pegamos esse endpoint, puxamos um script dentro do serviço, que vai para todos os pontos e diz “Posso puxar para lá, e puxar para lá, posso puxar para lá...”
Para comunicação assíncrona: mensagens recebidas - o terminal verifica se há mensagens de teste no barramento e exibe o status do processamento.
Para comunicação assíncrona: mensagens de saída – o endpoint envia mensagens de teste para o barramento.

Como normalmente acontece: temos um serviço que joga dados no barramento. Chegamos a este serviço e pedimos que nos conte sobre a sua saúde de integração. E se o serviço precisar produzir uma mensagem em algum lugar mais distante (WebApp), ele produzirá essa mensagem de teste. E se executarmos um serviço no lado OrderProcessing, ele primeiro posta o que pode postar de forma independente, e se houver algumas coisas dependentes, então ele lê um conjunto de mensagens de teste do barramento, entende que pode processá-las, reportá-las e , se necessário, poste mais, e sobre isso ele diz - está tudo bem, estou vivo.

Muitas vezes ouvimos a pergunta “como podemos testar isso em dados de combate?” Por exemplo, estamos falando do mesmo serviço de pedidos. O pedido envia mensagens para o armazém onde as mercadorias são baixadas: não podemos testar isso nos dados de combate, porque “minhas mercadorias serão baixadas!” Solução: Planeje todo esse teste desde o início. Você também tem testes unitários que fazem simulações. Então, faça isso em um nível mais profundo onde você tenha um canal de comunicação que não prejudique o funcionamento do negócio.

Camada de infraestrutura

O monitoramento de infraestrutura é algo que há muito tempo é considerado monitoramento em si.

A monitorização da infra-estrutura pode e deve ser lançada como um processo separado.
Você não deve começar monitorando a infraestrutura em um projeto em execução, mesmo que realmente queira. Isso é uma dor para todos os devops. “Primeiro vou monitorar o cluster, vou monitorar a infraestrutura” – ou seja, Primeiro, ele monitorará o que está abaixo, mas não entrará no aplicativo. Porque o aplicativo é algo incompreensível para devops. Foi vazado para ele e ele não entende como funciona. E ele entende a infraestrutura e começa por ela. Mas não – você sempre precisa monitorar o aplicativo primeiro.
Não exagere com o número de alertas. Considerando a complexidade dos sistemas modernos, os alertas voam constantemente e você tem que conviver de alguma forma com esse monte de alertas. E a pessoa de plantão, depois de analisar centenas dos próximos alertas, decidirá “Não quero pensar nisso”. Os alertas devem notificar apenas sobre coisas críticas.

Nível de aplicação como unidade de negócios

Pontos chave:

ELK. Este é o padrão da indústria. Se por algum motivo você não estiver agregando logs, comece a fazê-lo imediatamente.
APM. APMs externos como forma de fechar rapidamente o monitoramento de aplicativos (NewRelic, BlackFire, Datadog). Você pode instalar essa coisa temporariamente para, pelo menos de alguma forma, entender o que está acontecendo com você.
Rastreamento. Em dezenas de microsserviços, você precisa rastrear tudo, porque a solicitação não existe mais por conta própria. É muito difícil adicionar posteriormente, por isso é melhor agendar imediatamente o rastreamento no desenvolvimento - esse é o trabalho e a utilidade dos desenvolvedores. Se você ainda não implementou, implemente! Veja Jaeger/Zipkin

Alerta

Organização de um sistema de notificação: nas condições de monitorar um monte de coisas, deveria haver um sistema unificado de envio de notificações. Você pode em Grafana. No Ocidente, todo mundo usa o PagerDuty. Os alertas devem ser claros (por exemplo, de onde vieram...). E é aconselhável controlar se as notificações são recebidas
Organização de um sistema de plantão: os alertas não devem ser enviados a todos (ou todos reagirão na multidão ou ninguém reagirá). Os desenvolvedores também precisam estar de plantão: certifique-se de definir áreas de responsabilidade, dar instruções claras e escrever exatamente para quem ligar na segunda e quarta e para quem ligar na terça e sexta (caso contrário, eles não ligarão para ninguém, mesmo no caso de um grande problema - eles terão medo de acordá-lo ou incomodar: as pessoas geralmente não gostam de ligar e acordar outras pessoas, especialmente à noite). E explique que pedir ajuda não é um indicador de incompetência (“Peço ajuda, isso significa que sou um mau trabalhador”), incentive os pedidos de ajuda.
Organização de uma “base de conhecimento” e fluxo de trabalho para processamento de incidentes: para cada incidente grave, deve ser planejada uma autópsia e, como medida temporária, devem ser registradas ações que irão resolver o incidente. E torne uma prática que alertas repetidos sejam um pecado; eles precisam ser corrigidos no código ou no trabalho de infraestrutura.

Pilha de tecnologia

Vamos imaginar que nossa pilha seja a seguinte:

coleta de dados – Prometheus + Grafana;
análise de log - ELK;
para APM ou Tracing - Jaeger (Zipkin).

A escolha das opções não é crítica. Porque se no início você entendeu como monitorar o sistema e traçou um plano, então você começa a escolher ferramentas que atendam às suas necessidades. A questão é o que você escolheu monitorar em primeiro lugar. Porque talvez a ferramenta que você escolheu no início não atenda às suas necessidades.

Alguns pontos técnicos que vejo em todos os lugares ultimamente:

O Prometheus está sendo empurrado para dentro do Kubernetes – quem inventou isso?! Se o seu cluster falhar, o que você fará? Se você tiver um cluster complexo interno, deverá haver algum tipo de sistema de monitoramento dentro do cluster e algum externo, que coletará dados de dentro do cluster.

Dentro do cluster coletamos logs e tudo mais. Mas o sistema de monitoramento deve ficar do lado de fora. Muitas vezes, em um cluster onde há o Promtheus instalado internamente, também existem sistemas que realizam verificações externas do funcionamento do site. E se suas conexões com o mundo exterior caírem e o aplicativo não funcionar? Acontece que está tudo bem por dentro, mas isso não facilita em nada as coisas para os usuários.

Descobertas

Monitorar o desenvolvimento não é a instalação de utilitários, mas o desenvolvimento de um produto de software. 98% do monitoramento atual é codificação. Codificação em serviços, codificação de verificações externas, verificação de serviços externos e isso é tudo.
Não desperdice o tempo dos seus desenvolvedores monitorando: isso pode consumir até 30% do trabalho deles, mas vale a pena.
Devops, não se preocupe se você não conseguir monitorar algo, porque algumas coisas são uma forma de pensar completamente diferente. Você não era um programador e monitorar o trabalho é exatamente o trabalho deles.
Caso o projeto já esteja em execução e não seja monitorado (e você seja gestor), aloque recursos para monitoramento.
Se o produto já estiver em produção e você for um devops que foi instruído a “configurar o monitoramento” - tente explicar à gerência sobre o que escrevi tudo isso.

Esta é uma versão estendida do relatório da conferência Saint Highload++.

Se você estiver interessado em minhas idéias e pensamentos sobre o assunto e tópicos relacionados, aqui você pode leia o canal 🙂

Fonte: habr.com

O monitoramento está morto? - Monitoramento de longa duração