Use as Conversas Inteligentes do STAROps para diagnosticar falhas em diálogos de linguagem natural com um Digital Employee (Agente), desde a descoberta do alerta até a identificação da causa raiz. Este tópico inclui exemplos de diálogo para os pontos de entrada do CloudMonitor (CMS) e do Log Service (SLS), além de técnicas para melhorar as respostas da IA com perguntas de acompanhamento direcionadas.
Cenário de negócios
Ao receber um alerta ou detectar uma anomalia no sistema, identifique a causa raiz rapidamente. Consultar manualmente vários sistemas de monitoramento, plataformas de log e mapas de topologia é lento e pode deixar passar sinais correlacionados entre diferentes fontes de dados.
As Conversas Inteligentes do STAROps permitem descrever o problema em linguagem natural. O Digital Employee correlaciona automaticamente dados de múltiplas fontes e reduz o tempo de diagnóstico de dezenas de minutos para poucas rodadas de conversa.
Arquitetura da solução
Uma sessão de diagnóstico de falhas envolve as seguintes etapas:
Entrada do problema: Inicie uma conversa pelo Assistente Inteligente do CloudMonitor (CMS) ou do Log Service (SLS) e descreva o conteúdo do alerta ou a anomalia observada.
Correlação de dados: Com base na descrição do problema, o Digital Employee consulta automaticamente dados de várias fontes, incluindo métricas do Prometheus, logs do SLS e relacionamentos de topologia. Se houver referência @entity, a análise começa nessa entidade.
Raciocínio em múltiplos turnos: Após a análise inicial, o Digital Employee pode sugerir novas direções de investigação. Perguntas de acompanhamento direcionam a análise para dimensões específicas.
Saída da causa raiz: O Digital Employee entrega um relatório de análise de causa raiz com métricas anômalas, evidências em logs e relacionamentos de topologia, além de recomendações de correção.
Procedimento
Verifique a prontidão do ambiente
Antes de iniciar uma sessão de diagnóstico de falhas, confirme os pré-requisitos abaixo.
|
Item da lista de verificação |
Como verificar |
|
Digital Employee criado |
Na barra lateral do console do STAROps, clique em Digital Employee Management e confirme se o status do Digital Employee alvo está normal. |
|
Workspace com fontes de dados de observabilidade conectadas |
Na página de detalhes do Workspace, confirme se as fontes de dados de métricas (Prometheus) e logs (SLS) estão conectadas. |
|
Modelo de Observabilidade Unificado (UModel) configurado |
Na caixa de entrada da conversa, digite |
|
Default Rules configuradas (recomendado) |
Configurar Default Rules melhora significativamente a qualidade do diagnóstico. Para mais detalhes, consulte Criar um Agente Inteligente de O&M Personalizado. |
Cenário 1: Diagnóstico de falhas pelo ponto de entrada do CloudMonitor
O Assistente Inteligente do CloudMonitor oferece suporte a referências @entity, sendo ideal para investigações orientadas por alertas que rastreiam a propagação de falhas ao longo dos relacionamentos de topologia.
Use referências @entity
Na caixa de entrada da conversa, digite @ para abrir o seletor de entidades. O sistema exibe as entidades disponíveis no workspace atual. Os tipos de entidade incluem Cluster, Node, Service e Pod, dependendo da configuração do UModel.
Após selecionar uma entidade alvo, o Digital Employee inicia a análise a partir dela e correlaciona automaticamente sua topologia upstream e downstream, bem como as métricas associadas.
Exemplo de diálogo: Investigação de reinicialização de Pod
O diálogo em múltiplos turnos a seguir demonstra como investigar um alerta de reinicialização de Pod e refinar progressivamente a causa raiz.
Turno 1: Descreva o problema
@Service:order-service Pods têm sido reiniciados frequentemente na última 1 hora. Ajude-me a analisar a causa.
O Digital Employee executa automaticamente as seguintes ações:
Consulta a lista de Pods associados ao order-service e suas contagens de reinicialização.
Verifica os códigos de saída dos containers e os logs recentes dos Pods em reinicialização.
Analisa as tendências de uso de recursos (CPU e memória) dos Pods afetados.
Turno 2: Acompanhe para uma análise mais profunda
Se a análise inicial revelar OOMKilled, prossiga com um acompanhamento direcionado:
Mostre-me a tendência de uso de memória heap da JVM para este Pod e verifique se foram feitas requisições de consulta grandes recentemente.
O Digital Employee consulta métricas da JVM e logs de requisição para identificar vazamentos de memória ou consultas extensas que causaram o OOM.
Cenário 2: Diagnóstico de falhas pelo ponto de entrada do Log Service
O Assistente Inteligente do Log Service é otimizado para análises centradas em logs, sendo mais adequado para picos de logs de erro ou latência anormal de requisições.
Exemplo de diálogo: Investigação de pico de logs de erro
Turno 1: Descreva o problema
payment-service tem gerado um grande número de erros 500 desde as 14:00. Ajude-me a encontrar a causa.
O Digital Employee executa automaticamente as seguintes ações:
Consulta a distribuição de logs de erro do payment-service por volta das 14:00.
Categoriza os erros por tipo e extrai os stack traces de exceção mais frequentes.
Correlaciona cadeias de chamadas upstream para verificar falhas em cascata.
Turno 2: Verifique a correção
Reiniciei o pool de conexões do banco de dados. Confirme se a taxa de erro do payment-service voltou ao normal.
O Digital Employee compara as tendências da taxa de erro antes e depois da correção para confirmar se o problema foi resolvido.
Técnicas de acompanhamento: melhorando a qualidade do diagnóstico da IA
Quando a resposta inicial da IA for muito superficial ou mal direcionada, use as estratégias de acompanhamento abaixo para guiar a análise.
|
Situação |
Exemplo de acompanhamento |
Resultado esperado |
|
Análise muito superficial |
"Analise isso separadamente sob três ângulos: JVM, pool de conexões e dependências downstream." |
Orienta a IA a explorar múltiplas dimensões em vez de uma única perspectiva. |
|
Análise seguindo a direção errada |
"O problema não está na camada de rede. Concentre-se nos logs de erro da camada de aplicação." |
Corrige a direção da análise e evita perda de tempo em dimensões irrelevantes. |
|
Contexto ausente |
"Este serviço teve uma release às 14:00 hoje, atualizando a imagem de v2.3.1 para v2.4.0. Por favor, reanalise considerando essa mudança." |
Fornece contexto de negócios que a IA não consegue recuperar automaticamente, como registros de release e alterações de configuração. |
|
Necessidade de comparação temporal |
"Compare as métricas do mesmo horário de ontem com os dados de hoje." |
Detecta desvios anômalos por meio da comparação com uma linha de base. |
|
Necessidade de análise de topologia |
"Verifique se os serviços upstream e downstream do order-service também apresentam anomalias." |
Rastreia a origem de falhas em cascata ao longo dos relacionamentos de topologia. |
|
Verificação de uma correção |
"Aumentei o número de réplicas dos Pods. Confirme se a latência diminuiu." |
Valida se a medida de correção surtiu efeito. |
Formato de saída do relatório de diagnóstico
Após a conclusão do diagnóstico, solicite à IA que produza um relatório estruturado utilizando o seguinte prompt:
Resuma a análise e gere um relatório de diagnóstico estruturado que inclua causa raiz, escopo de impacto, relacionamentos em cascata e ações recomendadas.
A IA geralmente gera um relatório no seguinte formato:
Fault Diagnosis Report
Root Cause
pod-storage-02 triggered OOMKilled due to an excessively low memory limit (2 GiB).
Impact Scope
- Direct impact: Available Pods for service-storage dropped from 3 to 2.
- Indirect impact: Upstream pod-data-processor triggered a retry storm, causing CPU on node-03 to spike to 92%.
Cascade Failure Chain
pod-storage-02 OOM → service-storage latency increase → pod-data-processor retry storm → node-03 CPU spike
Recommended Actions
1. [Immediate] Increase pod-storage-02 memory limit to 4 GiB.
2. [Immediate] Confirm that pod-storage-02 has recovered.
3. [Short-term] Configure a PodDisruptionBudget (minAvailable=2) for service-storage.
4. [Long-term] Configure an exponential backoff retry strategy for pod-data-processor.
Do diagnóstico ao monitoramento contínuo
Se os problemas identificados durante o diagnóstico exigirem atenção contínua, configure o monitoramento automatizado criando uma Mission de longa duração:
Create a long-running mission to inspect service-storage memory usage and Pod health every day. Notify me immediately if OOM risk is detected.
A IA o guiará pela criação da Mission e pelo planejamento do blueprint. Para mais detalhes, consulte Criar e Planejar uma Mission de Longa Duração.