Davis AI: análise da anomalia à causa raiz sem abrir dashboard

O Davis, dentro do Dynatrace Intelligence, converte anomalia em diagnóstico percorrendo a topologia do Smartscape por análise de árvore de falhas, e devolve causa raiz, entidades atingidas, objetivos de nível de serviço rompidos e usuários afetados. Janelas de cinco e noventa minutos governam a fusão de eventos, e cinco modos de falha na ingestão explicam quase todo diagnóstico errado.

Um motor que responde por que o sistema degradou só é confiável quando se conhece onde ele erra. Davis AI erra de forma previsível: quando a topologia que ele percorre foi construída sobre dado mal instrumentado. O diagnóstico é tão bom quanto a ingestão que o alimenta.

O que é Davis AI e por que causal muda a pergunta

O Davis, dentro do Dynatrace Intelligence, é responsável pela análise causal da plataforma Dynatrace, transformando anomalias detectadas em um diagnóstico único de causa raiz. A finalidade é responder por que um sistema degradou, e não apenas que ele degradou. O mecanismo central é a análise de árvore de falhas percorrida sobre a topologia de dependências do Smartscape.

Esse mecanismo tem um requisito e uma restrição. O requisito é topologia correta, porque Davis AI só enxerga a relação de causa e efeito que a ingestão conseguiu representar. A restrição é temporal: eventos separados por mais de cinco minutos não entram no mesmo problema, e um problema aberto há mais de noventa minutos deixa de absorver eventos novos.

Davis AI não é dashboard, não é chatbot e não é modelo estatístico que adivinha padrão. A análise é determinística, o que significa que o mesmo insumo produz a mesma conclusão, e não que ela seja infalível. O componente opera dentro da observabilidade full-stack, que reúne aplicações, infraestrutura, cloud e experiência digital no mesmo contexto correlacionado.

Correlação temporal não prova causa

A documentação da plataforma Dynatrace registra que correlação no tempo, isolada, não é suficiente para determinar causa. Dois eventos simultâneos não guardam relação causal só por serem simultâneos, e a simultaneidade costuma denunciar uma causa comum a montante.

O caso concreto é banal na operação. Um banco de dados passa a responder mais devagar e cinco serviços a jusante alertam juntos. Agrupar por proximidade temporal produz cinco alertas de peso igual, em vez de um culpado e quatro consequências. A segunda leitura é a única acionável às três da manhã.

A IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais. A distância prática está entre um dashboard que acusa latência acima do normal e um motor causal que nomeia o serviço, a dependência e a mudança recente por trás dela.

Como Davis AI sai da anomalia e chega à causa raiz

O percurso tem quatro etapas.

1. As anomalias são detectadas e normalizadas em eventos de formato semântico único.
2. A topologia de dependências dá a direção causal entre as entidades.
3. A árvore de falhas percorre as dependências e ordena os candidatos.
4. Os eventos viram um problema, com causa raiz e impacto declarados.

Evento Davis: o átomo da análise

Um evento Davis representa uma anomalia singular. A documentação da plataforma Dynatrace descreve três tipos: violação de limiar, degradação de linha de base e eventos pontuais, como a queda de um processo.

Eventos informativos também são detectados e processados, entre eles nova implantação e mudança de configuração. É por isso que a causa raiz costuma chegar acompanhada da mudança recente que a explica. Para o profissional DevOps, é a diferença entre suspeitar da entrega de ontem e ver a entrega apontada dentro do problema.

Smartscape: a topologia que dá direção à causa

Smartscape é a representação visual e dinâmica de todas as dependências do ambiente, atualizada em tempo real. A leitura acontece em dois eixos. O vertical desce da aplicação ao serviço, do serviço ao processo e do processo ao host. O horizontal percorre as chamadas entre serviços, onde a cadeia de uma transação de negócio se forma.

A topologia é criada a partir do dado ingerido, incluindo métricas, eventos, logs e traces de transação, os PurePath. Para o arquiteto, isso significa que decisão de instrumentação é decisão sobre a qualidade da causa raiz, tomada meses antes do incidente que vai cobrá-la.

Árvore de falhas aplicada a milhões de dependências

A árvore de falhas parte do evento indesejado no topo e desce deduzindo as causas possíveis, ramo a ramo. A documentação da plataforma Dynatrace descreve o percurso de milhões de dependências até a causa raiz mais provável de um problema. Material técnico da fabricante atribui a essa metodologia a mesma classe usada por NASA e FAA, declaração registrada aqui como afirmação da própria Dynatrace.

O percurso não devolve uma lista plana de suspeitos. Os candidatos são ordenados pela posição na cadeia de dependência, e a entidade a montante de todas sustenta o diagnóstico. Problema, no vocabulário da plataforma, é o resultado dessa análise de causa e impacto, e não a palavra comum.

Os parâmetros que governam a análise

Confiança em análise automática se constrói conhecendo os limites dela, em vez de elogiando a tecnologia. Os valores abaixo vêm da documentação da plataforma.

A janela de cinco minutos muda a leitura de um incidente em cascata lenta. Quando a degradação avança devagar, é esperado ver dois problemas onde a intuição via um. O corte de noventa minutos tem justificativa declarada na documentação: impedir que um incidente longo, como um teste sintético falhando por semanas, agregue eventos sem relação causal.

Há um comportamento que a comunidade reporta e que não é falha do motor. Quando a condição de violação e a de desalerta são satisfeitas na mesma janela deslizante, o problema abre e fecha sem estabilidade. Métricas esparsas e aplicações de baixo tráfego são a origem mais comum, e o falso positivo está na configuração de detecção, não na análise.

Raio de impacto: a resposta que a diretoria precisa antes de o SRE terminar

Junto com a causa raiz, a análise entrega três medidas de impacto: o total de entidades afetadas, o número de Service Level Objective, ou SLO, atingidos, e o número de usuários reais que podem ter sido afetados. As três chegam no mesmo problema, no mesmo instante.

Para o Site Reliability Engineer, ou SRE, em plantão, esse conjunto define a ordem de ação. Para o CIO, o CTO e o CEO, resolve outra pergunta: quantos clientes foram atingidos, por quanto tempo e se o compromisso de nível de serviço foi rompido. Levar à diretoria a extensão do dano em linguagem de negócio não exige saber qual processo saturou.

Por que a análise causal falha, e por que quase sempre é a ingestão

Davis AI enxerga a relação causal que a ingestão conseguiu representar, e não inventa dependência que o dado não revelou. São cinco modos de falha recorrentes, e os cinco acontecem antes da análise.

Atributo fora da convenção semântica

Um serviço enviado com app.name em vez de service.name, ou com region em vez de cloud.region, não se resolve na entidade certa do Smartscape. A cadeia é curta: atributo errado gera entidade errada, entidade errada gera topologia torta, e topologia torta aponta a causa raiz para o lugar errado.

A modelagem de topologia da plataforma Dynatrace não se apoia em regras genéricas, e sim no dado ingerido. A normalização de eventos transforma todo evento em um formato semântico único, com mapeamento garantido contra o Dicionário Semântico, e é isso que permite ao Davis AI correlacionar. A regra que resolve o problema na origem é curta: atributo obrigatório definido em convenção escrita, prefixo reservado para atributo customizado e validação antes da entrada em produção.

Cardinality explosion

Cardinality explosion é a explosão do número de séries distintas de dados, causada por identificador único por requisição ou por carimbo de tempo de alta granularidade usado como atributo. O custo de ingestão dispara, a consulta degrada e o volume de séries sem significado enterra o sinal. Para o gerente de infraestrutura, custo e qualidade de análise viram o mesmo assunto.

Sampling que joga fora justo o que importa

Sampling é a pesquisa eleitoral. O sampling head-based agressivo decide o que guardar no início da transação, e por isso descarta o trace de erro e o de latência, os únicos que interessavam à análise. Em sistemas críticos, o sampling tail-based é geralmente preferido, porque decide o que guardar depois de saber como a transação terminou.

Span órfão e a cadeia causal interrompida

A propagação de contexto é o carimbo no passaporte. Quando o carimbo falha na fronteira, o span perde o pai e vira span órfão, e a cadeia causal se interrompe ali. O cenário é comum em ambiente legado, onde a travessia exige instrumentação manual nos pontos de integração, realidade de órgãos públicos e de instituições de grande porte.

Governança de atributos é pré-requisito, não faxina posterior

Mesmo serviço com dois nomes, unidades divergentes entre times e dashboards que não agrupam produzem topologia fragmentada. Renomear atributo depois de meses de coleta é retrabalho caro e cria histórico partido. A consequência aparece semanas depois, quando a equipe perde confiança na análise e volta ao processo manual.

OneAgent, OpenTelemetry e o modelo híbrido

Uma instalação de OneAgent descobre toda a stack de um host, contêiner ou ambiente cloud, incluindo linguagens, frameworks, bancos, filas, serviços e dependências, sem configuração manual por componente. É o caminho mais curto para topologia densa e, por consequência, para causa raiz precisa.

OpenTelemetry é o padrão USB-C da telemetria, e Davis AI usa dados de OpenTelemetry na análise contínua, incluindo service mesh e cargas sem servidor. O transporte é o OTLP, o envelope dos correios, sobre gRPC na porta 4317 ou sobre HTTP com protobuf na porta 4318.

O requisito decisivo está nos atributos de recurso, que precisam seguir as convenções semânticas, porque é por eles que a telemetria aberta se resolve nas entidades certas da topologia. O modelo híbrido é o padrão da Rike IS na maior parte dos projetos: OneAgent onde ele alcança, OpenTelemetry onde o agente não entra, com o critério de divisão dado pelo inventário real de cargas.

Davis AI, Davis CoPilot e Dynatrace Assist: o que mudou e o que não mudou

A inteligência da plataforma Dynatrace, chamada Dynatrace Intelligence, adota uma abordagem hipermodal, combinando capacidades de IA preditiva, causal, generativa e agêntica.

Em fevereiro de 2026, esse conjunto passou a ser apresentado sob o guarda-chuva Dynatrace Intelligence, e o aplicativo Ask Davis CoPilot foi renomeado para Dynatrace Assist. O motor causal segue o mesmo: a documentação de causa raiz continua tratando de eventos Davis, e as propriedades de controle da ingestão seguem no namespace dt.event, com o campo event.davis definido no Dicionário Semântico. Mudou o nome do guarda-chuva, não o mecanismo.

O que a análise causal muda em cada setor

São quatro leituras do mesmo mecanismo. Em instituições financeiras, o valor está no registro coerente do que aconteceu, quando e por quê, com trilha auditável completa. Em órgãos públicos, indisponibilidade em dia de prazo legal tem custo social e político antes de ser técnico, e o ambiente heterogêneo é a regra, não a exceção.

Em cooperativas, a governança pergunta se o associado da cidade pequena tem a mesma experiência do associado da capital, algo que uma média nacional nunca responde. Em empresas privadas de grande porte, o ganho é encurtar a distância entre constatar que algo piorou e nomear a mudança que piorou.

O ângulo regulatório merece precisão. A Resolução CMN nº 5.274, de 18 de dezembro de 2025, publicada no Diário Oficial da União de 22 de dezembro de 2025, alterou a Resolução CMN nº 4.893, de 26 de fevereiro de 2021. Nenhuma dessas normas exige observabilidade nem análise automática de causa raiz, e a relação é de consequência operacional, não de imposição normativa.

Do diagnóstico à ação: quando a causa raiz vira automação

Causa raiz identificada de forma automática é o que permite à operação disparar remediação pelo AutomationEngine. O encadeamento é direto: problema com causa apontada gera gatilho, e o gatilho aciona o fluxo de remediação desenhado para aquele cenário. Sem causa confiável, sobra automação disparada por sintoma.

A automação não substitui a equipe, porque executa o que foi desenhado e aprovado. Quem decide o que automatizar, com que salvaguarda e em que ordem continua sendo a engenharia. O ganho é remover repetição do plantão, e não remover gente.

The SRE Report 2025, da Catchpoint, registrou que a mediana de tempo gasto com toil, o trabalho operacional repetitivo, subiu para 30% contra 25% em 2024. A amostra declarada é de 301 respondentes, ouvidos entre julho e agosto de 2024, o que faz do dado uma tendência do ofício, e não estatística brasileira. Para o SRE, cada ponto de toil devolvido é orçamento de erro preservado e tempo médio de resolução tratado por engenharia.

Como a Rike IS estrutura análise causal em ambiente crítico

Davis AI entrega a causa raiz que a topologia permitir enxergar, e a topologia é resultado de decisões tomadas antes do incidente: como a telemetria é instrumentada, quais atributos são padronizados, o que o sampling preserva e como a detecção é ajustada quando o ambiente muda. Análise causal não é uma função que se liga, é uma capacidade que se constrói.

O projeto começa por avaliação inicial, que mapeia maturidade e dores prioritárias. Segue por implantação em ondas, com valor visível em poucas semanas, sobre arquitetura híbrida de OneAgent com OpenTelemetry. Sustenta o resultado com treinamento por perfil profissional, cobrindo governança de atributos e análise com o Dynatrace Query Language, ou DQL, e mantém governança de performance continuada, com revisões conforme o ambiente muda.

Perguntas frequentes sobre análise de causa raiz com Davis AI

Por que apareceram dois problemas onde a equipe esperava um?

Porque os inícios ficaram separados por mais de cinco minutos, que é a janela de fusão de eventos. Em cascata lenta, o comportamento é esperado e não indica erro. O corte de noventa minutos produz o mesmo efeito em incidentes longos, quando eventos novos deixam de ser absorvidos pelo problema já aberto.

Davis AI funciona com telemetria enviada por OpenTelemetry?

Funciona, e a análise contínua consome esses dados junto com os do agente. A condição é que os atributos de recurso sigam as convenções semânticas, porque é por eles que a telemetria aberta se resolve nas entidades certas da topologia. Atributo fora da convenção entra como dado que existe e não correlaciona.

O que fazer quando a causa raiz aponta para o componente errado?

Tratar como sintoma de topologia, e não como erro de análise. A verificação começa pelos atributos que identificam a entidade apontada, segue pela cobertura de instrumentação do que está a montante dela e termina na propagação de contexto nas fronteiras. Causa raiz de borda repetida em incidentes de origens diferentes é o indício mais comum de ponto cego.

A análise é determinística ou probabilística?

Determinística. O mesmo insumo produz a mesma conclusão, o que torna o resultado auditável e reproduzível. Determinismo não significa infalibilidade: a conclusão é correta em relação ao que a topologia representa, e uma topologia incompleta produz conclusão consistente e errada.

Qual a diferença entre Davis AI e Dynatrace Assist?

Davis AI é o motor causal que produz o diagnóstico. Dynatrace Assist é a camada generativa, que cria consultas, dashboards e notebooks em linguagem natural, e foi o nome adotado em fevereiro de 2026 para o aplicativo antes chamado Ask Davis CoPilot. A renomeação atingiu a interface, e não o mecanismo de análise.

Extrair diagnóstico confiável em ambiente crítico depende de topologia, atributos e cobertura de instrumentação decididos antes do incidente, e revistos sempre que o ambiente muda. A Rike IS conduz esse percurso com consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, junto a órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte, apoiada nas cinco capacidades essenciais da plataforma: Application Performance Monitoring, ou APM, monitoramento de infraestrutura e cloud, Digital Experience Monitoring, ou DEM, AIOps, e compliance e governança de performance.

Este conteúdo é técnico e informativo. Parâmetros e nomenclatura variam conforme a versão e a configuração do ambiente, e devem ser confirmados na documentação oficial.