![Apache Flink obtém alguma observabilidade com Datorios](https://optimuscloud.com.br/wp-content/uploads/2024/04/Apache-Flink-obtem-alguma-observabilidade-com-Datorios-150x150.jpg)
Apache Flink obtém alguma observabilidade com Datorios
30 de abril de 2024![Gateway de saída: atribua IPs estáveis ao tráfego que sai dos clusters K8s](https://optimuscloud.com.br/wp-content/uploads/2024/04/1714520643_Gateway-de-saida-atribua-IPs-estaveis-ao-trafego-que-sai-150x150.jpg)
Gateway de saída: atribua IPs estáveis ao tráfego que sai dos clusters K8s
30 de abril de 2024A integração e a implantação contínuas (CI/CD) são a espinha dorsal da entrega de software moderno, mas ainda há visibilidade limitada em seus processos. Veja como isso está mudando com o OpenTelemetry (OTel) e por que essas mudanças são tão interessantes.
Existem diferentes definições de CI/CD 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, da geração de software implantável e da erradicação de problemas antes que eles cheguem à produção.
A prática tornou-se essencial para reduzir processos manuais, gerar software implementável e aumentar a confiança no processo de entrega de software, mas faltam-nos ferramentas para evitar que se torne instável.
A observabilidade dos sistemas de CI ainda está nos estágios iniciais — uma oportunidade agora possibilitada por uma combinação de fatores. Vamos examinar mais de perto os aspectos dos pipelines de CI/CD que historicamente não foram observáveis, como o OpenTelemetry e os esforços relacionados estão permitindo a observabilidade de CI e o alto teto para ganhos de produtividade do desenvolvedor que estão por vir.
Ainda há muito espaço para mudar mais para a esquerda
CI e alertas têm sido tradicionalmente usados como soluções com um propósito comum. Eles trabalham em estreita colaboração como componentes essenciais do monitoramento automatizado contínuo. A integração contínua é a proteção nos estágios iniciais: ela detecta alterações, mantém a integridade da construção e monitora constantemente os sinais do sistema. Os alertas tendem a ser para fases posteriores. Ele identifica problemas que passam despercebidos pela CI. Assim, a CI estabelece as bases enquanto alerta as respostas às ameaças – trabalhando continuamente em conjunto para resolver o mesmo problema.
Mas historicamente, o foco da observabilidade tem estado no correr parte das coisas e negligenciou insights valiosos de fases anteriores, como construção, teste e implantação, e outras áreas de oportunidades importantes em fases anteriores do pipeline de CI.
Implantamos coisas, vemos coisas pegando fogo e depois tentamos mitigar o fogo.
Mas se observarmos apenas os últimos estágios do ciclo de desenvolvimento e implantação, será tarde demais. Não sabemos o que aconteceu na fase de construção ou na fase de teste, ou temos dificuldades na análise da causa raiz ou devido ao aumento do tempo médio de recuperação, e também devido a oportunidades de otimização perdidas. Sabemos que nossos pipelines de CI demoram muito para serem executados, mas não sabemos o que melhorar se quisermos torná-los mais rápidos.
Se mudarmos nosso foco de observabilidade para a esquerda, poderemos resolver os problemas antes que eles aumentem, aumentar a eficiência eliminando problemas no processo, aumentar a robustez e a integridade dos nossos testes e minimizar custos e despesas relacionados à pós-implantação e ao tempo de inatividade.
Possuindo seus próprios dados de CI com OpenTelemetry
Há uma razão pela qual o OpenTelemetry é um dos projetos mais ativos (tecnicamente, o “segundo projeto com maior velocidade”) na Cloud Native Computing Foundation. Tem sido um protocolo incrível para definir convenções semânticas e unificar tipos de sinais em logs, métricas e rastreamentos (os “três pilares” da observabilidade), bem como criação de perfil e outros tipos de sinais emergentes.
Vimos a OTel agitando-se no último ano depois de adicionar amplo suporte a padrões abertos e pontos comuns em áreas que antes eram caixas pretas. Áreas de observabilidade que antes eram altamente proprietárias, como bancos de dados, provedores de nuvem, linguagens de consulta e formatos de arquivos de log, foram abertas com um protocolo bem definido que simplesmente funcionae suporta praticamente todas as linguagens de programação populares em nosso mundo poliglota moderno.
O domínio de ferramentas do fornecedor de CI/CD tem suas próprias caixas pretas. Cada equipe de desenvolvimento usa um sistema de CI e a maioria usa mais de um. O conceito de “possuir seus próprios dados de CI” está sendo muito mais utilizado hoje por usuários que estão cansados de soluções alternativas complicadas para obter esses dados em seu próprio esquema de back-end bem compreendido, mas estão lutando com a alternância de contexto e back-ends proprietários.
É por isso que houve tanta excitação quando o Grupo de trabalho OTel CI/CD primeiro propôs a introdução de novas convenções semânticas para observabilidade CI/CD, depois seguiu recentemente com uma nova Grupo de Interesse Especial (SIG) especificamente para observabilidade de CI/CD.
Como será o futuro dos dados de observabilidade
Possuir seus próprios dados significa que você decide para onde vão esses dados e como armazená-los. Com o OpenTelemetry operando entre nossos sistemas de CI e os destinos que escolhemos, o OpenTelemetry se encarrega de convertê-lo no banco de dados e no esquema que desejamos, o que significa que uma enorme onda de inovação baseada em dados de CI que antes eram limitados agora está sendo introduzida nas ferramentas de observabilidade arena.
Nós, por exemplo, construímos um Distribuição do coletor OpenTelemetry — um binário cujos receptores, processadores e exportadores extraem dados de CI do Drone, transformam-nos no formato necessário e depois enviam esses dados para o banco de dados. Jenkins tem um plug-in que exporta dados através do protocolo OpenTelemetry (OTLP).
Este é um momento realmente emocionante para a comunidade de observabilidade. Ao obter dados de nossos CIs e integrá-los a sistemas de observabilidade, podemos rastrear os logs nas compilações e ver informações importantes – como quando algo falhou pela primeira vez – de nosso CI. A partir daí podemos descobrir o que está produzindo erros, de uma forma muito melhor identificada até o momento exato de sua origem.
A arena CI/CD libera muitos dados pré-crime para sistemas de observabilidade. Obter a telemetria de suas compilações permite que você crie cronogramas de suas ramificações de implantação e descubra insights mais profundos sobre as falhas que ocorrem, resolvendo uma ampla gama de problemas de teste instáveis, encontrando e reproduzindo facilmente as origens dos problemas e solucionando problemas de desempenho e duração do pipeline de CI/CD .
À medida que a observabilidade continua essa mudança mais à esquerda no pipeline de CI, podemos resolver os problemas antes que eles aumentem, aumentar a eficiência removendo problemas do processo, aumentar a robustez da integridade dos nossos testes e minimizar custos e despesas relacionados à pós-implantação e tempo de inatividade.
Com o impulso do OpenTelemetry por trás disso, esperamos que a área de CI/CD seja uma das áreas evolutivas mais quentes para observabilidade, juntando-se a outros casos de uso de observabilidade importantes, como monitoramento de infraestrutura e monitoramento de desempenho de aplicativos.
CI/CD é a base — e muitas vezes um pré-requisito — de todos os sistemas de produção modernos, por isso devemos enfatizar a sua importância aplicando-lhe todas as melhores práticas que utilizamos nos nossos serviços de produção.
A postagem Observabilidade de CI/CD: uma nova e rica oportunidade para OpenTelemetry apareceu pela primeira vez em The New Stack.