SRE (Site Reliability Engineering) - uma abordagem para garantir a disponibilidade de projetos da web. Ele é considerado uma estrutura para o DevOps e mostra como ter sucesso na aplicação de práticas do DevOps. Este artigo é uma tradução do Capítulo 6 Monitorando sistemas distribuídos do livro Engenharia de confiabilidade do site do Google. Eu mesmo preparei esta tradução e confiei em minha própria experiência na compreensão dos processos de monitoramento. No canal de telegrama @monitorim_it e no blog Medium, também publiquei um link para a tradução do quarto capítulo do mesmo livro sobre os objetivos do nível de serviço.

Tradução por cat. Boa leitura!

As equipes do Google SRE têm os princípios básicos e as práticas recomendadas para criar sistemas bem-sucedidos de monitoramento e notificação. Este capítulo fornece recomendações sobre quais problemas um visitante da página da Web pode encontrar e como resolver problemas que dificultam a exibição da página.

Definições

Não existe um vocabulário único usado para discutir tópicos relacionados ao monitoramento. Mesmo no Google, os termos abaixo não são comumente usados, mas listaremos as interpretações mais comuns.

Monitoramento

Coleta, processamento, agregação e exibição de dados quantitativos em tempo real sobre o sistema: número de solicitações e tipos de solicitações, número de erros e tipos de erros, tempo de processamento da solicitação e tempo de atividade do servidor.

Monitoramento de caixa branca

Monitoramento com base nas métricas exibidas pelos componentes internos do sistema, incluindo logs, métricas de criação de perfil da Java virtual machine ou manipulador HTTP que geram estatísticas internas.

Monitoramento de caixa preta

Testando o comportamento do aplicativo do ponto de vista do usuário.

Painel (painéis)

Uma interface (geralmente a web) que fornece uma visão geral dos principais indicadores de saúde dos serviços. O painel pode ter filtros, a capacidade de selecionar indicadores a serem exibidos etc. A interface é criada para identificar os indicadores mais importantes para os usuários. As informações da equipe de suporte técnico também podem ser exibidas no painel: fila de solicitações, lista de erros de alta prioridade, engenheiro designado para uma determinada área de responsabilidade.

Alerta (aviso)

Notificações projetadas para serem recebidas por uma pessoa por email ou de outra maneira, que podem ser iniciadas como resultado de erros ou um aumento na fila de solicitações. As notificações são classificadas como: tickets, alertas por email e mensagens do messenger.

Causa raiz

Um defeito de software ou fator humano que não deve ocorrer novamente quando eliminado. O problema pode ter vários motivos principais: automação insuficiente de processos, defeito de software, estudo insuficiente da lógica do aplicativo. Cada um desses fatores pode ser a causa raiz e cada um deles deve ser eliminado.

Nó e máquina

Termos intercambiáveis ​​para indicar uma única instância de um aplicativo em execução em um servidor físico, máquina virtual ou contêiner. Pode haver vários serviços em uma máquina. Os serviços podem ser:

• relacionados entre si: por exemplo, um servidor de cache e um servidor da web;
• serviços não relacionados em um único hardware: por exemplo, um repositório de códigos e um assistente para um sistema de configuração, como Puppet ou Chef .

Push

Qualquer alteração na configuração do software.

Por que o monitoramento é necessário

Há várias razões pelas quais os aplicativos devem ser monitorados:

Análise de tendências longas

Qual é o tamanho do banco de dados e com que rapidez está crescendo? Como o número diário de usuários está mudando?

Comparação de desempenho

As consultas do Acme Bucket of Bytes 2.72 são mais rápidas que o Ajax DB 3.14? Qual a melhor qualidade das solicitações em cache após o aparecimento de um nó adicional? O site ficou mais lento em comparação com a semana passada?

Alerta (notificações)

Algo está quebrado e alguém precisa corrigi-lo. Ou algo vai quebrar em breve e alguém deve dar uma olhada em breve.

Criar painéis

Os painéis devem responder a perguntas básicas e incluir alguns dos "4 sinais de ouro" - latência, tráfego, erros e carga (saturação).

Realizando uma análise retrospectiva (depuração)

O atraso no processamento de solicitações aumentou e o que mais aconteceu ao mesmo tempo?
Os sistemas de monitoramento são úteis como fonte de dados para sistemas de inteligência de negócios e para simplificar a análise de incidentes de segurança. Como este livro se concentra nas áreas de engenharia nas quais os SREs têm experiência, não discutiremos aqui as técnicas de monitoramento.

O monitoramento e alertas permitem que o sistema avise quando ele quebrou ou está prestes a quebrar. Quando o sistema não pode se recuperar automaticamente, queremos que o alerta seja analisado pela pessoa, determinado se o problema é relevante, corrigido e determinado sua causa raiz. Se você não auditar os componentes do sistema, nunca receberá um alerta simplesmente porque "algo parece um pouco estranho".

A carga de alertas humanos é um uso bastante caro do tempo do funcionário. Se um funcionário estiver trabalhando, um alerta interrompe o fluxo de trabalho. Se o funcionário estiver em casa, a notificação interrompe o tempo pessoal e, possivelmente, dorme. Quando os alertas ocorrem com muita frequência, os funcionários examinam, atrasam ou ignoram rapidamente os alertas recebidos. De tempos em tempos, eles ignoram o alerta real, mascarado por eventos de ruído. As interrupções do serviço podem durar muito tempo, porque os eventos de ruído interferem no diagnóstico e solução de problemas rápidos. Sistemas de alerta eficientes têm uma boa relação sinal / ruído.

Definindo expectativas razoáveis ​​de um sistema de monitoramento

Configurar o monitoramento de um aplicativo complexo é, por si só, uma tarefa de engenharia difícil. Mesmo com uma infraestrutura significativa de ferramentas para coletar, exibir e alertar, a equipe do Google SRE com 10 a 12 membros geralmente inclui uma ou duas pessoas cujo objetivo principal é criar e manter sistemas de monitoramento. Esse número diminuiu com o tempo à medida que generalizamos e centralizamos a infraestrutura de monitoramento, mas cada equipe de SRE geralmente possui pelo menos uma equipe de monitoramento. Devo dizer que, embora seja bastante interessante observar os painéis do sistema de monitoramento, as equipes do SRE evitam cuidadosamente situações que exigem que alguém olhe a tela para monitorar problemas.

Em geral, o Google mudou para sistemas de monitoramento simples e rápidos, com ferramentas ideais para análise pós-factum. Evitamos sistemas "mágicos" que tentam prever limites ou detectar automaticamente a causa raiz. Sensores que detectam conteúdo inapropriado nas solicitações do usuário final são os únicos contra-exemplos; Enquanto esses sensores permanecerem simples, eles poderão identificar rapidamente as causas de anomalias graves. Outros formatos para usar dados de monitoramento, como planejamento de capacidade ou previsão de tráfego, são mais desafiadores. A observação realizada por um período muito longo (meses ou anos) com uma baixa taxa de amostragem (horas ou dias) revelará uma tendência de longo prazo.

A equipe do Google SRE trabalhou com sucesso variável com hierarquias de dependência complexas. Raramente usamos regras como "se eu descobrir que o banco de dados começou a funcionar lentamente, recebo uma notificação sobre a lentidão do banco de dados, caso contrário, recebo um alerta sobre um site de execução lenta". As regras baseadas em dependência geralmente se aplicam a partes invariáveis ​​do nosso sistema, como um sistema para filtrar o tráfego do usuário em um data center. Por exemplo, “se a filtragem de tráfego para o datacenter estiver configurada, não me avise sobre atrasos no processamento de solicitações de usuário” - essa é uma regra geral para notificações do datacenter. Poucas equipes no Google suportam hierarquias de dependência complexas porque nossa infraestrutura tem uma taxa de refatoração contínua e constante.

Algumas das idéias descritas neste capítulo ainda são relevantes: sempre há a oportunidade de passar mais rapidamente de um sintoma para uma causa raiz, especialmente em sistemas em constante mudança. Portanto, embora este capítulo descreva alguns objetivos para os sistemas de monitoramento e maneiras de alcançá-los, é importante que os sistemas de monitoramento sejam simples e compreensíveis para todos da equipe.

Da mesma forma, para manter um nível baixo de ruído e alto nível de sinal, as abordagens para monitorar objetos para os quais os alertas estão sendo feitos devem ser muito simples e confiáveis. As regras que geram avisos para as pessoas devem ser fáceis de entender e apresentar um problema claro.

Sintomas vs. Causas

Seu sistema de monitoramento deve responder a duas perguntas: "o que quebrou" e "por que quebrou".
"O que está quebrado" fala do sintoma e "por que está quebrado" da causa. A tabela abaixo mostra exemplos desses pacotes configuráveis.

“O que” e “por que” são alguns dos elementos mais importantes para criar um bom sistema de monitoramento com sinal máximo e ruído mínimo.

Caixa preta vs caixa branca

Combinamos um amplo monitoramento de caixa branca com um modesto monitoramento de caixa preta para métricas críticas. A maneira mais fácil de comparar a caixa preta com a caixa branca é que a caixa preta é orientada por sintomas e é reativa ao invés de monitoramento proativo: "o sistema não está funcionando no momento". A caixa branca depende dos recursos da verificação interna do sistema: logs de eventos ou servidores da web. Assim, a caixa branca permite detectar problemas futuros, mau funcionamento que se assemelha a uma retransmissão de uma solicitação, etc.

Observe que, em um sistema multicamada, um sintoma na área de responsabilidade de um engenheiro é um sintoma na área de responsabilidade de outro engenheiro. Por exemplo, o desempenho do banco de dados diminuiu. As leituras lentas do banco de dados são um sintoma para os SREs nos bancos de dados que os detectam. No entanto, para o SRE front-end, que observa um site lento, o motivo da mesma leitura lenta do banco de dados é a operação lenta do banco de dados. Portanto, o monitoramento da caixa branca às vezes é focado nos sintomas e às vezes em razões, dependendo de quão extenso é.

Ao coletar telemetria, é necessário o monitoramento de caixa branca para depuração. Se os servidores da Web responderem lentamente às consultas ao banco de dados, você precisará saber com que rapidez o servidor da Web interage com o banco de dados e com que rapidez ele responde. Caso contrário, você não poderá distinguir um servidor de banco de dados lento de um problema de rede entre o servidor da Web e o banco de dados.

O monitoramento de caixa preta tem uma vantagem importante ao enviar alertas: você inicia uma notificação para o destinatário quando o problema já levou a sintomas reais. Por outro lado, para um problema de caixa preta que ainda não surgiu, mas é iminente, o monitoramento é inútil.

Quatro sinais de ouro

Os quatro sinais de monitoramento dourados são latência, tráfego, erros e saturação. Se você puder medir apenas quatro métricas em um sistema de usuário, concentre-se nessas quatro.

Atraso

O tempo necessário para processar a solicitação. É importante distinguir entre o atraso de solicitações com e sem êxito. Por exemplo, um erro HTTP 500 causado por uma perda de conexão com um banco de dados ou outro back-end pode ser diagnosticado muito rapidamente; no entanto, um erro HTTP 500 pode indicar uma falha na solicitação. Identificar o efeito do erro 500 no atraso geral pode levar a conclusões errôneas. Por outro lado, um erro lento é mesmo um erro rápido! Portanto, é importante rastrear o atraso com um erro, e não apenas filtrar os erros.

Tráfego

O número de solicitações para o seu sistema é medido em métricas de alto nível do sistema. Para um serviço da Web, essa dimensão normalmente representa o número de solicitações HTTP por segundo, separadas pela natureza da solicitação (por exemplo, conteúdo estático ou dinâmico). Para um sistema de streaming de áudio, essa medição pode ser concentrada na velocidade de E / S da rede ou no número de sessões simultâneas. Para um sistema de armazenamento de valores-chave, essa medida pode ser transações ou resultados de pesquisa por segundo.

Erros

Essa é a frequência de solicitações sem êxito que são explicitamente (por exemplo, HTTP 500), implicitamente (por exemplo, HTTP 200, mas em combinação com o conteúdo errado) ou uma política (por exemplo, “Se você registrou a resposta em um segundo, qualquer segundo é um erro”). Se os códigos de resposta do protocolo HTTP forem insuficientes para expressar todas as condições de falha, protocolos secundários (internos) podem ser necessários para detectar falhas parciais. O monitoramento de todas essas solicitações incorretas pode não ser informativo, enquanto os testes completos do sistema ajudarão você a descobrir que está processando o conteúdo errado.

Saturação

A métrica mostra a intensidade com que seu serviço é usado. Essa é uma medida de monitoramento do sistema que identifica os recursos mais limitados (por exemplo, em um sistema com memória limitada, ela mostra memória, em um sistema com limitações de E / S, o número de E / S é mostrado). Observe que muitos sistemas degradam o desempenho antes de atingirem 100% de utilização; portanto, é importante ter um objetivo de uso.

Em sistemas complexos, a saturação pode ser complementada medindo a carga de um nível mais alto: seu serviço pode lidar adequadamente com o tráfego duplo, processar apenas 10% mais tráfego ou processar ainda menos tráfego do que atualmente? Para serviços simples que não possuem parâmetros que alteram a complexidade da solicitação (por exemplo, "Não me dê nada" ou "Não preciso de um único número inteiro monótono") que raramente alteram sua configuração, o valor estático do teste de carga pode ser adequado. discutido no parágrafo anterior, a maioria dos serviços deve usar sinais indiretos, como utilização da CPU ou largura de banda da rede, que possuem um limite superior conhecido. O aumento da latência geralmente é um indicador primário de saturação. Medir o tempo de resposta do 99º percentil em uma pequena janela (por exemplo, um minuto) pode gerar um sinal de saturação muito cedo.

Por fim, a saturação também está associada a previsões de saturação iminente, por exemplo: "Parece que seu banco de dados irá encher seu disco rígido em 4 horas".

Se você medir todos os quatro sinais dourados e quando surgir um problema com uma das métricas (ou, no caso de saturação, quase um problema), notifique a pessoa, seu serviço será mais ou menos monitorado.

Ansiedade sobre a cauda (ou instrumentação e desempenho)

Ao criar um sistema de monitoramento a partir do zero, é tentador desenvolver um sistema com base em valores médios: latência média, utilização média da CPU dos nós ou ocupação média do banco de dados. O perigo dos dois últimos exemplos é óbvio: processadores e bancos de dados são descartados de maneira muito imprevisível. O mesmo vale para o atraso. Se você executar um serviço da Web com um atraso médio de 100 ms a 1000 solicitações por segundo, 1% das solicitações poderá levar 5 segundos. Se os usuários dependem de vários desses serviços da web, o percentil 99 de um back-end pode facilmente se tornar o tempo médio de resposta da interface.

A maneira mais simples de distinguir entre uma média lenta e uma “cauda” muito lenta de consultas é coletar dimensões de consulta expressas em estatísticas (uma ferramenta adequada para exibir histogramas) em vez de atrasos reais: quantas solicitações foram atendidas pelo serviço, que levou entre 0 ms e 10 ms, entre 10 ms e 30 ms, entre 30 ms e 100 ms, entre 100 ms e 300 ms, etc. Expandir as bordas do histograma aproximadamente exponencialmente (com um coeficiente aproximado de 3) geralmente é uma maneira simples de visualizar a distribuição das consultas.

Selecionando o grau de detalhe apropriado para medições

Diferentes elementos do sistema devem ser medidos com diferentes graus de detalhe. Por exemplo:

• O monitoramento da utilização da carga da CPU em um intervalo de tempo específico não mostrará valores discrepantes de longo prazo que resultam em altas latências.
• Por outro lado, para um serviço da Web que se concentre em não mais de 9 horas de tempo de inatividade por ano (99,9% do tempo de atividade anual), a verificação de uma resposta HTTP de 200 mais de uma ou duas vezes por minuto provavelmente será desnecessariamente frequente.
• Da mesma forma, a verificação de espaço livre no disco rígido para disponibilidade de 99,9% mais de uma vez a cada 1-2 minutos é provavelmente desnecessária.

Cuide de como você estrutura a granularidade das dimensões. A frequência de coleta da carga da CPU uma vez por segundo pode fornecer dados interessantes, mas essas medições frequentes podem ser muito caras para coletar, armazenar e analisar.Se o objetivo de monitoramento exigir alta granularidade e não exigir uma alta taxa de reação, você poderá reduzir esses custos configurando a coleta de métricas no servidor e, em seguida, configurando um sistema externo para coletar e agregar essas métricas. Você pode:

1. Meça a utilização da CPU a cada segundo.
2. Corte os detalhes para 5%.
3. Agregue métricas a cada minuto.

Essa estratégia permitirá que os dados sejam coletados com alta granularidade sem sofrer alta análise e sobrecarga de armazenamento.

Tão simples quanto possível, mas não mais fácil

A imposição de requisitos diferentes entre si pode levar a um sistema de monitoramento muito complexo. Por exemplo, seu sistema pode ter os seguintes elementos complicadores:

• Alertas de acordo com diferentes valores limite para o atraso no processamento de solicitações, em diferentes percentis, para todos os tipos de indicadores diferentes.
• Escrevendo código adicional para detectar e identificar possíveis causas.
• Crie painéis relacionados para cada uma das possíveis causas de problemas.

As fontes de complicações potenciais nunca terminam. Como todos os sistemas de software, o monitoramento pode se tornar tão complicado que se torna frágil e difícil de mudar e manter.

Portanto, projete seu sistema de monitoramento para simplificá-lo o máximo possível. Ao escolher o que rastrear, lembre-se do seguinte:

• As regras que mais frequentemente capturam incidentes reais devem ser tão simples, previsíveis e confiáveis ​​quanto possível.
• As configurações para coleta, agregação e alertas de dados que raramente são executadas (por exemplo, menos de uma vez por trimestre para alguns comandos do SRE) devem ser excluídas.
• , , - - , .

No Google, a coleta e agregação básicas de indicadores, combinadas com alertas e painéis, funcionam bem como um sistema relativamente autônomo (na verdade, o sistema de monitoramento do Google é dividido em vários subsistemas, mas geralmente as pessoas conhecem todos os aspectos desses subsistemas). Pode ser tentador combinar o monitoramento com outros métodos de verificação de sistemas complexos: criação de perfil detalhado do sistema, depuração de processos, rastreamento de detalhes sobre exceções ou falhas, teste de carga, coleta e análise de logs ou verificação de tráfego. Embora a maioria dessas coisas tenha características comuns ao monitoramento básico, misturá-las resultará em muitos resultados na criação de um sistema complexo e frágil. Como em muitos outros aspectos do desenvolvimento de software, o suporte a vários sistemas é claro, simples,pontos de integração fracamente acoplados são uma estratégia melhor (por exemplo, usar uma API da web para recuperar dados resumidos em um formato que possa permanecer constante por um longo período de tempo).

Vinculando princípios

Os princípios discutidos neste capítulo podem ser integrados a uma filosofia de monitoramento e alerta endossada e respeitada pelas equipes do Google SRE. Aderir a essa filosofia de monitoramento é desejável, é um bom ponto de partida para criar ou revisar uma metodologia de alerta e pode ajudar a fazer as perguntas certas ao serviço operacional, independentemente do tamanho da sua organização ou da complexidade do serviço ou sistema.

Ao criar regras de monitoramento e alerta, fazendo as seguintes perguntas, você pode evitar falsos positivos e alertas desnecessários:

• Essa regra detecta um estado indetectável do sistema que é urgente, exigindo ação e inevitavelmente afetando o usuário?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

Essas perguntas refletem a filosofia fundamental de alertas e sistemas de alerta:

• Toda vez que um alerta chega, devo responder com urgência. Posso reagir com urgência várias vezes ao dia antes de me cansar.
• Cada alerta deve ser relevante.
• Cada resposta a um alerta deve exigir intervenção humana. Se o alerta puder ser processado automaticamente, ele não deverá aparecer.
• Os alertas devem ser sobre um novo problema ou evento que não existia antes.

Essa abordagem apaga certas diferenças: se a notificação atender às quatro condições anteriores, não importa se a notificação é enviada pelo sistema de monitoramento de caixa branca ou caixa preta. Essa abordagem também reforça certas diferenças: é melhor gastar muito mais esforço na identificação dos sintomas do que nas causas; Quando se trata de razões, você só precisa se preocupar com as razões inevitáveis.

Monitoramento a longo prazo

Nos ambientes produtivos atuais, os sistemas de monitoramento rastreiam um sistema produtivo em constante evolução com a arquitetura de software, as características de carga e o desempenho pretendido. Alertas atualmente difíceis de automatizar podem se tornar uma ocorrência frequente, talvez até digna de ser resolvida. Nesse ponto, alguém deve encontrar e eliminar as causas do problema; se essa permissão não for possível, a resposta à notificação exigirá automação total.

É importante que as decisões de monitoramento sejam tomadas com objetivos de longo prazo em mente. Cada aviso que é realizado hoje distrai uma pessoa de melhorar o sistema amanhã, com tanta frequência que há uma diminuição na disponibilidade ou produtividade de um sistema produtivo pelo tempo necessário para melhorar o sistema de monitoramento a longo prazo. Vejamos dois exemplos que ilustram esse fenômeno.

Bigtable SRE: Histórico de alertas

A infraestrutura interna do Google é normalmente fornecida e medida em termos de nível de serviço (SLO). Muitos anos atrás, o serviço SLO da Bigtable era baseado no desempenho médio de uma transação sintética simulando um cliente que trabalha. Devido a problemas no Bigtable e em níveis mais baixos da pilha de armazenamento de dados, o desempenho médio ocorreu devido à cauda “grande”: os piores 5% dos pedidos eram geralmente muito mais lentos que os demais.

As notificações por email foram enviadas à medida que se aproximavam do limite do SLO, e os alertas ao mensageiro foram enviados quando o SLO foi excedido. Os dois tipos de alertas foram enviados com frequência suficiente, consumindo quantidades inaceitáveis ​​de tempo de engenharia: a equipe gastou um tempo considerável analisando alertas para encontrar alguns que eram realmente relevantes. Muitas vezes perdíamos um problema que realmente afetava os usuários, porque apenas alguns dos alertas eram especificamente para esse problema. Muitos dos alertas não eram urgentes devido a problemas compreensíveis na infraestrutura e funcionavam de maneira padrão ou não foram processados.

Para remediar a situação, a equipe adotou uma abordagem tripla: ao fazer grandes esforços para melhorar o desempenho da Bigtable, definimos temporariamente o percentil 75 como nosso objetivo de SLO para atrasar a resposta à solicitação. Também desativamos os alertas por e-mail, pois havia muitos deles que eram impossíveis de gastar tempo diagnosticando-os.

Essa estratégia nos permitiu fazer uma pausa para começar a corrigir problemas de longo prazo no Bigtable e nos níveis mais baixos da pilha de armazenamento de dados, em vez de corrigir constantemente problemas táticos. Os engenheiros podiam realmente fazer o trabalho quando não eram constantemente atacados por alertas. Por fim, o atraso temporário no processamento de notificações nos permitiu melhorar a qualidade do serviço.

Gmail: respostas previsíveis e algorítmicas de pessoas

No início, o Gmail foi criado em um sistema de controle de processo da fila de trabalho modificado, criado para fragmentos de índice de pesquisa de processo em lote. A fila de trabalho foi adaptada a processos de longa duração e posteriormente aplicada ao Gmail, mas alguns erros no código do agendador opaco acabaram sendo muito difíceis de resolver.

Naquele momento, o monitoramento do Gmail era estruturado de forma que os alertas eram acionados quando tarefas individuais eram canceladas usando a fila de trabalho. Essa abordagem não era ideal, porque mesmo naquela época o Gmail executava muitos milhares de tarefas, cada uma delas fornecida a frações de um por cento de nossos usuários. Garantimos que os usuários do Gmail tivessem uma boa interface de usuário, mas a elaboração de tantos alertas era inatingível.

Para resolver esse problema, o Gmail SRE criou uma ferramenta que ajudou a depurar o agendador da melhor maneira possível, a fim de minimizar o impacto nos usuários. A equipe teve várias discussões sobre se era apenas necessário automatizar todo o ciclo, desde detectar um problema até resolvê-lo até que uma solução de longo prazo fosse encontrada, mas alguns deles estavam preocupados com o fato de que tal solução atrasaria a correção real do problema.

Essa tensão era comum na equipe e geralmente refletia uma falta de confiança na autodisciplina: enquanto alguns membros da equipe desejam dar tempo para uma correção correta, outros se preocupam com o fato de que a correção final será esquecida e a correção temporária durará para sempre. Esse problema merece atenção, pois é muito fácil corrigir problemas temporariamente, em vez de precisar corrigir a situação continuamente. Gerentes e equipe técnica desempenham um papel fundamental na implementação de correções de longo prazo, apoiando e priorizando correções potencialmente de longo prazo, mesmo quando a “dor” inicial desaparece.

Alertas recorrentes regulares e respostas algorítmicas devem ser sinalizadores vermelhos. A falta de vontade da sua equipe em automatizar esses alertas significa que a equipe não tem confiança de que pode confiar nos algoritmos. Esse é um problema sério que precisa ser resolvido.

A longo prazo

Um tema comum vincula os exemplos do Bigtable e do Gmail: a competição entre a disponibilidade a curto e a longo prazo. Freqüentemente, um grande esforço pode ajudar um sistema frágil a obter alta disponibilidade, mas esse caminho geralmente dura pouco, repleto de desgaste da equipe e dependência de um pequeno número de membros dessa equipe muito heróica.

Uma diminuição controlada e de curto prazo na disponibilidade geralmente é uma tarefa dolorosa, mas estrategicamente importante para a estabilidade do sistema a longo prazo. É importante não considerar cada alerta isoladamente, mas considerar se o nível geral de alertas leva a um sistema saudável e adequadamente acessível, com uma equipe viável e um prognóstico favorável. Analisamos as estatísticas da frequência dos alertas (geralmente expressos como incidentes de turno, quando um incidente pode consistir em vários incidentes relacionados) em relatórios trimestrais com a gerência, que permite que os tomadores de decisão apresentem constantemente a carga no sistema de alerta e no estado geral da equipe.

Conclusão

O caminho para o monitoramento e alertas saudáveis ​​é simples e direto. Ele se concentra nos sintomas do problema para o qual os alertas são emitidos e o monitoramento da causa serve como uma ajuda para depurar problemas. O monitoramento de sintomas é ainda mais fácil, quanto mais alto você estiver na pilha que controla, embora o monitoramento da carga e do desempenho do banco de dados deva ser feito diretamente nele. As notificações por email têm benefícios muito limitados e tendem a crescer com facilidade; em vez disso, você deve usar um painel que monitore todos os problemas atuais enviados por email. O painel também pode ser emparelhado com um log de eventos para analisar correlações históricas.

A longo prazo, é necessário obter uma alternância bem-sucedida de alertas sobre sintomas e problemas reais inevitáveis, adaptar metas para garantir que o monitoramento suporte o diagnóstico rápido.

Obrigado por ler a tradução até o fim. Inscreva-se no meu canal de telegrama sobre o monitoramento @monitorim_it e o blog no Medium .