Alerta: Nós queremos que o sistema de monitoramento CHAME uma pessoa para dar uma olhada;

Depuração: Já que você veio, agora quem chegou, precisa investigar para determinar a causa raiz e resolver o incidente.

Tendencias: Alimentam decisões de design e processos como planejamento de capacidade.

Canalização: No fim de o dia em que todos os sistemas de monitoramento são canais de processamento de dados.

• Métricas técnicas;
• Fatores de Saúde - não diretamente ligados a indicadores específicos de negócios;
• Temperatura, armazenamento, carga de rede e etc.
• Paine

O Prometheus possui integrações com muitos mecanismos de descoberta de serviço comuns,como Kubernetes, EC2 e Consul, mas não foi o foco deste trabalho.

Prometheus faz isso enviando uma solicitação HTTP chamada de scrape. A resposta deste scraping é analisada e armazenada. Outras métricas úteis também são adicionadas, como se o scrape foi bem-sucedido e quanto tempo demorou.

Optei por uma instalação em /opt/prometheus, tando do server como dos exportadores.

Observação: Optei por uma instalação em /opt, em usuário prometheus.

graph TD
    A[opt] -->B[prometheus]
    B --> C[prmt_abrv_versão]
    B --> D[latest_abrv]
    B --> E[conf]
    B --> F[data]

graph TD

   A[Concurrents] --> |Single push|C[Pushgateway]
   B[JOBs]        --> |Single push|C[Pushgateway]
   D[SFTPs]       --> |Single push|C[Pushgateway]
   E[FTPs]        --> |Single push|C[Pushgateway]
   C              --> |Regular Scrape|Prometheus

O Alertmanager recebe alertas dos servidores Prometheus e os transforma em notificações. As notificações podem incluir e-mail, aplicativos Slack, Teams, WhatsAPP e etc. Os alertas relacionados podem ser agregados em uma notificação.

Bem, pelo que pude perceber a estrutura geral de um nome de métrica geralmente é biblioteca_nome_unidade_sufixo. Devem começar com uma letra e podem ser seguidos por qualquer número de letras, números e sublinhados.

A convenção é usar SNAKE CASE para nomes de métricas cada componente do nome deve ser minúsculo e separado por um sublinhado.

Os sufixos _total, _count, _sum e _bucket são usados pelas métricas de contador, resumo e histograma. Além de sempre ter um sufixo _total nos contadores, você deve evitar colocar esses sufixos no final dos nomes das métricas para evitar confusão.

Você deve preferir usar unidades básicas não fixadas, como segundos, bytes e proporções. Você deve sempre incluir a unidade de seu métrica no nome.

Os nomes geralmente vão de menos para mais específicos conforme você vai da esquerda para a direita

O software não restringe o numero de métricas, contadores e etc, porem, em algum ponto, os custos operacionais e de recursos superam os benefícios para certas estratégias.

Grafana é uma ferramenta com a qual você pode construir tais painéis para muitos diferentes sistemas de monitoramento e não monitoramento, incluindo Graphite, InfluxDB, Elastic-Search e PostgreSQL

A Arquitetura Prometheus cada um dos seus serviços irá expor suas próprias métricas, usando um exportador.

O exportador do Node é projetado para ser executado como um usuário não root e deve ser executado diretamente na máquina da mesma forma que você executa um daemon do sistema como sshd ou cron.

File Integrity Monitoring (FIM) ou monitoramento de integridade de arquivos, no português, é um controle essencial de segurança que analisa e alerta alterações suspeitas na integridade de arquivos de configuração e sistema, com o objetivo de identificar possíveis ataques cibernéticos.

O cenário de TI se alterou drasticamente, com as organizações adotando massivamente a cultura de Agile e DevOps, arquitetura de microsserviços, "containerização" e migração de aplicações para a nuvem.

Nesse novo contexto, com os containers sendo efêmeros na sua essência e com novas versões de aplicações sendo entregues mais frequentemente, a quantidade de alterações aumentou consideravelmente.

Seria FIM ainda uma solução relevante de segurança? Como evitar que as mudanças tão frequentes causem a chamada "Fadiga de Alerta", que é perigosa porque incidentes legítimos de segurança podem ser ignorados?

O tempo que leva para atender a uma solicitação. É importante distinguir entre a latência de solicitações bem-sucedidas e a latência de solicitações com falha. Por exemplo, um erro HTTP 500 disparado devido à perda de conexão com um banco de dados ou outro back-end crítico pode ser atendido muito rapidamente; no entanto, como um erro HTTP 500 indica uma falha na solicitação, fatorar 500s em sua latência geral pode resultar em cálculos enganosos. Por outro lado, um erro lento é ainda pior do que um erro rápido! Portanto, é importante rastrear a latência do erro, em vez de apenas filtrar os erros.

Uma medida de quanta demanda está sendo colocada em seu sistema, medida em uma métrica específica do sistema de alto nível. Para um serviço da web, essa medida geralmente é de solicitações HTTP por segundo, talvez divididas pela natureza das solicitações (por exemplo, conteúdo estático versus conteúdo dinâmico). Para um sistema de streaming de áudio, esta medição pode se concentrar na taxa de E / S da rede ou sessões simultâneas. Para um sistema de armazenamento de valor-chave, essa medida pode ser transações e recuperações por segundo .

A taxa de solicitações que falham, seja explicitamente (por exemplo, HTTP 500s), implicitamente (por exemplo, uma resposta de sucesso HTTP 200, mas associada ao conteúdo errado) ou por política (por exemplo, "Se você se comprometeu com um segundo tempos de resposta, qualquer solicitação acima de um segundo é um erro "). Quando os códigos de resposta do protocolo são insuficientes para expressar todas as condições de falha, protocolos secundários (internos) podem ser necessários para rastrear os modos de falha parcial. O monitoramento desses casos pode ser drasticamente diferente: capturar HTTP 500s em seu balanceador de carga pode fazer um trabalho decente de capturar todas as solicitações com falha completa, enquanto apenas testes de sistema de ponta a ponta podem detectar que você está servindo o conteúdo errado.

O quão "completo" o seu serviço é. Uma medida da fração do seu sistema, enfatizando os recursos que são mais restritos (por exemplo, em um sistema com restrição de memória, mostrar memória; em um sistema com restrição de E / S, mostrar E / S). Observe que muitos sistemas degradam o desempenho antes de atingirem 100% de utilização, portanto, ter uma meta de utilização é essencial. Em sistemas complexos, a saturação pode ser complementada com medição de carga de nível mais alto: seu serviço pode lidar adequadamente com o dobro do tráfego, lidar com apenas 10% mais tráfego ou lidar com ainda menos tráfego do que recebe atualmente? Para serviços muito simples que não têm parâmetros que alteram a complexidade da solicitação (por exemplo, "Dê-me um nonce" ou "Eu preciso de um número inteiro monotônico exclusivo global") que raramente mudam de configuração, um valor estático de um teste de carga pode ser adequado . Conforme discutido no parágrafo anterior, no entanto, a maioria dos serviços precisa usar sinais indiretos, como utilização da CPU ou largura de banda da rede, que têm um limite superior conhecido. Os aumentos de latência costumam ser um indicador importante de saturação. Medir o seu tempo de resposta do 99º percentil em uma pequena janela (por exemplo, um minuto) pode dar um sinal muito precoce de saturação. Por fim, a saturação também se preocupa com as previsões de saturação iminente, como "Parece que seu banco de dados encherá o disco rígido em 4 horas". Se você medir todos os quatro sinais dourados e chamar um humano quando um sinal for problemático (ou, no caso de saturação, quase problemático), seu serviço será pelo menos decentemente coberto pelo monitoramento.

Ao construir um sistema de monitoramento do zero, é tentador projetar um sistema baseado na média de alguma quantidade: a latência média, o uso médio da CPU de seus nós ou a plenitude média de seus bancos de dados. O perigo apresentado pelos dois últimos casos é óbvio: CPUs e bancos de dados podem ser facilmente utilizados de uma forma muito desequilibrada. O mesmo se aplica à latência. Se você executar um serviço da web com uma latência média de 100 ms a 1.000 solicitações por segundo, 1% das solicitações pode facilmente levar 5 segundos. 23 Se seus usuários dependem de vários serviços da web para renderizar suas páginas, o 99º percentil de um back-end pode facilmente se tornar a resposta mediana de seu front-end .

A maneira mais simples de diferenciar entre uma média lenta e uma "cauda" muito lenta de solicitações é coletar contagens de solicitações divididas por latências (adequadas para renderizar um histograma), em vez de latências reais: quantas solicitações atendi que levaram entre 0 ms e 10 ms, entre 10 ms e 30 ms, entre 30 ms e 100 ms, entre 100 ms e 300 ms, e assim por diante? Distribuir os limites do histograma de forma aproximadamente exponencial (neste caso, por fatores de aproximadamente 3), geralmente é uma maneira fácil de visualizar a distribuição de suas solicitações.

Diferentes aspectos de um sistema devem ser medidos com diferentes níveis de granularidade. Por exemplo:

Observar a carga da CPU no intervalo de tempo de um minuto não revelará nem mesmo picos de longa duração que geram latências de cauda altas.

Por outro lado, para um serviço da web que visa não mais do que 9 horas de tempo de inatividade agregado por ano (99,9% de tempo de atividade anual), a verificação de um status de 200 (sucesso) mais de uma ou duas vezes por minuto é provavelmente desnecessariamente frequente.

Da mesma forma, verificar se o disco rígido está cheio para um serviço que visa 99,9% de disponibilidade mais de uma vez a cada 1–2 minutos é provavelmente desnecessário.

Tome cuidado ao estruturar a granularidade de suas medições. Coletar medições por segundo da carga da CPU pode render dados interessantes, mas essas medições frequentes podem ser muito caras para coletar, armazenar e analisar. Se sua meta de monitoramento exige alta resolução, mas não exige latência extremamente baixa, você pode reduzir esses custos realizando amostragem interna no servidor e, em seguida, configurando um sistema externo para coletar e agregar essa distribuição ao longo do tempo ou entre servidores.

Usando intervalos de granularidade de 5%, incremente o intervalo de utilização de CPU apropriado a cada segundo.

Essa estratégia permite observar breves pontos de acesso da CPU sem incorrer em custos muito altos devido à coleta e retenção.

Empilhar todos esses requisitos uns sobre os outros pode resultar em um sistema de monitoramento muito complexo - seu sistema pode acabar com os seguintes níveis de complexidade:

Alertas em diferentes limites de latência, em diferentes percentis, em todos os tipos de métricas diferentes

Código extra para detectar e expor as possíveis causas Painéis associados para cada uma dessas possíveis causas As fontes de complexidade potencial são infinitas. Como todos os sistemas de software, o monitoramento pode se tornar tão complexo que se torna frágil, complicado de mudar e um fardo de manutenção.

Portanto, projete seu sistema de monitoramento tendo em vista a simplicidade. Ao escolher o que monitorar, tenha em mente as seguintes diretrizes:

As regras que detectam incidentes reais na maioria das vezes devem ser o mais simples, previsíveis e confiáveis ​​possível. A coleta de dados, agregação e configuração de alerta que raramente é realizada (por exemplo, menos de uma vez por trimestre para algumas equipes SRE) devem ser removidos. Os sinais que são coletados, mas não expostos em nenhum painel pré-elaborado nem usados ​​por qualquer alerta, são candidatos à remoção. Na experiência do Google, a coleta e agregação básicas de métricas, emparelhadas com alertas e painéis, funcionou bem como um sistema relativamente autônomo. (Na verdade, o sistema de monitoramento do Google é dividido em vários binários, mas normalmente as pessoas aprendem sobre todos os aspectos desses binários.) Pode ser tentador combinar o monitoramento com outros aspectos da inspeção de sistemas complexos, como perfis de sistema detalhados, depuração de processo único , rastreando detalhes sobre exceções ou travamentos, teste de carga, coleta e análise de log ou inspeção de tráfego. Embora a maioria desses assuntos compartilhe semelhanças com o monitoramento básico, combinar muitos resultados em sistemas excessivamente complexos e frágeis. Como em muitos outros aspectos da engenharia de software, manter sistemas distintos com

Vinculando esses princípios Os princípios discutidos neste capítulo podem ser agrupados em uma filosofia de monitoramento e alerta amplamente endossada e seguida pelas equipes de SRE do Google. Embora essa filosofia de monitoramento seja um tanto aspiracional, é um bom ponto de partida para escrever ou revisar um novo alerta e pode ajudar sua organização a fazer as perguntas certas, independentemente do tamanho de sua organização ou da complexidade de seu serviço ou sistema.

Ao criar regras para monitoramento e alerta, fazer as seguintes perguntas pode ajudá-lo a evitar falsos positivos e esgotamento do pager: 24

Esta regra detecta uma condição não detectada que é urgente, acionável e ativa ou iminentemente visível para o usuário? 25 Serei capaz de ignorar esse alerta, sabendo que é benigno? Quando e por que poderei ignorar esse alerta e como posso evitar esse cenário? Este alerta indica definitivamente que os usuários estão sendo afetados negativamente? Existem casos detectáveis ​​em que os usuários não estão sendo afetados negativamente, como tráfego drenado ou implantações de teste, que devem ser filtrados? Posso agir em resposta a este alerta? Essa ação é urgente ou pode esperar até de manhã? A ação poderia ser automatizada com segurança? Essa ação será uma solução de longo prazo ou apenas uma solução alternativa de curto prazo? Outras pessoas estão sendo avisadas por este problema, tornando pelo menos uma das páginas desnecessária? Essas perguntas refletem uma filosofia fundamental em páginas e pagers:

Cada vez que o pager tocar, devo ser capaz de reagir com um senso de urgência. Só consigo reagir com urgência algumas vezes por dia antes de ficar cansado. Cada página deve ser acionável. Cada resposta de página deve exigir inteligência. Se uma página meramente merece uma resposta robótica, não deveria ser uma página. As páginas devem ser sobre um problema novo ou um evento que não tenha sido visto antes. Essa perspectiva dissipa certas distinções: se uma página satisfaz os quatro marcadores anteriores, é irrelevante se a página é acionada por monitoramento de caixa branca ou caixa preta. Essa perspectiva também amplifica certas distinções: é melhor despender muito mais esforço em detectar os sintomas do que as causas; quando se trata de causas, preocupe-se apenas com causas muito definidas e iminentes.

Monitoramento de Longo Prazo Em sistemas de produção modernos, os sistemas de monitoramento rastreiam um sistema em constante evolução com mudanças na arquitetura de software, características de carga e metas de desempenho. Um alerta que atualmente é excepcionalmente raro e difícil de automatizar pode se tornar frequente, talvez até merecendo um script hackeado para resolvê-lo. Nesse ponto, alguém deve encontrar e eliminar as causas básicas do problema; se tal resolução não for possível, a resposta do alerta merece ser totalmente automatizada.

É importante que as decisões sobre monitoramento sejam tomadas com objetivos de longo prazo em mente. Cada página que acontece hoje distrai o ser humano de melhorar o sistema para amanhã, então muitas vezes é o caso de dar um golpe de curto prazo na disponibilidade ou no desempenho para melhorar a perspectiva de longo prazo para o sistema. Vamos dar uma olhada em dois estudos de caso que ilustram essa compensação.

Bigtable SRE: A Tale of Over-Alerting A infraestrutura interna do Google é normalmente oferecida e medida em relação a um objetivo de nível de serviço (SLO; consulte Objetivos de nível de serviço ). Muitos anos atrás, o SLO do serviço Bigtable era baseado no desempenho médio de um cliente sintético bem comportado. Devido a problemas no Bigtable e nas camadas inferiores da pilha de armazenamento, o desempenho médio foi impulsionado por uma cauda "grande": os piores 5% das solicitações costumavam ser significativamente mais lentos do que o resto.

Alertas de e-mail eram acionados conforme o SLO se aproximava, e alertas de paging eram acionados quando o SLO era excedido. Ambos os tipos de alertas foram disparados de forma volumosa, consumindo uma quantidade inaceitável de tempo de engenharia: a equipe gastou uma quantidade significativa de tempo fazendo a triagem dos alertas para encontrar os poucos que eram realmente acionáveis ​​e muitas vezes perdemos os problemas que realmente afetavam os usuários, porque poucos fez. Muitas das páginas não eram urgentes, devido a problemas bem conhecidos na infraestrutura, e tiveram respostas automáticas ou não receberam resposta.

Para remediar a situação, a equipe usou uma abordagem em três vertentes: ao fazer grandes esforços para melhorar o desempenho do Bigtable, também reduzimos temporariamente nossa meta de SLO, usando a latência de solicitação do 75º percentil. Também desabilitamos os alertas de e-mail, pois eram tantos que perder tempo diagnosticando-os era inviável.

Essa estratégia nos deu espaço para respirar para realmente consertar os problemas de longo prazo no Bigtable e nas camadas inferiores da pilha de armazenamento, em vez de consertar constantemente os problemas táticos. Os engenheiros de plantão podiam realmente realizar o trabalho quando não eram acompanhados por pajens o tempo todo. Por fim, o recuo temporário de nossos alertas nos permitiu progredir mais rapidamente em direção a um serviço melhor.

Gmail: respostas previsíveis e programáveis ​​de humanos Nos primeiros dias do Gmail, o serviço foi construído em um sistema de gerenciamento de processo distribuído adaptado chamado Workqueue, que foi originalmente criado para processamento em lote de partes do índice de pesquisa. O Workqueue foi "adaptado" a processos de longa duração e posteriormente aplicado ao Gmail, mas alguns bugs na base de código relativamente opaca do agendador se mostraram difíceis de superar.

Naquela época, o monitoramento do Gmail era estruturado de forma que alertas fossem disparados quando tarefas individuais fossem “canceladas” pelo Workqueue. Essa configuração não era ideal porque, mesmo naquela época, o Gmail tinha muitos, muitos milhares de tarefas, cada tarefa representando uma fração de um por cento de nossos usuários. Nós nos preocupávamos profundamente em fornecer uma boa experiência do usuário aos usuários do Gmail, mas essa configuração de alerta era impossível de manter.

Para resolver esse problema, o Gmail SRE construiu uma ferramenta que ajudou a “cutucar” o programador da maneira certa para minimizar o impacto para os usuários. A equipe teve várias discussões sobre se deveríamos ou não simplesmente automatizar todo o loop, desde a detecção do problema até o ajuste do reescalonador, até que uma solução melhor de longo prazo fosse alcançada, mas alguns temiam que esse tipo de solução alternativa atrasaria uma correção real.

Este tipo de tensão é comum dentro de uma equipe e muitas vezes reflete uma desconfiança subjacente da autodisciplina da equipe: enquanto alguns membros da equipe querem implementar um "hack" para dar tempo para uma correção adequada, outros temem que um hack seja esquecido ou que a correção adequada será despriorizada indefinidamente. Essa preocupação é verossímil, pois é fácil construir camadas de dívidas técnicas insustentáveis ​​corrigindo os problemas em vez de fazer correções reais. Gerentes e líderes técnicos desempenham um papel fundamental na implementação de correções verdadeiras de longo prazo, apoiando e priorizando correções de longo prazo potencialmente demoradas, mesmo quando a “dor” inicial do paging diminui.

Páginas com respostas automáticas e algorítmicas devem ser uma bandeira vermelha. A falta de vontade da sua equipe em automatizar essas páginas implica que a equipe não tem confiança de que pode limpar seu débito técnico. Este é um grande problema que vale a pena escalar.

The Long Run Um tema comum conecta os exemplos anteriores de Bigtable e Gmail: uma tensão entre disponibilidade de curto e longo prazo. Freqüentemente, a força total do esforço pode ajudar um sistema raquítico a atingir alta disponibilidade, mas esse caminho geralmente é de curta duração e repleto de esgotamento e dependência de um pequeno número de membros heróicos da equipe. Assumir uma redução controlada e de curto prazo na disponibilidade costuma ser uma troca dolorosa, mas estratégica para a estabilidade de longo prazo do sistema. É importante não pensar em cada página como um evento isolado, mas considerar se o nível geralde paging leva a um sistema saudável e apropriadamente disponível com uma equipe saudável e viável e perspectiva de longo prazo. Revisamos as estatísticas sobre a frequência da página (geralmente expressa como incidentes por turno, em que um incidente pode ser composto de algumas páginas relacionadas) em relatórios trimestrais com a gerência, garantindo que os tomadores de decisão sejam mantidos atualizados sobre o carregamento do pager e a integridade geral de seus equipes.