Simple Log Service:Enable controlled execution of OpenClaw with SLS

Pilares de observabilidade para AI agents

A observabilidade se baseia em três pilares: dados de log, métrica e trace. Para o OpenClaw, cada pilar mapeia fontes de dados específicas e perguntas centrais:

Os três pilares são essenciais. Métricas sozinhas não respondem "quem" nem "por quê". Logs de sessão sozinhos carecem de uma visão global da saúde do sistema. Logs de execução sozinhos perdem o comportamento de negócio. Apenas juntos eles sustentam a auditoria de segurança, o gerenciamento de custos e a resolução de problemas operacionais.

Capacidades do SLS

O SLS oferece as seguintes vantagens para cenários do OpenClaw:

• Alinhamento nativo com a stack tecnológica do OpenClaw

  O LoongCollector suporta nativamente os protocolos de log e OTLP e se destaca na coleta de logs de sessão com texto longo. Integra-se perfeitamente ao plugin diagnostics-otel do OpenClaw sem necessidade de modificações, enviando métricas e traces diretamente ao SLS via OTLP.

• Operadores avançados de consulta, análise e processamento

  Os logs de sessão utilizam JSON aninhado (por exemplo, message.content, message.usage.cost, message.toolName). O motor SQL + SPL do SLS indexa e analisa campos aninhados em tempo real, sem necessidade de ETL adicional.

• Capacidades de segurança e conformidade

  Controle de acesso RAM, mascaramento de dados sensíveis e armazenamento criptografado atendem aos requisitos de trilha de auditoria e conformidade. O SLS possui certificação dedicada de produto de segurança de rede, sendo adequado para cenários que exigem conformidade com o Multi-Level Protection Scheme (MLPS). Os canais de alerta suportam DingTalk, SMS e e-mail para notificação oportuna de incidentes.

• Totalmente gerenciado, pagamento conforme o uso e dimensionamento automático

  A análise de log é um pipeline completo: "Coleta → Armazenamento → Indexação → Consulta → Painel → Alertas", totalmente gerenciado pelo LogStore e MetricStore. O modelo de pagamento conforme o uso mantém custos baixos em pequena escala, enquanto o dimensionamento automático absorve o crescimento de tráfego sem planejamento manual de capacidade ou clusters autogerenciados de Elasticsearch ou Prometheus.

O SLS é uma base ideal de observabilidade e auditoria para execução controlada do OpenClaw.

O SLS agora oferece uma solução de integração completa para o OpenClaw:

• Use o assistente de Data Import para configurar a coleta. A configuração gera automaticamente e fornece um ponto de entrada e Project unificados para logs de sessão, logs de aplicação e telemetria OTLP, reduzindo a complexidade de gerenciar fontes separadas.

• Uma única fonte de dados de sessão atende múltiplos cenários, incluindo auditoria de segurança, análise de custos e análise de comportamento.

• Painéis pré-configurados para auditoria, análise de custos e métricas de execução oferecem uma solução de observabilidade pronta para uso para execução controlada.

Etapa 1: Ingestão de logs (exemplo de log de sessão)

Os logs de sessão registram cada turno de conversa, chamada de ferramenta e token consumido.

Pré-requisitos

• Você criou um Project (por exemplo, openclaw-observability) e criou um LogStore.

• Certifique-se de que o LoongCollector esteja instalado na instância ECS ou no servidor on-premises onde o OpenClaw está em execução.

Processo de ingestão

1. Faça logon no Log Service console. No painel à direita, clique em Quick Data Import, selecione o cartão de integração OpenClaw-Session Log e escolha o Project e LogStore de destino.

2. Na seção Machine Group Configurations, encontre o grupo de máquinas criado durante a instalação do LoongCollector na lista Source Machine Group e adicione-o à lista Applied Machine Group.

   Se um grupo de máquinas apresentar exceção de heartbeat: Solucionar problemas de exceções de heartbeat.

3. Na página Logtail Configuration, o Log Service preenche automaticamente a configuração de coleta integrada. Se nenhuma alteração for necessária, clique em Next.

   • O Configuration Name está pré-preenchido. Modifique-o se necessário.

   • Em Other Global Configurations, o Log Topic Type está pré-configurado.

     Sobre o tipo de tópico de log: O LoongCollector pode extrair automaticamente o topic e o session_id do caminho do arquivo. Se o caminho do arquivo foi personalizado e não corresponde ao valor pré-preenchido, ajuste-o conforme necessário.

   • O File Path é preenchido automaticamente.

     Sobre o caminho do arquivo de texto: O caminho pré-preenchido pressupõe uma instalação padrão por um usuário não-root em um host Linux. Se o caminho real for diferente, modifique-o.

   • Em Processing Method, uma combinação de plugins de processamento está pré-configurada.

     Sobre o parsing de hora: Por padrão, o OpenClaw gera logs no fuso horário UTC+0. Se isso foi personalizado, modifique também o fuso horário no plugin de parsing de hora para evitar divergências de horário.

4. Na página Query and Analysis Configurations, o Log Service cria automaticamente um índice e relatórios integrados. Visualize-os posteriormente em Dashboard e nos painéis.

   • Índice integrado:

   • Painéis:

     • OpenClaw Behavior Analysis Dashboard

     • OpenClaw Security Audit Dashboard

     • OpenClaw Metrics Dashboard

     • OpenClaw Token Analysis Dashboard

Etapa 2: Auditar e observar

O SLS fornece painéis pré-configurados do OpenClaw que cobrem auditoria de segurança, análise de custos, análise de comportamento e métricas de execução.

1. Faça logon no Log Service console. Em Projects, selecione o Project de destino.

2. Em Log Storage, acesse o LogStore de destino e clique em Search & Analyze para verificar a ingestão de dados e o formato do log.

3. No painel de navegação à esquerda, clique em Dashboard para visualizar os painéis pré-configurados.

   • Security Audit Dashboard

     O Security Audit Dashboard é o painel principal para execução controlada do OpenClaw. Ele responde: "O que o agent está fazendo, existem ações de alto risco e quem está realizando operações fora dos limites?" Oferece monitoramento de comportamento em tempo real, identificação de ameaças e capacidades forenses abrangendo visão geral de comportamento, comandos de alto risco, injeção de prompt e exfiltração de dados.

     • Página de visão geral de estatísticas de auditoria de segurança:

       • Esta página fornece um snapshot de riscos com contagens multidimensionais de operações de alto risco em uma janela de tempo definida. Sete métricas — execuções de comandos de alto risco, requisições web de saída, execuções de linha de comando de saída, comunicações de saída, acessos a arquivos sensíveis e injeção de prompt — são exibidas com comparações período a período para avaliação rápida de anomalias.

       • Preste atenção especial a operações de alto risco que ocorrem após um evento de injeção de prompt. Embora operações de alto risco comuns possam ser legítimas, comportamentos de alto risco pós-injeção são um sinal forte de ameaça, indicando que instruções maliciosas direcionaram o agent a agir. O "Número de sessões com chamadas de ferramentas após injeção" é o sinal de maior confiança nesta página — três dessas sessões frequentemente justificam prioridade mais alta do que centenas de comandos de alto risco comuns.

       • A tabela de sessões de alto risco agrega contagens de risco por sessão e ordena por pontuação de risco composta, destacando as sessões que precisam de intervenção manual primeiro.

     • Análise de uso de Skills

       • Skills são o mecanismo do OpenClaw para estender capacidades, mas também um ponto de entrada primário para injeção de prompt. Usuários podem instalar inadvertidamente Skills com vulnerabilidades ou instruções maliciosas incorporadas. A distribuição de chamadas de Skills é, portanto, uma base crucial para analisar caminhos de ataque.

       • O gráfico de pizza de distribuição de uso estabelece uma baseline para chamadas de Skills. Um aumento repentino de uma Skill incomum ou o surgimento de uma nova Skill frequentemente indica que o agent está sendo guiado por um caminho não intencional e requer investigação.

       • Novas entradas na tabela de Skills são críticas. Como novas Skills não passaram por avaliação completa de segurança, seus limites de permissão e padrões de comportamento são um ponto cego para a equipe de segurança. Para identificar novas Skills assim que surgem, ordene-as por hora da primeira chamada em ordem decrescente. Isso permite revisá-las antes que sejam exploradas.

     • Monitoramento de chamadas de comandos de alto risco

       • A capacidade do OpenClaw de executar comandos do sistema o torna um possível trampolim para invasores. Um agent comprometido pode excluir arquivos, elevar privilégios ou exfiltrar dados enquanto aparenta comportamento normal de tarefa.

       • O monitoramento de comandos de alto risco estabelece uma camada de observabilidade independente fora da proteção em tempo de execução. Erros de configuração ou limites de permissão mal definidos podem permitir que comandos de alto risco passem despercebidos. A camada de observabilidade garante que, mesmo quando os controles em tempo de execução falham, operações de alto risco ainda sejam detectadas.

       • A visualização de linha do tempo identifica padrões de comportamento além de contagens de eventos. Uma explosão densa de chamadas de alto risco em um curto período — sinal de um agent comprometido executando instruções maliciosas — justifica intervenção imediata. A tabela de detalhes fornece contexto forense completo para rastrear anomalias até sessões e comandos específicos.

     • Detecção de injeção de prompt

       • A injeção de prompt é um método central de ataque que leva uma IA a realizar ações prejudiciais. Independentemente do caminho de ataque, instruções maliciosas devem entrar no prompt para afetar o Agent. Esses caminhos podem incluir entrada direta do usuário, dados retornados de chamadas de Skills ou dados externos lidos por ferramentas como web_fetch e read. O prompt é o ponto de entrada final para todos os caminhos de ataque.

       • A distribuição das fontes de injeção ajuda a determinar a natureza do risco. Injeções por entrada direta do usuário são tipicamente intencionais. Em contraste, os usuários frequentemente não percebem injeções entregues por toolResult. Para Agents assistentes pessoais como o OpenClaw, a injeção indireta é a ameaça principal. Skills instaladas ou conteúdo externo acessado podem se tornar vetores de injeção difíceis de identificar e evitar pelos usuários.

       • O valor de classificar injeções é identificar a intenção de ataque, não apenas sinalizar anomalias. Por exemplo, injeções de ROLE_HIJACK e JAILBREAK indicam que um invasor está tentando contornar os limites comportamentais do Agent. HIDDEN_INSTRUCTION representa uma técnica de implantação mais furtiva. A prioridade de resposta e os procedimentos de tratamento diferem para cada tipo. Monitorar continuamente as mudanças na distribuição dessas classificações ajuda a detectar tentativas focadas em superfícies de ataque específicas.

       • Uma tabela de detalhes registra a ferramenta acionadora, o contexto da sessão e o conteúdo original de cada evento de injeção. Essa tabela permite que equipes de segurança aprofundem rapidamente das estatísticas resumidas até incidentes específicos, fechando o ciclo do reconhecimento de padrões à análise de causa raiz e resposta.

     • Detecção de exfiltração de dados sensíveis

       • A exfiltração de dados de um AI agent tipicamente segue uma cadeia: o agent lê um arquivo sensível, o conteúdo entra no contexto do modelo e uma chamada de ferramenta subsequente o transmite externamente. Apenas a correlação entre acesso a arquivos e comportamento de saída revela a intenção completa do ataque.

       • A detecção utiliza uma abordagem de funil: a primeira camada registra o acesso a arquivos sensíveis por tipo de ativo (SSH_KEY, ENV_FILE, CREDENTIALS, CONFIG_SECRET, HISTORY). A segunda camada rastreia o comportamento de saída por canal (API_CALL, MESSAGE_SEND, WEB_ACCESS, EMAIL). A terceira camada correlaciona ambos — se acesso a arquivo sensível e uma operação de saída ocorrem em rápida sucessão na mesma sessão, sinaliza um evento de exfiltração de alta prioridade.

       • O valor está na localização causal, não em alertas de ponto único. Ler um SSH_KEY isoladamente não constitui uma ameaça, tampouco uma API_CALL. Porém, ambos na mesma sessão, separados por minutos, com parâmetros de saída contendo o conteúdo do arquivo, aumentam drasticamente a confiança na ameaça. A tabela de cadeia de comportamento exibe a diferença de tempo e os parâmetros completos de chamada para julgamento forense sem correlação manual de logs.

   • Token Analysis Dashboard

     O consumo de tokens está diretamente relacionado aos custos, e suas flutuações frequentemente sinalizam anomalias como inflação de contexto por injeção de prompt. O Token Analysis Dashboard responde: "Onde o dinheiro está sendo gasto, é razoável e existem anomalias?"

     Sobre dados de custo: O campo cost no painel vem do campo usage.cost no OpenClaw. O OpenClaw não suporta nativamente preços escalonados, e sua lógica de cálculo de cacheRead + cacheWrite pode não estar alinhada com a do provedor. Ele apenas estima o custo de uma única chamada usando uma fórmula como inputTokens × input + outputTokens × output + .... Portanto, os custos exibidos no painel são uma base para estimativa de custos, não um demonstrativo de cobrança exato. Para modelos em que cost não está configurado, a coluna de custo exibirá 0.

     Exemplo de configuração do Qwen3.5-Plus

     Tomando o modelo Qwen3.5-Plus como exemplo: os custos das chamadas à API do Model Studio podem ser encontrados na Lista de Modelos.

     A configuração de custo do modelo no .openclaw é a seguinte:

     {
       "id": "qwen3.5-plus",
       "name": "Qwen3.5 Plus",
       "cost": {
         "input": 0.4, // From the lowest tier input price
         "output": 2.4, // From the lowest tier output price
         "cacheRead": 0.2, // Estimated as half of the input cost
         "cacheWrite": 0
       },
     }

     • Visão geral e distribuição por modelo

       • O painel exibe comparações de 1 dia para tokens totais e custo com percentuais período a período. Se a variação diária exceder um limiar (por exemplo, ±30%), geralmente indica inflação de prompt, loop de chamadas ou uma sessão anômala que requer investigação.

     • Tendências de consumo por provedor/modelo (série temporal)

       • Dois gráficos de série temporal (1 semana) mostram tendências de consumo de tokens e custos por modelo. Picos de tokens são frequentemente sinais de segurança: injeção de prompt inflando contexto, loops infinitos de chamadas de ferramentas ou expansão de sessão não detectada. Codificados por cor por modelo, as mudanças aparecem como alterações na composição de cores para identificação rápida.

     • Principais consumos por sessão e por host/Pod (gráficos de barras)

       • O layout de gráfico de barras 2×2 responde "quem está gastando o dinheiro" a partir das perspectivas de sessão e host (ou Pod):

         • Maiores consumos de tokens por sessão / Maiores custos por sessão: Exibe o total de tokens e custos por sessão na última semana, em ordem decrescente. A distribuição de custos geralmente segue uma distribuição de cauda longa — poucas sessões representam a maior parte do consumo.

         • Maiores consumos de tokens por host / Maiores custos por host: Agrega tokens e custos por host ou Pod para análise de custos e localização de riscos em implantações com múltiplas instâncias. Combinado com a propriedade de ativos, isso mapeia o consumo aos responsáveis e ajuda a identificar usuários de risco ou sessões descontroladas.

     • Tabela de detalhes de tokens por modelo (detalhamento de custos)

       • A tabela de detalhes (relativa a 1 semana) lista para cada modelo: totalTokens, inputTokens, outputTokens, cacheReadTokens e cacheWriteTokens, juntamente com os respectivos totalCost, inputCost, outputCost, cacheReadCost e cacheWriteCost. Suporta ordenação e filtragem, permitindo responder diretamente "qual modelo gastou mais e qual foi a composição de entrada/saída". A proporção entre inputTokens e outputTokens reflete o padrão de interação do agent: uma proporção alta de entrada sugere prompts redundantes ou contexto excessivo, enquanto uma proporção alta de saída pode indicar que o modelo está gerando grande volume de conteúdo inválido. O percentual de cacheReadTokens mostra diretamente o benefício da estratégia de cache — quanto maior o percentual, menor o valor efetivamente cobrado, fornecendo uma base quantitativa para engenharia de prompts e ajuste de cache.

   • Behavior Analysis Dashboard

     O Behavior Analysis Dashboard registra e classifica o comportamento operacional do OpenClaw por sessão, respondendo: "O que o agent fez durante a janela de tempo atual?"

     • Estatísticas de sessão

       • Os cartões de contagem detalham as chamadas de ferramentas por tipo de comportamento — execução de comandos, processos em segundo plano, requisições web, ferramentas de comunicação e I/O de arquivos. Exceções de chamadas são listadas separadamente para avaliação de estabilidade.

       • A tabela de estatísticas de sessão registra contagens de chamadas por tipo de comportamento dentro de cada sessão, ordenada pelo horário da última atividade. Sessões com atividade incomum (por exemplo, 1.925 chamadas de ferramentas versus contagens típicas baixas) são destacadas para revisão prioritária.

     • Estatísticas de volume de chamadas de ferramentas e análise de erros

       • As chamadas de ferramentas são o único canal de interação externa do agent. A linha do tempo de chamadas de ferramentas mostra a frequência de chamadas ao longo do tempo, codificada por cores por tipo de ferramenta — picos são o primeiro ponto de entrada para resolução de problemas. O gráfico de tendência de taxa de erros compartilha o mesmo eixo temporal; a diferença de tempo entre os picos de erros e de volume frequentemente revela a verdadeira origem do problema.

       • O log completo de chamadas de ferramentas fornece o erro de protocolo, o status de execução e o conteúdo de retorno de cada chamada, permitindo aprofundar rapidamente de uma anomalia na tendência até a chamada específica que falhou para localizar a causa raiz.

     • Interações externas

       • As interações externas registram todas as ações de saída iniciadas pelo agent durante sua operação, incluindo chamadas de API, acesso web, envio de mensagens e envio de e-mails. Os dados são apresentados categorizados por sessão, nome da ferramenta e tipo de interação.

       • Para um AI agent, as interações externas são tanto necessárias para concluir tarefas quanto uma potencial fonte de risco. Um registro completo do comportamento de interação externa ajuda as equipes a entender os limites reais de capacidade e os hábitos de uso do agent. Por outro lado, fornece contexto comportamental completo quando anomalias ocorrem, suportando análise de correlação e forense entre ferramentas e sessões.

Etapa 3: Explorar dados com consultas personalizadas

Os painéis integrados são o ponto de partida para a descoberta de problemas, não o ponto final. Quando um painel sinaliza uma sessão de alto risco, um pico anômalo ou um alerta de métrica, é necessário aprofundar da visão geral estatística até o evento específico para reconstruir a cadeia de comportamento e confirmar a causa raiz.

Modelo de dados de log para análise personalizada

O SLS pré-configura um índice para análise de auditoria, permitindo consultar dados diretamente. Dois tipos de log são as fontes de dados principais:

• Logs de sessão — Registram o comportamento de negócio completo do agent e são a base principal para auditoria de segurança e análise de custos. Esses são os logs ingeridos na Etapa 1: Ingestão de logs (exemplo de log de sessão).

  Caminho do campo	Tipo	Finalidade
  __tag__:__session_id__	text	Identificador único de sessão. Campo-chave para isolar e agregar dados por sessão.
  type	text	Tipo de entrada: session (metadados de sessão), message (mensagem de conversa) ou compaction (resumo de compressão de contexto). Use para filtrar registros de conversa auditáveis.
  message.role	text	Papel da mensagem: user (entrada do usuário), assistant (resposta do modelo) ou toolResult (retorno de ferramenta). Use para identificar o sujeito da ação.
  message.content	text	Corpo da mensagem. Inclui entrada do usuário, saída do modelo e parâmetros/valores de retorno de ferramentas. Suporta detecção de injeção, correspondência de dados sensíveis e busca em texto completo.
  message.provider message.model	text	Provedor do modelo e nome do modelo. Use para análise de custos e estatísticas de comportamento por modelo.
  message.usage.totalTokens message.usage.cost.total	long / double	Uso de tokens e custo estimado. Use para detecção de consumo anômalo e classificação de custos por sessão.
  message.stopReason	text	Motivo de encerramento da resposta: stop (encerramento normal), toolUse (chamada de ferramenta acionada; a próxima entrada geralmente é um toolResult), error / aborted / timeout (encerramento anormal). Campo-chave para filtrar sessões anômalas.
  message.toolName message.isError	text / bool	Nome da chamada de ferramenta e status de execução. Use com o papel toolResult para auditoria em nível de ferramenta.
  id, parentId	text	ID da entrada e ID pai. Use para construir a árvore de conversa e reconstruir a ordem das mensagens. O id de uma entrada do tipo session é o sessionId.
  timestamp	text	Timestamp do evento. Use para filtragem por janela de tempo, ordenação e definição de escopos de alerta.

• Logs de execução — Registram o status operacional do gateway e dos diversos subsistemas. São a base de dados para resolução de problemas e análise de saúde do sistema.

  null

  Selecione o cartão OpenClaw-Runtime Log e siga as instruções da Etapa 1: Ingestão de logs (exemplo de log de sessão) para concluir a ingestão.

  Caminho do campo	Tipo	Finalidade
  _meta.logLevelName	text	Nível do log (TRACE / DEBUG / INFO / WARN / ERROR / FATAL). Use para focar em ERROR e FATAL durante a resolução de problemas.
  _meta.path	text	Caminho do arquivo de código-fonte e número da linha. Vincula precisamente a localizações no código para análise de stack trace.
  Chave numérica "0"	object (JSON)	Contexto estruturado. Geralmente contém um campo subsystem (como gateway, channels, telegram ou plugins).
  Chave numérica "1" e chaves subsequentes	text	Corpo da mensagem de log e conteúdo de stack trace. Suporta busca em texto completo e correspondência de palavras-chave.

Aprofundamento em nível de sessão

Cenário típico: O painel de auditoria sinaliza uma sessão de alto risco. A equipe de segurança precisa reconstruir sua interação completa para confirmar a ameaça.

Em uma implantação com múltiplas instâncias, todos os logs são gravados centralmente em um único LogStore do SLS. Isole pelo ID de sessão para esclarecer "quem acionou quais requisições, quais ferramentas foram chamadas e como o modelo respondeu".

1. Faça logon no Log Service console. Em Projects, selecione o Project de destino.

2. Em Log Storage, acesse o LogStore de destino e clique em Search & Analyze para explorar os dados. Use a consulta * and __tag__:__session_id__:<Session_Id> para filtrar, substituindo <Session_Id> pelo ID de sessão real.

3. Após filtrar a sessão, na seção Raw Logs, encontre o log desejado na aba Raw Data e clique no ícone para abrir a visualização contextual de log. Isso reconstrói a cadeia de comportamento completa dentro daquela sessão em sua ordem original — entrada do usuário, inferência do modelo, requisições de chamada de ferramenta e resultados de execução de ferramentas são exibidos sequencialmente de forma clara. Esse recurso é crucial para auditoria — identifica sequências de chamadas anormais (como leitura de arquivo sensível seguida de operação de saída) e fornece contexto completo para reproduzir e preservar evidências de incidentes de segurança.

Resolução de problemas em tempo de execução: busca por palavras-chave e análise de agregação

Cenário típico: Um alerta do painel de métricas de execução indica um aumento repentino na taxa de erros. É necessário localizar rapidamente o módulo com falha e a causa raiz em um volume massivo de logs de execução.

O SLS suporta uma combinação de busca em texto completo e busca estruturada por campo que, junto com a filtragem por intervalo de tempo, permite restringir progressivamente o escopo da investigação. Um caminho típico de resolução envolve duas etapas: primeiro, restringir o escopo e, em seguida, quantificar a distribuição.

Passo 1: Filtrar progressivamente para isolar o problema

1. Filtrar por nível de log: Use a consulta _meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL para filtrar todos os logs de erro e alerta, concentrando a atenção em eventos anormais.

2. Detalhar por subsistema: Adicione uma condição de campo à consulta de logs de erro, como 0.subsystem: plugins. A instrução de análise completa seria (_meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL) and 0.subsystem: plugins. Isso restringe o escopo a um subsistema específico. Essas duas etapas de filtragem permitem localizar rapidamente os logs de erro relevantes.

Passo 2: Usar agregação SQL para quantificar a distribuição global

Enquanto a filtragem por palavras-chave localiza eventos individuais, a análise de agregação SQL eleva essa visão para uma perspectiva estatística global. Por exemplo, agrupar pelo campo subsystem com a instrução de análise _meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL | select "0.subsystem" as subsystem, count(1) as c group by subsystem apresenta visualmente a distribuição de erros em todos os subsistemas. Isso ajuda a identificar rapidamente anomalias concentradas e direciona a investigação subsequente.