Observabilidade CI/CD: Novas oportunidades para OpenTelemetry

A equipe da comunidade de código aberto da China fez sua primeira transmissão ao vivo, contando a história por trás da comunidade de código aberto da China em nome do compartilhamento."

Se mudarmos nosso foco de observabilidade para a esquerda, poderemos resolver problemas de CI/CD antes que eles aumentem, como afirmaram dois engenheiros da Grafana.

Traduzido de CI/CD Observability: A Rich New Opportunity for OpenTelemetry , autor Giordano Ricci;

A integração e a implantação contínuas (CI/CD) são a espinha dorsal da entrega de software moderno, mas a visibilidade dos seus processos permanece limitada. Veja como o OpenTelemetry (OTel) está mudando isso e por que essas mudanças são tão interessantes.

CI/CD tem definições diferentes dependendo de quem você pergunta, mas a parte consistente é que ele é contínuo – um ciclo de feedback sem fim que trata da redução de processos manuais, produção de software implantável e entrega de software quando surgem problemas.

Esta prática tornou-se necessária para reduzir processos manuais, produzir software implementável e aumentar a confiança no processo de entrega de software, mas faltam-nos as ferramentas para evitar que este se torne instável.

A observabilidade dos sistemas de IC ainda está numa fase inicial – e agora, graças a uma combinação de factores, esta oportunidade é possível. Vamos dar uma olhada mais de perto nos aspectos historicamente não observáveis dos pipelines de CI/CD, como o OpenTelemetry e o trabalho relacionado permitem a observabilidade de CI e o teto alto para futuras melhorias de produtividade do desenvolvedor.

Ainda há muito espaço para mover para a esquerda

CI e alertas têm sido tradicionalmente usados como soluções com um objetivo comum. Eles trabalham em conjunto como componentes essenciais para monitoramento automatizado contínuo. A integração contínua é um protetor nos estágios iniciais: ela detecta alterações, mantém a integridade do build e monitora continuamente os sinais do sistema. Os alertas são frequentemente usados em fases posteriores. Ele identifica problemas perdidos pelo CI. Assim, a CI estabelece a base, enquanto os alertas respondem às ameaças – colaboração contínua para resolver o mesmo problema.

Mas, historicamente, o foco da observabilidade tem sido a parte "em execução" das coisas, ignorando insights valiosos desde os estágios iniciais, como construção, teste e implantação, bem como outras áreas-chave de oportunidade nos estágios iniciais de um pipeline de CI.

Implantamos coisas, vemos coisas pegando fogo e depois tentamos apagar o fogo.

Mas se olharmos apenas para as fases finais do ciclo de desenvolvimento e implementação, será tarde demais. Não sabemos o que aconteceu durante a fase de construção ou de teste, ou temos dificuldade com a análise da causa raiz ou aumento do tempo médio de recuperação e perdemos oportunidades de otimização. Sabíamos que nossos pipelines de CI estavam demorando muito para serem executados, mas se quiséssemos que eles rodassem mais rápido, não sabíamos o que melhorar.

Se mudarmos nosso foco de observabilidade para a esquerda, poderemos resolver problemas antes que eles aumentem, aumentar a eficiência reduzindo problemas no processo, aumentar a robustez e a integridade de nossos testes e minimizar custos e despesas pós-implantação e relacionados a interrupções.

Há uma razão pela qual o OpenTelemetry é um dos projetos mais ativos na Cloud Native Computing Foundation (CNCF) (tecnicamente, o “segundo projeto mais rápido”). Tem sido um excelente protocolo para definir convenções semânticas e unificar tipos de sinais para logs, métricas e rastreamentos (os “três pilares” da observabilidade), bem como análises e outros tipos de sinais emergentes.

Vimos a OTel agitar no ano passado depois de adicionar amplo suporte a padrões abertos e pontos comuns no que antes era uma área de caixa preta. Áreas de observabilidade altamente proprietárias, como bancos de dados, provedores de nuvem, linguagens de consulta e formatos de arquivos de log, foram quebradas com um protocolo bem definido que funciona e suporta quase tudo que é popular em nossa moderna linguagem de programação mundial multilíngue.

O mundo das ferramentas dos fornecedores de CI/CD tem sua própria caixa preta. Cada equipe de desenvolvimento usa um sistema de CI, e a maioria das equipes usa vários sistemas de CI. O conceito de "possuir seus próprios dados de CI" está ganhando força hoje com mais usuários que estão cansados de soluções alternativas complexas para obter esses dados em sua própria arquitetura de back-end bem compreendida, mas estão lutando com a mudança de contexto e há um back-end dedicado.

É por isso que quando o grupo de trabalho CI/CD da OTel propôs pela primeira vez a introdução de novas convenções semânticas para observabilidade CI/CD e, posteriormente, propôs um novo Grupo de Interesse Especial (SIG) especificamente para observabilidade CI/CD, houve tanta excitação.

Como será o futuro dos dados de observabilidade

Possuir seus próprios dados significa que você decide para onde eles vão e como serão armazenados. Ao executar o OpenTelemetry entre nosso sistema de CI e o destino de nossa escolha, o OpenTelemetry se encarrega de transformá-lo no banco de dados e no esquema que desejamos, o que significa que muita inovação baseada em dados de CI anteriormente isolados agora está introduzindo o campo da ferramenta de observabilidade.

Por exemplo, construímos uma distribuição OpenTelemetry Collector – um binário cujos receptores, processadores e exportadores extraem dados de CI do Drone, convertem-nos para o formato necessário e depois enviam esses dados para o banco de dados. Jenkins possui um plugin para exportar dados via OpenTelemetry Protocol (OTLP).

Este é um momento muito emocionante para a comunidade de observabilidade. Ao pegar os dados do nosso CI e integrá-los ao sistema de observabilidade, podemos detalhar os logs da construção e ver informações importantes do nosso CI – como o horário da primeira falha. A partir daí, podemos descobrir o que causou o erro de uma forma que identifique com mais precisão quando ele ocorreu.

O espaço CI/CD libera grandes quantidades de dados pré-crime para sistemas de observabilidade. A obtenção de dados de telemetria de suas compilações permite que você crie um cronograma de suas ramificações de implantação e obtenha insights sobre quais falhas ocorreram, solucione vários problemas de testes instáveis, encontre e reproduza facilmente a causa raiz dos problemas e analise o desempenho do pipeline de CI/CD e duração. Execute a solução de problemas.

À medida que a observabilidade continua avançando para a esquerda no pipeline de CI, podemos resolver problemas antes que eles aumentem, aumentar a eficiência removendo problemas do processo, melhorar a robustez e integridade dos testes e minimizar custos e despesas associados à pós-implantação e ao tempo de inatividade.

Impulsionado pela OpenTelemetry, esperamos que o espaço CI/CD se torne uma das áreas em maior evolução para observabilidade, juntando-se a outros casos de uso importantes de observabilidade, como monitoramento de infraestrutura e monitoramento de desempenho de aplicativos.

CI/CD é a base – e muitas vezes o pré-requisito – de todo sistema de produção moderno, por isso devemos enfatizar a sua importância aplicando-lhe as melhores práticas que utilizamos para serviços de produção.

Este artigo foi publicado pela primeira vez em Yunyunzhongsheng ( https://yylives.cc/ ), todos são bem-vindos para visitar.