Monitoramento de produção com Codex: Grafana, Kubernetes e segurança

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Production Monitoring with Codex: Grafana, Kubernetes, & Security · Canal: OpenAI · 07:33 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Cibersegurança e segurança de software, Engenharia de software com IA, Infraestrutura e hardware de IA

Resumo

O vídeo demonstra como Codex pode investigar problemas de produção usando evidências de dashboards, código e contexto de deploy, e propor correções para aprovação humana. Em um cenário, a ferramenta ajuda a diagnosticar e corrigir uma taxa elevada de erros no checkout sem reverter a versão atual. Em outro, uma skill de investigação de rollout identifica uma falha em um serviço no Kubernetes e seus efeitos em cascata. Por fim, o vídeo mostra como uma correção relacionada à segurança pode resolver um problema de produção causado por uma requisição que consome recursos em excesso.

Pontos-chave

Codex pode reunir evidências de dashboards, métricas, saúde dos serviços e código para investigar incidentes.
No exemplo de checkout, a taxa de erros cai a zero após a aplicação de uma correção, sem voltar à versão anterior.
A aprovação humana mantém o engenheiro no controle antes de aplicar as correções propostas.
Uma skill de investigação de rollout identifica a causa de falhas em um serviço no Kubernetes e a cadeia de efeitos no cluster.
Runners próprios e alertas podem iniciar investigações automaticamente, e um sistema multi-agent pode validar e aplicar correções.
O vídeo relaciona monitoramento de produção e segurança ao mostrar uma requisição que monopoliza recursos de um pool de workers.
Uma correção gerada pelo plugin Codex Security bloqueia a requisição excessivamente dispendiosa.

Capítulos

Início	Capítulo	Resumo
00:02	Investigação de erros no checkout	Codex reúne evidências de produção para investigar a alta na taxa de erros e aplicar uma correção sem reverter a versão.
02:16	Da análise manual à investigação assistida	O vídeo compara a busca manual por dashboards, logs e commits com a coleta de informações feita por um agent.
03:18	Rollout com falhas no Kubernetes	Uma skill investiga um container encerrado por falta de memória e propõe uma correção para restaurar os serviços do cluster.
05:56	Segurança e monitoramento de produção	Uma correção do Codex Security bloqueia uma requisição que monopoliza recursos e prejudica o serviço de checkout.

Citações

São três da manhã. O celular toca. Você confere: os erros estão aumentando. — 00:02

Nossa taxa de erros no checkout voltou a zero. — 01:43

O engenheiro delega boa parte da coleta manual de informações a um processo com agent. — 02:47

Você pode configurar um sistema multi-agent para validar as correções e publicá-las sem precisar intervir. — 05:25

Conseguimos bloquear essa requisição extremamente dispendiosa. — 07:02

Conceitos e entidades

Codex (ferramenta): Ferramenta apresentada para reunir evidências de incidentes e propor correções em aplicações.
Grafana (ferramenta): Plataforma de observabilidade cujo dashboard exibe métricas como saúde do checkout, versão atual e taxa de erros.
Kubernetes (conceito): Ambiente de containers e clusters no qual o vídeo demonstra a investigação de um rollout com falhas.
Cortex (ferramenta): Nome usado na transcrição para o processo que reúne informações e propõe correções de incidentes.
Codex Security (ferramenta): Plugin mencionado como fonte de uma correção que bloqueia uma requisição excessivamente dispendiosa.
Kubernetes rollout investigator skill (conceito): Skill usada no exemplo para investigar um rollout e identificar problemas e sua cadeia causal.
human-in-the-loop (conceito): Abordagem em que uma pessoa aprova a correção proposta antes que ela seja aplicada.
multi-agent system (conceito): Sistema mencionado como opção para que agents validem correções e as publiquem com menos intervenção humana.

Tradução completa (pt-BR)

00:02 Então, são 3 da manhã. Seu celular toca. Confira: os erros estão aumentando. Você abre o Grafana. Por onde começar a resolver o problema? >> Sim, este é o pior pesadelo de um engenheiro, não é? Primeiro, precisamos descobrir o que foi afetado e o que mudou. O dashboard é uma parte disso. Também precisamos do contexto do deploy e do código relevante. Reunir essas informações pode exigir muito trabalho repetitivo. >> É isso que vamos explorar hoje com o Codex.

00:33 Vamos analisar um cenário? Neste exemplo, estamos lançando uma nova versão do nosso repo. Podemos ver que agora estamos na versão atual, V2, mas, infelizmente, a taxa de erros no checkout subiu para cerca de 20%. Isso é preocupante. Ainda não sabemos exatamente o que está acontecendo. Vamos usar o Codex junto com uma skill personalizada para investigar os dados do checkout e descobrir exatamente o que está causando essa interrupção. O Codex está trabalhando nisso. Ele está

01:07 reunindo as evidências necessárias para garantir que tudo esteja funcionando como esperado. Está analisando os checkouts bem-sucedidos, o tempo de resposta, a integridade do serviço e praticamente tudo o mais de que precisamos para verificar a resposta. Em instantes, teremos o resultado. Pronto. Podemos simplesmente digitar “approve”, e isso vai lançar a versão mais recente da nossa aplicação, corrigida, com o patch aplicado e pronta para uso. Vamos ver o que acontece

01:43 quando lançamos essa versão. A taxa de erros no checkout voltou a zero. E repare que não revertemos para uma versão anterior. Continuamos na V2. Estamos executando a versão mais recente, e o Codex usou com sucesso o workflow de evidências delimitadas do repo e o release stiff para investigar e corrigir o problema. >> Sim. Então, se analisarmos o que aconteceu, estávamos vendo este dashboard do Grafana, em que os principais indicadores são a integridade do checkout, a versão atual, a taxa de erros e as métricas reais de P95.

02:16 Então, manualmente, um engenheiro poderia abrir este dashboard e tentar descobrir onde estão os logs, quais outros dashboards talvez mostrem mais informações, qual foi a alteração no código e localizar aquele commit específico. Neste caso, o que fizemos foi usar o Codex para obter mais dessas informações. O engenheiro delega grande parte dessa coleta manual a um processo com agent

02:47 que então propõe uma correção. Depois, quando nós, humanos no loop, aprovamos, podemos colocar isso em produção em questão de minutos, em vez de levar um período muito corrido, de uma hora ou algo assim. >> Ei, Ankur, sabia que isso também funciona com contêineres e clusters do Kubernetes? >> Não sabia. Vamos dar uma olhada. >> Vamos mesmo. Nesta versão, temos, bem, um

03:18 aplicativo composto por um cluster da API de inventário, um cluster da API de pedidos e, claro, um gateway de borda. Nesta nova versão, vamos lançar uma nova versão da nossa API de inventário. São apenas algumas alterações dos desenvolvedores que enviamos. Vamos verificar se essa nova versão do serviço é implantada corretamente. Parece que ela passou pelo workflow de CI/CD. Ainda assim, o contêiner foi encerrado por falta de memória (OOM killed).

03:48 O que está acontecendo? Muito confuso. Ah, e, infelizmente, isso causou falhas em cascata que derrubaram todo o nosso cluster. Nada bom. Vamos usar esta skill Kubernetes rollout investigator para investigar o rollout atual e descobrir o que está acontecendo. Estamos investigando e identificando exatamente quais são os problemas. Também estamos identificando a cadeia causal. Esse provavelmente é o aspecto mais valioso do Cortex, tanto para segurança quanto para monitoramento de produção. Ah,

04:19 pronto. Nosso patch está preparado. Vou clicar em “approve”, assim como antes. Isso vai lançar uma nova versão do contêiner da nossa API de inventário. Com isso, parece que nosso serviço voltou a um estado saudável. Nossa API de pedidos está funcionando e o gateway de borda voltou a ficar online. Não é ótimo? >> Sim. Aqui vimos um processo muito parecido, em que o engenheiro não precisa coletar as informações por conta própria. Ele delega essa tarefa ao Cortex.

04:51 E continuamos no loop enquanto o Cortex propõe a correção; depois, conseguimos acelerar a aplicação dela muito mais do que conseguiríamos sozinhos. Eu diria que, nos dois casos, dá para ver que somos nós que recebemos o alerta primeiro e depois acessamos o Cortex para que ele proponha uma correção. Também existe a alternativa de hospedar seus próprios runners no Kubernetes, no Grafana

05:25 ou em qualquer outra plataforma de observabilidade. Assim, você pode fazer com que monitorem esses alertas que ultrapassam o nível de referência. Quando isso acionar o Cortex, ele poderá automatizar completamente o processo, desde o alerta até a correção proposta. Você também pode configurar um sistema multiagente. Se quiser sair totalmente do loop, pode deixar esses outros agents validarem as correções por conta própria e fazerem o lançamento, tudo isso

05:56 sem que você precise intervir. >> Adorei. Uma coisa interessante sobre o monitoramento de produção é que ele também pode ter alguns pontos de contato com a segurança. Na verdade, vamos analisar um último exemplo, em que usamos o monitoramento de produção e o Codex Security juntos para garantir que tenhamos um serviço continuamente disponível e operacional. Acabamos de iniciar esta aplicação. Vamos comparar a

06:28 demanda do checkout e… Para contextualizar um pouco o cenário: vamos enfrentar alguns problemas de tráfego. Mais especificamente, vamos notar que, apesar de não ter havido um deploy recente, existe um problema em que >> [limpa a garganta] >> basicamente, uma solicitação de relatório está consumindo os recursos do pool de workers compartilhado e deixando o checkout sem recursos. Em termos simples, essa solicitação está tentando consumir recursos demais de uma só vez. Ela está derrubando nosso serviço. Então, o que fazemos? Nada, porque o Codex

07:02 vai fazer isso por nós. Vamos aprovar o patch que deve corrigir essa funcionalidade, gerado para nós pelo plugin Codex Security. Vamos repetir a solicitação e agora vemos que bloqueamos com sucesso essa solicitação extremamente dispendiosa. Curiosamente, esse requisito de segurança nos ajudou a resolver um problema de monitoramento de produção. Se ainda não experimentou o plugin Codex Security, ele é uma ferramenta incrivelmente poderosa. Recomendo muito, e

07:33 há muitas possibilidades de aplicação relacionadas que ainda nem exploramos nesse sentido. Então, recomendamos muito que investiguem. >> Sim, e se tiverem alguma pergunta ou algo que queiram discutir, também estamos totalmente disponíveis para conversar com vocês. Fiquem à vontade para entrar em contato e podemos continuar a partir daí.

Transcrição original

[00:02] So, it’s 3:00 a.m. Your phone goes off. Check out errors are climbing. You open Grafana. Where do you even start with fixing the problem? >> Yeah, this is the engineer’s worst nightmare, isn’t it? So, first we would have to work out what’s affected and what has changed. The dashboard is one part of that. You also do need the deployment context and the relevant code. So, gathering these pieces, if you think about it, can take a lot of repetitive work. >> That is what we are exploring with Codex today.

[00:33] Let’s walk through a scenario, shall we? So, in this example, we are pushing a new version of our repository out. We can see that we are now on the current release V2, but unfortunately, our checkout error rate has climbed to right around 20%. So, this is unfortunate. We don’t really know exactly what’s going on as of yet. And we’re going to use Codex along with a custom skill to investigate the checkout evidence and see exactly what is causing this outage. So, Codex is working through. It is

[01:07] gathering the evidence that needs to gather in order to ensure that everything is working as expected. It’s taking a look at the successful checkouts, the response time, the service health, and pretty much everything else that we need in order to check the response. As we return with the result, which we should have in a mere matter of seconds. There it is. We can just type approve, and this will push the newest version of our application out, fixed, patched, and ready to go. So, let’s see what happens

[01:43] when we push that up. Our checkout error rate has returned to zero. And note that we did not reverse do it back to an older release. We are still on V2. We are running the latest version, and Codex has successfully used the repositories bounded evidence workflow and the release stiff to investigate and repair the issue. >> Yeah, so here if we take a look at what has happened, we were looking at the dashboard here from Grafana where the main things that we’re looking at are checkout health, the current release version, the error rate, and the actual P95

[02:16] metrics. So here we would see in a manual sense an engineer might come in and take a look at this dashboard, start trying to figure out like where are the logs, where are the other dashboards that might show more information, what’s the code change, tracking down that specific commit. Um and in this case what we actually have done is more of Codex getting more of that information. The engineer’s offloading a lot of that manual gathering to um an agentic

[02:47] process which then goes on to propose a fix and then when we, the human in the loop, approves that, then we can basically just have this out within a matter of minutes rather than a very hurried um amount like an hour or so. >> Hey Ankur, did you know that this will work for containers and Kubernetes clusters as well? >> I did not. Let’s take a look. >> Let’s take a look indeed. So within this version we have a um well we have an

[03:18] application that essentially compo- is composed of an inventory API cluster, an orders API cluster, and an edge gateway of course. Within this new version we are going to roll out a new version of our inventory API. Just some developer work that we pushed out. And we’re going to verify that this new version of the service deploys healthily. So within this version it looks like it has passed our CI/CD workflow. That being said, it looks like the container is OOM killed

[03:48] regardless. What’s going on here? Very confusing. Oh, and unfortunately, it’s caused cascading failures that have taken down our entire cluster. That’s never good. So, let’s use this Kubernetes rollout investigator skill to investigate our current rollout and see what is going on here. Uh so, we are investigating. We are seeing exactly what the problems are. Uh we are also identifying the causal chain. That’s probably the most valuable aspect of Cortex both for security and production monitoring purposes. Ah,

[04:19] there we are. We have our patch ready now. I’m just going to click approve similarly to how it was before. And this is going to roll out a new version of our inventory API container. With that, it looks like our service has been restored to a healthy baseline. Our orders API is functioning and the edge gateway is back online. Isn’t that wonderful? >> Yeah, so here we saw a very similar process where the engineer doesn’t just gather the information themselves. They go and offload that over to Cortex.

[04:51] Um and then we are still in the loop as Cortex proposes the fix and then we are able to fast-track this fix much quicker than uh than we would have ourselves. And I would say like in both cases, you can see that we are the ones who get paged first and then we are the ones who go into Cortex and have it propose a fix. There is also an alternative where you actually host your own runners within either Kubernetes or Grafana. Um or any other observability platform and

[05:25] then you can have it monitor these alerts that um are above the baseline and then once that is something that triggers Cortex, it will able be able to go in and completely automate that process from the alerting to the proposed fix. And you can also set up a multi-agent system if you want to uh remove yourself from the loop entirely, you can have those um other agents go in and validate the fixes themselves and push out that all

[05:56] without you needing to become hands-on for it. >> Love it. So, the interesting thing thing about production monitoring as well is that it can have some touch points with security. As a matter of fact, let’s dive into one last example where we are essentially using uh production monitoring and Codex Security together in tandem to ensure that we have one continuously up and available service. So, we just kicked off this particular application. Um we are going to be comparing the

[06:28] checkout demand and the just to give a little bit of backstory on the scenario here is that we’re going to be encountering some uh traffic issues. Specifically, we’re going to notice that despite there not being a recent deployment, uh there is a problem where >> [clears throat] >> essentially one report request is starving the checkout in the shared worker pool. What that means in plain English is that this request is trying to pull too many resources at once. It’s taking down our service. So, what do we do about it? Well, nothing because Codex

[07:02] is going to do that for us. We are essentially going to approve the uh patch that should fix this functionality, which is generated for us through the Codex Security plugin. Uh we’re going to replay the request and we now see that we have successfully blocked this incredibly expensive request. So, interestingly enough, this security requirement actually helped us fix a production monitoring issue. Uh if you haven’t tried out the Codex Security plugin, it’s an incredibly powerful tool. Highly recommend it and

[07:33] there are a lot of lateral plays that we haven’t even put together on this front. So, highly encourage exploration on that. >> Yeah, and if you had any um questions or anything that you wanted to discuss, we are also fully available to discuss with you guys. So, feel free to reach out and we can take it from there.