Uma visão para a observabilidade na prática

Uma das principais tendências da infraestrutura de software em 2019 é a Observabilidade .

Ele ganhou muita atenção recentemente.

O que é observabilidade?

Há muitas discussões e piadas sobre esse termo. Por exemplo:

• Por que chamar isso de monitoramento? Isso não é mais sexy o suficiente.
• Observabilidade, porque mudar o nome de Ops como DevOps não era ruim o suficiente, agora eles estão desenvolvendo o monitoramento também.
• O novo Chuck Norris do DevOps.
• Sou um engenheiro que pode ajudar a fornecer monitoramento para os outros engenheiros da organização.
• > Ótimo, aqui estão $ 80k.
• Sou um arquiteto que pode ajudar a fornecer observabilidade para aplicativos nativos da nuvem e baseados em contêiner.
• > Incrível! Aqui estão $ 300k!

Cindy sridharan

Qual é a diferença entre monitoramento e Observabilidade, se houver?

Olhando para trás ...

Anos atrás, executamos nosso software principalmente em servidores físicos. Nossas aplicações eram monólitos construídos sobre LAMP ou outras pilhas. Verificar o tempo de atividade foi tão simples quanto enviar pings regulares e verificar o uso de CPU / disco para seu aplicativo.

Mudança de paradigma

A principal mudança de paradigma veio dos campos de infraestrutura e arquitetura. Arquiteturas em nuvem, microsserviços, Kubernetes e infraestrutura imutável mudaram a maneira como as empresas constroem e operam sistemas.



Como resultado da adoção dessas novas idéias, os sistemas que construímos tornaram-se cada vez mais distribuídos e efêmeros.

As estruturas de virtualização, contêiner e orquestração são responsáveis ​​por fornecer recursos computacionais e lidar com falhas, criando uma camada de abstração para hardware e rede.

Avançar para a abstração a partir do hardware e da rede subjacentes significa que devemos nos concentrar em garantir que nossos aplicativos funcionem conforme pretendido no contexto de nossos processos de negócios.

O que é monitoramento?

Monitorar é essencialmente para operações o que é teste para desenvolvimento de software. De fato, os testes verificam o comportamento dos componentes do sistema em relação a um conjunto de entradas em um ambiente em área restrita, geralmente com um grande número de componentes simulados.



A questão principal é que a quantidade de possíveis problemas na produção não pode ser coberta com testes de forma alguma. A maioria dos problemas em um sistema maduro e estável é desconhecida, relacionada não apenas ao desenvolvimento de software em si, mas também ao mundo real.

Black Box vs. Monitoramento de caixa branca

Existem duas abordagens para o monitoramento.

No caso de monitoramento de caixa preta, tratamos o sistema ou partes dele como uma caixa preta e os testamos fora. Isso pode significar verificar chamadas de API, tempo de carregamento ou disponibilidade de diferentes partes do sistema. Nesse caso, a quantidade de informações e controle sobre o sistema é limitada.



O monitoramento de caixa branca refere-se à situação em que obtemos informações dos internos do sistema. Esta não é uma idéia revolucionária, mas ganhou muita atenção recentemente.



Então, Observabilidade é apenas outro nome para o monitoramento de caixa branca? Nem tanto.

Por que precisamos de um novo tipo de monitoramento

Freqüentemente, é feita uma distinção entre monitoramento e o conceito de Observabilidade, com este último definido como algo que reúne dados sobre o estado da infraestrutura / aplicativos e rastreamentos de desempenho de uma maneira ou de outra (https://thenewstack.io/monitoring-and -observabilidade-qual-a-diferença-e-porque-isso-importa /).

Ou, de acordo com honeycomb.io :

• "Você está verificando o status e os comportamentos de seus sistemas em relação a uma linha de base conhecida, para determinar se algo não está se comportando conforme o esperado."
• "Você pode fazer verificações no Nagios para verificar se várias coisas estão dentro dos limites conhecidos."
• "Você pode criar painéis com Graphite ou Ganglia para agrupar conjuntos de gráficos úteis."
• "Todas essas são ferramentas excelentes para entender as incógnitas conhecidas sobre o seu sistema."

Um grande ecossistema de produtos como New Relic, HP e AppDynamics evoluiu. Todas essas ferramentas são perfeitamente adequadas para monitoramento de nível baixo e intermediário ou para problemas de desempenho de desembaraço.

No entanto, eles não conseguem lidar com consultas de dados com alta cardinalidade e apresentam desempenho ruim no caso de problemas relacionados a problemas de integração de terceiros ou ao comportamento de grandes sistemas complexos com enxames de serviços trabalhando em ambientes virtuais modernos.

Por que os painéis são inúteis

Na verdade, eles não são. Mas somente se você souber quando e onde assistir. Caso contrário, é melhor assistir ao YouTube.

Os painéis não são dimensionados.

Imagine uma situação em que você tenha várias métricas relacionadas à sua infraestrutura (por exemplo, cpu_usage / cotas de disco) e aplicativos (por exemplo, JVM assignment_speed / GC Runs) etc. O número total dessas métricas pode facilmente crescer para milhares ou dezenas de milhares. Todos os seus painéis são verdes, mas ocorre um problema em um serviço de integração de terceiros. Seus painéis ainda estão verdes, mas os usuários finais já estão afetados.

Você decide adicionar verificações de serviços de integração de terceiros ao seu monitoramento e obter um conjunto adicional de métricas e painéis no seu aparelho de TV. Até o próximo caso surgir.

Quando perguntado por que os clientes não podem abrir um site, a resposta geralmente é assim:



A espaguetificação de painéis

Embora a adoção da telemetria de diferentes partes do sistema seja uma prática comum, geralmente termina com um monte de espaguete desenhado em um painel.

Essas são as métricas operacionais do GitLab que são abertas ao público.

E isso é apenas uma pequena parte de todo um exército de painéis



Parece uma tapeçaria, onde é fácil perder o fio.

Agregação de log

Ferramentas de agregação de log, como ELK Stack ou Splunk, são usadas pela grande maioria das empresas de TI modernas. Esses instrumentos são incrivelmente úteis para análise de causa raiz ou post mortem. Eles também podem ser usados ​​para monitorar algumas condições que podem ser derivadas do seu fluxo de logs.

No entanto, ele vem com um custo. Os sistemas modernos geram enormes quantidades de logs e um aumento no seu tráfego pode esgotar seus recursos ELK ou elevar a taxa de faturamento do Splunk para a lua.

Existem algumas técnicas de amostragem que podem reduzir a quantidade dos chamados registros de perfuração em várias ordens de magnitude e salvar todos os anormais. Ele pode fornecer uma visão geral de alto nível sobre o comportamento normal do sistema e uma visão detalhada de qualquer evento problemático.

De logs para um modelo de eventos

Geralmente, as linhas de log refletem eventos que ocorrem no sistema. Por exemplo, estabelecendo uma conexão, autenticando, consultando o banco de dados e assim por diante. A execução de todas as fases significa que um trabalho foi concluído. O evento de definição como uma parte lógica do trabalho pode ser visto como parte dos Objetivos de Nível de Serviço relacionados a um serviço específico. Por "serviço", quero dizer não apenas serviços de software, mas também certos dispositivos físicos, como sensores ou outras máquinas do mundo da IoT.

Também é muito complementar aos princípios de design orientados por domínio. O isolamento e o compartilhamento de responsabilidades entre serviços ou domínios tornam os eventos específicos para cada parte do trabalho em todas as partes do sistema.

Por exemplo, os eventos do serviço de login podem ser separados por successful_logins, failed_logins com o próprio contexto dinâmico.

Métricas e eventos devem criar uma história em torno dos processos no sistema.

Os eventos podem ser amostrados de forma que, no caso do comportamento normal do sistema, apenas uma fração deles seja armazenada e todos os eventos problemáticos sejam armazenados como estão. Os eventos são agregados e armazenados como principais indicadores de desempenho, com base nos objetivos de determinados serviços.

Ele pode reunir métricas de objetivo de serviço e seus metadados relacionados, que aproveitam as conexões entre os problemas momento a momento.

Escrito com alta cardinalidade em mente, esses dados revelam o desconhecido desconhecido no sistema.

Esta é uma forma de instrumentação de software? Sim No entanto, quando você compara as quantidades de dados provenientes do registro no nível de depuração e da instrumentação completa, a divisão dos registros em eventos torna possível beber de uma mangueira de incêndio no ambiente de produção sem se afogar em dados e custos.

"Definir um evento como uma peça de trabalho pode ser visto como relacionado aos objetivos de um serviço específico".

Por que não estamos prontos para soluções completas de IA

AI é uma boa palavra de ordem para atrair investimentos de startups. No entanto, o diabo está sempre nos detalhes.

1. Reprodutibilidade

O problema de um sistema totalmente baseado em aprendizado de máquina (a chamada abordagem de IA completa) é que, por estar constantemente aprendendo novos comportamentos, não há reprodutibilidade. Se você deseja entender por que, por exemplo, uma condição resultou em um alerta, não é possível investigá-lo, porque os modelos já foram alterados. Qualquer solução que dependa do aprendizado constante do comportamento enfrenta esse problema.

É essencial otimizar o próprio sistema quando você estiver operando com dados ou métricas altamente granulares, mas é muito difícil fazê-lo sem reprodutibilidade.

2. Consumo de recursos

Para qualquer tipo de aprendizado de máquina constante, você precisa de uma quantidade significativa de recursos computacionais. Geralmente, isso assume a forma de conjuntos de dados de processamento em lote. No caso de alguns produtos, os requisitos mínimos para o processamento de 200.000 métricas são v32CPU e 64 Gb de RAM. Se você deseja dobrar a quantidade de métricas, precisa de outra máquina que atenda aos mesmos requisitos.

3. Você ainda não pode escalar a automação completa do aprendizado profundo

De acordo com uma tese de mestrado escrita por Samreen Hassan Massak (ainda não totalmente concluída), o processo de treinamento para milhares de métricas exige dias de tempo de CPU ou horas de GPU. Você não pode escalá-lo sem gastar seu orçamento.

4. Velocidade

Soluções como a Amazon Forecast, que funcionam como serviços de processamento em lote que ingerem dados e aguardam o término da computação, não são adequadas para isso.

5. Clareza

Com base na experiência do Google:

"As regras que detectam incidentes reais com mais frequência devem ser o mais simples, previsíveis e confiáveis ​​possíveis".

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

Quando os modelos ou regras estão constantemente mudando, você perde a compreensão do sistema e ele funciona como uma caixa preta.

Anomalias = alertas?

Digamos que você tenha milhares de métricas e, se quiser ter uma boa observabilidade, precisará coletar dados importantes. Cada batimento cardíaco do sistema gera flutuações estatísticas em seu enxame de métricas.

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

As principais lições que podem ser extraídas do projeto Kale de Etsy:



Alertar sobre anomalias de métricas acabará por levar a enormes quantidades de alertas e trabalho manual a jogar com limites e filtros de criação manual.

Por que precisamos de uma abordagem de streaming

Obter observabilidade e trazer o desconhecido para o centro das atenções requer dados altamente granulares que podem ser categorizados por data centers, versões de compilação, serviços, plataformas e tipos de sensores. Agregá-los em qualquer combinação é combinatória por sua natureza.

Mesmo que você projete cuidadosamente suas métricas e eventos, acabará tendo uma quantidade bastante grande delas. Ao operar nessa escala em tempo real, consultas regulares ou trabalhos em lote terão latência e sobrecarga significativas.

Coisas a serem consideradas

Qualquer operação executada em um fluxo infinito de dados é um empreendimento de engenharia. Você precisa lidar com as implicações relacionadas aos sistemas distribuídos.



Ao monitorar eventos, objetivos de nível de serviço ou KPI em alto nível, você precisa ser reativo e não consultar constantemente seus dados, mas operar em um fluxo que pode ser escalonado horizontalmente e obter uma grande taxa de transferência e velocidade sem consumir uma quantidade enorme de recursos.

Algumas estruturas de streaming, como Apache Storm, Apache Flink e Apache Spark, são orientadas para o processamento de tupla e não para o processamento de séries temporais pronto para uso.

Também há problemas com a semântica de sistemas distribuídos.

Digamos que você tenha muitas implantações em diferentes data centers. Você pode ter um problema de rede e o agente que armazena suas métricas de KPI não pode encaminhá-las. Depois de um tempo - digamos 3 minutos - o agente envia esses dados para o sistema. E essas novas informações devem acionar uma ação com base nessa condição. Devemos armazenar essa janela de dados na memória e verificar condições não apenas para trás, mas também para frente no tempo? Qual deve ser o tamanho dessa janela de dessincronização? Operar em milhares de métricas em tempo real torna essas perguntas muito importantes. Você não pode armazenar tudo no banco de dados no caso de sistemas de processamento de fluxo sem perder velocidade.

A análise de fluxo em tempo real de dados de séries temporais em sistemas distribuídos é complicada, porque os eventos relacionados ao comportamento do sistema podem estar fora de ordem e as condições que podem surgir com base nesses dados dependem da ordem dos eventos. Isso significa que uma semântica pelo menos uma vez pode ser alcançada facilmente, mas quando apenas uma vez pode ser muito mais difícil.

Recursos desejáveis ​​de uma estratégia de monitoramento de acordo com a pasta de trabalho do Google SRE

• “O design moderno geralmente envolve a separação de coleta e avaliação de regras (com uma solução como o servidor Prometheus), armazenamento de séries temporais de longo prazo (InfluxDB), agregação de alertas (Alertmanager) e painel de controle (Grafana).”
• “Os sistemas baseados em logs do Google processam grandes volumes de dados altamente granulares. Há algum atraso inerente entre quando um evento ocorre e quando é visível nos logs. Para análises que não são sensíveis ao tempo, esses logs podem ser processados ​​com um sistema em lote, interrogados com consultas ad hoc e visualizados com painéis. Um exemplo desse fluxo de trabalho seria usar o Cloud Dataflow para processar logs, o BigQuery para consultas ad hoc e o Data Studio para os painéis. "
• “Por outro lado, nosso sistema de monitoramento baseado em métricas, que coleta um grande número de métricas de todos os serviços do Google, fornece muito menos informações granulares, mas em tempo quase real. Essas características são bastante típicas de outros sistemas de monitoramento baseados em logs e métricas, embora haja exceções, como sistemas de logs em tempo real ou métricas de alta cardinalidade. ”
• “Em um mundo ideal, o código de monitoramento e alerta deve estar sujeito aos mesmos padrões de teste que o desenvolvimento do código. Embora os desenvolvedores do Prometheus estejam discutindo o desenvolvimento de testes de unidade para monitoramento, atualmente não existe um sistema amplamente adotado que permita que você faça isso. ”
• “No Google, testamos nosso monitoramento e alertas usando uma linguagem específica de domínio que nos permite criar séries temporais sintéticas. Em seguida, escrevemos asserções com base nos valores de uma série temporal derivada ou no status de disparo e na presença de alertas específicos no rótulo. ”

Muito obrigado a Charity Majors e Cindy Sridharan
Thanx para Sigrid Maasen por sua ajuda