Alex Camargo, Head de Observabilidade da Delfia, explica como traces, OpenTelemetry, IA, SLOs e telemetria ajudam a localizar falhas, reduzir riscos e conectar desempenho técnico ao resultado financeiro
Em operações financeiras digitais, uma transação que leva alguns segundos a mais para ser concluída pode parecer, à primeira vista, apenas um problema de performance. Mas, quando milhões de operações atravessam aplicações, APIs, microsserviços, sistemas antifraude, redes, bancos de dados e parceiros externos, identificar exatamente onde ocorreu uma degradação pode determinar a diferença entre uma correção rápida e uma perda relevante para o negócio.
É nesse ponto que a observabilidade deixa de ser apenas uma camada de monitoramento e passa a integrar a própria arquitetura de operação de ambientes críticos.
Para entender o que precisa existir tecnicamente por trás dessa visibilidade, o Crypto ID conversou com Alex Camargo, Head de Observabilidade da Delfia, empresa de curadoria de jornadas digitais.
Em vez de discutir apenas por que a observabilidade é importante, avançamos sobre como logs, métricas e traces são correlacionados, o papel do OpenTelemetry, o acompanhamento de transações financeiras de ponta a ponta, o uso de inteligência artificial, a definição de SLOs e error budgets e a fronteira entre observabilidade e ferramentas específicas de segurança.
Quem é Alex Camargo
Alex Camargo reúne mais de 19 anos de experiência em Tecnologia da Informação, sendo os últimos 12 anos dedicados a posições de gestão e liderança. Sua trajetória envolve estratégia orientada a negócios, vendas técnicas B2B de soluções e serviços, operações, inovação, delivery e projetos relacionados à transformação digital. Atualmente, é Head de Observabilidade da Delfia.
Camargo também é coautor do livro “Jornada da Observabilidade – Unindo tecnologia e negócios para melhorar a experiência do cliente”, obra que reuniu especialistas brasileiros para discutir observabilidade a partir da conexão entre tecnologia, experiência do cliente e resultados de negócio. O livro foi apresentado em seu lançamento como o primeiro dedicado à observabilidade no Brasil.
O Crypto ID já destacou a participação de Alex Camargo na obra e sua contribuição como autor. Leia: CTO da Delfia, Alex Camargo, é coautor do primeiro livro sobre observabilidade no Brasil
A seguir, Alex Camargo detalha o que acontece por trás de uma arquitetura de observabilidade capaz de acompanhar ambientes distribuídos e operações financeiras críticas.
Leia entrevista na íntegra!
Crypto ID: Como logs, métricas, traces e eventos são coletados e correlacionados em ambientes que envolvem aplicações, APIs, microsserviços, bancos de dados, cloud, infraestrutura on-premises e fornecedores externos? Onde normalmente surgem os principais pontos cegos?
Alex Camargo: Observabilidade moderna se apoia em três sinais complementares. Logs registram eventos discretos (“o que aconteceu”), métricas agregam séries temporais numéricas (“quanto e com que frequência”), traces reconstroem o caminho de uma requisição através dos serviços (“por onde passou e quanto demorou em cada etapa”).
Em um ambiente típico aplicações, APIs, microsserviços, bancos de dados, cloud, on-premises e fornecedores externos o padrão de coleta segue três camadas. Na origem, agentes e SDKs instrumentam cada componente, o OpenTelemetry Collector (ou agentes equivalentes) recebe, processa e roteia esses dados. Em seguida, um pipeline de telemetria normaliza, enriquece (adiciona metadados do ambiente, versão, região, cliente) e apresenta os dados. Por fim, backends de armazenamento e análise correlacionam tudo.
A correlação é o que transforma dados isolados em observabilidade real, e depende de identificadores propagados de ponta a ponta: o trace_id e o span_id viajam junto com a requisição (via cabeçalhos W3C Trace Context), enquanto rótulos consistentes (serviço, ambiente, versão, transaction_id) permitem cruzar um log de erro com o trace da transação e com o pico de latência na métrica correspondente.
Os principais pontos cegos surgem justamente onde a propagação se rompe:
• Fronteiras com terceiros (gateways de pagamento, adquirentes, birôs de crédito, antifraude externo): você mede a latência da chamada, mas perde a visibilidade de dentro do parceiro.
• Camadas de rede e infraestrutura intermediária: load balancers, service mesh, filas, DNS e NAT frequentemente não propagam contexto de trace.
• Sistemas legados e mainframe, difíceis de instrumentar, que só aparecem como uma “caixa-preta” no meio do fluxo.
• Processamento assíncrono (filas, eventos, batch): quando a propagação de contexto não acompanha a mensagem, o trace se fragmenta.
• Cardinalidade e amostragem: excesso de amostragem para conter custo pode descartar exatamente a transação anômala que você precisava investigar.
Crypto ID: Seria interessante você explicar o papel do OpenTelemetry na prática. O que ele resolve, como reduz dependência de fornecedores e quais desafios ainda existem para implementá-lo em ambientes legados ou altamente distribuídos?
Alex Camargo: O problema que resolve. Historicamente, cada ferramenta de observabilidade exigia seu próprio agente e formato proprietário. Trocar de fornecedor significava reinstrumentar 100% do ambiente do ambiente que compõe o Stack de tecnologia. O OpenTelemetry (OTel) projeto da CNCF, hoje o segundo mais ativo depois do próprio Kubernetes define um padrão aberto e único de instrumentação (APIs, SDKs e protocolo OTLP) para os três sinais principais (traces, métricas e logs).
Como reduz a dependência de fornecedor. A instrumentação passa a ser um ativo da empresa, não do fornecedor. Você instrumenta uma vez com OTel e o Collector roteia a telemetria para qualquer backend inclusive para vários ao mesmo tempo. Trocar de plataforma vira uma mudança de configuração no Collector, não um reprojeto. Isso muda a dinâmica do mercado: o custo de saída cai, e com ele o poder de barganha do fornecedor.
Desafios que permanecem, especialmente em ambientes legados e distribuídos:
• Instrumentação de legado: sistemas antigos e componentes de terceiros muitas vezes não aceitam SDKs modernos; a saída é instrumentação manual, proxies ou conversão de formatos.
• Maturidade desigual dos sinais: traces e métricas estão estáveis; logs amadureceram por último e a adoção ainda varia por linguagem.
• Propagação de contexto consistente entre times, linguagens e sistemas assíncronos exige disciplina e convenções (nomes de atributos, semantic conventions) que precisam de atenção.
• Custo e volume: OTel facilita gerar telemetria, o que pode explodir custos de ingestão e armazenamento sem uma estratégia de amostragem e retenção.
• Curva de adoção: operar o Collector em escala e definir pipelines é uma competência nova para muitas equipes.
Em resumo, o OTel resolve a padronização e a portabilidade, mas transfere para a organização a responsabilidade de governança da telemetria o que antes era imposto pelo fornecedor agora precisa ser decidido internamente.
Crypto ID: Como acompanhar uma operação de ponta a ponta? Em uma transação Pix ou pagamento com cartão, por exemplo, seria interessante mostrar como identificar em qual componente ocorreu a degradação e diferenciar problemas da aplicação, infraestrutura, rede, antifraude, API ou parceiro externo.
Alex Camargo: O objetivo é acompanhar uma transação de ponta a ponta e localizar, em segundos, onde ocorreu a degradação. Exemplo como um pagamento Pix ou por cartão: a jornada atravessa o app/browser, o API gateway, o serviço de pagamentos, o antifraude, o processador/adquirente, o parceiro externo (bandeira, banco emissor, SPI/Bacen no caso do Pix) e os bancos de dados de suporte.
A técnica central é o trace distribuído com um identificador de negócio anexado. Além do trace_id técnico, cada span carrega o transaction_id da operação. Assim, é possível abrir uma transação específica e ver o waterfall: quanto tempo cada componente consumiu.
Como diferenciar a origem da degradação:
• Aplicação: o span do próprio serviço tem tempo alto de processamento (não de espera), acompanhado de erros de código, exceções nos logs correlacionados ou aumento de garbage collection/CPU no processo.
• Infraestrutura: latência sobe junto com utilização de CPU, memória, I/O de disco ou throttling do banco; o span mostra tempo gasto esperando recurso, não processando.
• Rede: gap de tempo entre spans (o cliente enviou, o servidor demorou a receber), retransmissões TCP, timeouts de conexão, erros de DNS ou mesh.
• Antifraude: o span do serviço de score/fraude concentra o tempo útil distinguir latência da decisão (modelo lento) de fila de análise manual.
• API/gateway: erros 4xx/5xx e latência no próprio gateway, rate limiting, problemas de autenticação/TLS.
• Parceiro externo: o span da chamada de saída mostra alta latência ou erro, mas o tempo interno do seu serviço está normal a espera está “do outro lado”. Aqui entram métricas de disponibilidade e latência por parceiro, com circuit breakers e fallback.
Na prática, a diferenciação vem de cruzar o trace (onde o tempo foi gasto) com as métricas de recurso (havia saturação?) e os logs (houve erro explícito?) daquele exato intervalo. Uma boa montagem permite responder “a lentidão do Pix nos últimos 10 minutos veio do emissor X, não da nossa plataforma” com evidência, não suposição o que muda completamente a conversa com o parceiro e com o negócio.
Crypto ID: Alex, que tipo de inteligência artificial está sendo utilizada hoje em observabilidade? Ela atua apenas na correlação e priorização de alertas ou já consegue identificar padrões anômalos, sugerir causa raiz e antecipar falhas? Quais são os limites dessa automação e onde continua necessária a intervenção humana?
Alex Camargo: A adoção da IA em observabilidade evoluiu por níveis de maturidade:
Correlação e redução de ruído (amplamente em produção). Algoritmos agrupam alertas relacionados a um mesmo incidente, deduplicam e priorizam. É o uso mais maduro e o que mais reduz fadiga de alertas.
Detecção de anomalias (madura). Modelos estatísticos e de machine learning aprendem o comportamento normal de cada métrica incluindo sazonalidade (hora do dia, dia do mês, picos de fim de mês) e sinalizam desvios sem depender de limiares fixos. É especialmente valioso em finanças, onde o “normal” das 14h de uma sexta-feira é muito diferente do das 3h de domingo, de fato um self learning de todo o ambiente.
Sugestão de causa raiz (em amadurecimento). Ao correlacionar a topologia de serviços, mudanças recentes (deploys, feature flags) e sinais anômalos simultâneos, os sistemas passaram a apontar o componente provável e a mudança suspeita. Funciona bem quando a topologia e os dados de mudança estão bem instrumentados.
Antecipação de falhas (emergente). Previsão de esgotamento de recursos (disco, conexões, memória) e de tendências que levarão a violação de SLO. É promissor, mas ainda limitado a padrões com histórico claro.
A camada mais nova: LLMs e agentes. Interfaces em linguagem natural para consultar telemetria e assistentes que resumem incidentes e propõem hipóteses de investigação estão ganhando espaço, funcionando como copiloto do time de plantão.
Os limites e onde a intervenção humana permanece indispensável:
• IA aponta correlação, não intenção ou contexto de negócio não sabe que “hoje é dia de fechamento” ou que houve uma campanha de marketing.
• Falsos positivos e negativos exigem julgamento; automação de remediação sem supervisão é arriscada em sistemas financeiros.
• Causa raiz sugerida é hipótese, não veredito: a validação e a decisão de mitigar (especialmente algo com impacto regulatório ou financeiro) continuam humanas.
• Modelos degradam com mudanças de arquitetura e precisam de curadoria contínua.
A regra prática: IA para acelerar detecção, correlação e triagem; humano para decisão, contexto e ação de risco.
Crypto ID: Como transformar métricas como latência, erro, disponibilidade e tempo de resposta em indicadores financeiros? É possível calcular, por exemplo, quanto determinado aumento de latência representa em abandono de transações, perda de conversão ou receita?
Alex Camargo: O salto de maturidade está em traduzir latência, taxa de erro, disponibilidade e tempo de resposta em linguagem financeira. Três caminhos:
Métricas de negócio como sinais de primeira classe. Ao lado da telemetria técnica, instrumente diretamente o funil: transações iniciadas, autorizadas, negadas, concluídas e o valor monetário de cada estágio. Isso permite ver receita processada por minuto tão claramente quanto latência por minuto.
Correlação estatística entre técnico e negócio. Cruzando séries históricas, é possível estimar a elasticidade entre latência e abandono. É bem documentado na indústria que cada incremento de latência reduz conversão a Amazon popularizou a referência de que 100 ms extras custavam ~1% em vendas, e o Google observou queda de tráfego com poucas centenas de ms adicionais. Cada operação deve medir a sua própria curva, porque a sensibilidade varia por canal e tipo de transação (um checkout tolera menos latência que uma consulta de saldo).
Cálculo de impacto. Com a curva de elasticidade e o valor médio da transação, converte-se degradação técnica em número: por exemplo, “+300 ms de latência no checkout → +X% de abandono → R$ Y de receita não capturada por hora”. O mesmo vale para disponibilidade: “30 min de indisponibilidade parcial em horário de pico ≈ N transações perdidas ≈ R$ Z”. Esses números transformam a conversa de “o serviço está lento” em “estamos perdendo R$ por minuto”, que é a linguagem que prioriza investimento.
O resultado é um dashboard executivo onde cada painel técnico tem um painel executivo financeiro correspondente e onde um alerta pode ser expresso em reais em risco, não só em milissegundos.
Crypto ID: Também acho importante vocês abordar SLOs, SLIs e error budgets, principalmente em operações financeiras. Como definir o nível aceitável de desempenho de um serviço e em que momento uma degradação que tecnicamente parece pequena passa a representar risco relevante para o negócio?
Alex Camargo: Os três conceitos formam uma hierarquia:
• SLI (Service Level Indicator): a métrica que você mede ex.: % de transações Pix concluídas em menos de 500 ms; % de requisições sem erro.
• SLO (Service Level Objective): a meta interna sobre o SLI ex.: 99,9% das transações abaixo de 500 ms em janela de 30 dias.
• Error budget: o complemento do SLO (100% − SLO). Com 99,9%, o orçamento de erro é 0,1% a quantidade de falha “permitida” antes de a meta ser violada.
O error budget é a ferramenta de governança: enquanto há orçamento, o time pode priorizar entrega de features; quando o orçamento se esgota, o foco muda obrigatoriamente para confiabilidade. Isso substitui discussões subjetivas (“está bom o suficiente?”) por uma regra objetiva.
Como definir o nível aceitável. Parte-se do impacto no negócio e no cliente, não da capacidade técnica. Pergunte: a partir de que ponto a degradação gera abandono, reclamação, risco regulatório ou perda de receita relevante?
SLOs internos devem ser mais rígidos que os SLAs contratuais com clientes, criando margem de segurança. E é essencial ter SLOs por jornada crítica (autorização de pagamento, liquidação Pix) em vez de uma média geral que esconde a falha onde ela dói.
Quando uma degradação “pequena” vira risco relevante. Três gatilhos típicos em finanças:
• Consumo acelerado do error budget: uma queda pequena, mas sustentada pode queimar o orçamento do mês inteiro em horas (burn rate). Alertas de burn rate multi-janela detectam isso cedo.
• Concentração em jornada de alto valor ou horário de pico: 0,2% de erro distribuído é uma coisa; 0,2% concentrado na autorização de cartão às 12h de uma sexta é receita e reputação.
• Proximidade de limites regulatórios ou contratuais: em operações como o Pix, há requisitos de disponibilidade do próprio arranjo; degradações que ameaçam esses limites são risco regulatório, não apenas técnico.
A mensagem para o executivo: o error budget é o mecanismo que alinha velocidade de entrega e confiabilidade a uma decisão baseada em dados, não em opinião.
Crypto ID: Outra frente interessante seria explicar a relação entre observabilidade e segurança. Alex, até onde os mesmos dados de telemetria podem contribuir para identificar comportamento anômalo, fraude, abuso de APIs ou incidentes de segurança, e onde termina observabilidade e começa a atuação de ferramentas como SIEM, EDR ou XDR?
Alex Camargo: Os dados de telemetria e os dados de segurança têm origem comum logs, métricas de rede, eventos de acesso, comportamento de API o que cria uma zona de sobreposição real e útil.
Onde a observabilidade contribui para segurança:
• Comportamento anômalo de API: os mesmos dados que medem latência revelam picos de requisições, padrões de acesso incomuns, enumeração de endpoints e abuso de credenciais.
• Detecção de fraude: traces e métricas de transação expõem padrões atípicos (velocidade de tentativas, geografia inconsistente, sequências improváveis) que alimentam ou complementam o antifraude.
• Sinais precoces de incidente: uma mudança súbita de tráfego de saída, novos destinos de rede ou erros de autenticação em massa aparecem primeiro na telemetria operacional.
Onde termina a observabilidade e começam SIEM/EDR/XDR:
A distinção é de propósito, retenção e capacidade de resposta:
• Observabilidade é otimizada para diagnosticar performance e disponibilidade, com retenção relativamente curta e foco em “por que está lento/quebrado”.
• SIEM (Security Information and Event Management) agrega e correlaciona logs sob a ótica de segurança, com regras de detecção, retenção longa (exigência de compliance/forense) e trilha de auditoria.
• EDR/XDR (Endpoint/Extended Detection and Response) atuam na detecção e resposta — isolar um endpoint, bloquear um processo, conter uma ameaça — com telemetria profunda de endpoint e capacidade de ação que a observabilidade não tem.
A fronteira prática: observabilidade detecta que algo está anômalo; ferramentas de segurança classificam a ameaça, preservam evidência forense e executam a resposta. A tendência de mercado é de convergência (os mesmos pipelines OTel podem alimentar tanto plataformas de observabilidade quanto SIEM), mas a governança precisa separar claramente os domínios — inclusive por razões de compliance, cadeia de custódia e segregação de acessos.
Observabilidade: da infraestrutura ao impacto no negócio
Ao longo da entrevista, Alex Camargo deixa clara uma mudança importante na forma de tratar observabilidade em ambientes críticos. O objetivo não é simplesmente acumular logs ou criar mais dashboards, mas construir uma capacidade de correlacionar o que acontece entre aplicações, infraestrutura, redes, parceiros externos e a própria jornada de negócio.
Em operações financeiras, essa correlação ganha uma dimensão adicional: determinar não apenas onde ocorreu a degradação, mas qual transação foi afetada, qual componente consumiu o tempo, quanto daquela falha pode representar em receita e em que momento um problema aparentemente pequeno ultrapassa o limite aceitável de risco.
Ao mesmo tempo, a entrada de IA nesse ambiente amplia a capacidade de detectar anomalias, correlacionar eventos e sugerir causas prováveis, sem eliminar a necessidade de decisão humana quando a ação envolve impacto financeiro, regulatório ou operacional.
O Crypto ID agradece a Alex Camargo pela disponibilidade e, principalmente, pelo aprofundamento técnico das respostas, contribuindo para que a discussão sobre observabilidade avance do conceito para as decisões de arquitetura, operação e governança que determinam sua efetividade em ambientes reais.
Ploomes incrementa processo de segurança com curadoria da Delfia
ID Talk são entrevistas que geram insights poderosos e soluções práticas para você tomar decisões estratégicas e liderar o futuro. Assistindo ou lendo você descobre o que há de mais inovador em tecnologia. Você vai gostar muito!
