Simple Log Service:Enable controlled execution of OpenClaw with SLS

Pilares de observability para agentes de IA

La observability se basa en tres pilares: datos de registros, métricas y trazas. Para OpenClaw, cada pilar se asigna a fuentes de datos específicas y preguntas clave:

Los tres pilares son esenciales. Las métricas por sí solas no responden al "quién" ni al "por qué". Los registros de sesión carecen de una vista global de la salud del sistema. Los registros de ejecución omiten el comportamiento empresarial. Solo en conjunto permiten realizar auditorías de seguridad, gestión de costos y resolución de problemas operativos.

Capacidades de SLS

SLS ofrece las siguientes ventajas para escenarios de OpenClaw:

• Alineación nativa con el stack tecnológico de OpenClaw

  LoongCollector admite de forma nativa los protocolos de registros y OTLP, y destaca en la recolección de registros de sesión de texto largo. Se integra perfectamente con el plugin diagnostics-otel de OpenClaw sin requerir modificaciones, y envía métricas y trazas directamente a SLS mediante OTLP.

• Amplios operadores de consulta, análisis y procesamiento

  Los registros de sesión utilizan JSON anidado (por ejemplo, message.content, message.usage.cost, message.toolName). El motor SQL + SPL de SLS indexa y analiza campos anidados en tiempo real sin necesidad de ETL adicional.

• Capacidades de seguridad y cumplimiento

  El control de acceso RAM, el enmascaramiento de datos sensibles y el almacenamiento cifrado cumplen con los requisitos de pistas de auditoría y normativas. SLS cuenta con una certificación dedicada de productos de seguridad de red, lo que lo hace adecuado para escenarios que requieren cumplimiento del Esquema de Protección Multinivel (MLPS). Los canales de alerta admiten DingTalk, SMS y correo electrónico para notificar incidentes oportunamente.

• Totalmente gestionado, pay-as-you-go y auto scaling

  El análisis de registros es un pipeline integral: "Recolección → Almacenamiento → Indexación → Consulta → Panel → Alertas", totalmente gestionado por LogStore y MetricStore. El modelo pay-as-you-go mantiene bajos los costos a pequeña escala, mientras que el auto scaling maneja el crecimiento del tráfico sin planificación manual de capacidad ni clústeres autogestionados de Elasticsearch o Prometheus.

SLS es una base ideal de observability y auditoría para la ejecución controlada de OpenClaw.

SLS ahora ofrece una solución de integración integral para OpenClaw:

• Utilice el asistente Data Import para configurar la recolección. La configuración genera automáticamente un punto de entrada unificado y un Project para registros de sesión, registros de aplicación y telemetría OTLP, lo que reduce la complejidad de gestionar fuentes separadas.

• Una única fuente de datos de sesión atiende múltiples escenarios, incluidos auditoría de seguridad, análisis de costos y análisis de comportamiento.

• Paneles predefinidos para auditoría, análisis de costos y métricas de ejecución proporcionan una solución de observability lista para usar en la ejecución controlada.

Paso 1: Ingesta de registros (ejemplo de registro de sesión)

Los registros de sesión capturan cada turno de conversación, llamada a herramienta y token consumido.

Requisitos previos

• Cuenta con created a Project (por ejemplo, openclaw-observability) y created a LogStore.

• Asegúrese de que LoongCollector is installed en la instancia ECS o en el servidor local donde se ejecuta OpenClaw.

Proceso de ingesta

1. Inicie sesión en la consola de Log Service. En el panel derecho, haga clic en Quick Data Import, seleccione la tarjeta de integración OpenClaw-Session Log y, a continuación, seleccione el Project y el LogStore de destino.

2. En la sección Machine Group Configurations, busque el grupo de máquinas que creó al instalar LoongCollector en la lista Source Machine Group y agréguelo a la lista Applied Machine Group.

   Si un grupo de máquinas presenta una excepción de latido: Troubleshoot heartbeat exceptions .

3. En la página Logtail Configuration, Log Service completa automáticamente la configuración de recolección integrada. Si no requiere cambios, haga clic en Next.

   • El campo Configuration Name viene prellenado. Puede modificarlo si es necesario.

   • En Other Global Configurations, el campo Log Topic Type ya está configurado.

     Acerca del tipo de tema de registro: LoongCollector puede extraer automáticamente el tema y el session_id de la ruta del archivo. Si personalizó la ruta del archivo y esta no coincide con el valor prellenado, debe ajustarla en consecuencia.

   • La File Path se llena automáticamente.

     Acerca de la ruta del archivo de texto: La ruta de archivo prellenada asume una instalación predeterminada realizada por un usuario sin privilegios root en un host Linux. Si su ruta real es diferente, asegúrese de modificarla.

   • En Processing Method, hay una combinación de complementos de procesamiento preconfigurada.

     Acerca del análisis de tiempo: De forma predeterminada, OpenClaw genera registros en la zona horaria UTC+0. Si modificó esta configuración, también debe cambiar la zona horaria en el complemento de análisis de tiempo para evitar discrepancias temporales.

4. En la página Query and Analysis Configurations, Log Service crea automáticamente un índice integrado y reportes. Puede consultarlos posteriormente en Dashboard y en los paneles correspondientes.

   • Índice integrado: Los índices de campo generados automáticamente incluyen los siguientes campos:

     Ruta del campo	Tipo
     __tag__:__hostname__	text
     __tag__:__session_id__	text
     __tag__:_pod_name_	text
     id	text
     message	json

     El campo message contiene los siguientes subcampos anidados:

     Ruta del campo	Tipo
     api	text
     content	text
     details	text
     details.aggregated	text
     details.cwd	text
     details.durationMs	long
     details.exitCode	long
     details.status	text

   • Paneles:

     • Panel de análisis de comportamiento de OpenClaw

     • Panel de auditoría de seguridad de OpenClaw

     • Panel de métricas de OpenClaw

     • Panel de análisis de tokens de OpenClaw

Paso 2: Auditoría y observación

SLS ofrece paneles predefinidos para OpenClaw que abarcan auditoría de seguridad, análisis de costos, análisis de comportamiento y métricas de tiempo de ejecución.

1. Inicie sesión en la consola de Log Service. En Projects, seleccione el Project de destino.

2. En Log Storage, vaya al LogStore de destino y haga clic en Search & Analyze para verificar la ingesta de datos y el formato de los registros.

3. En el panel de navegación izquierdo, haga clic en Dashboard para ver los paneles predefinidos.

   • Panel de auditoría de seguridad

     El panel de auditoría de seguridad es el componente central para la ejecución controlada de OpenClaw. Responde a preguntas como: "¿Qué está haciendo el agente?, ¿existen acciones de alto riesgo? y ¿quién realiza operaciones fuera de los límites permitidos?". Proporciona monitoreo de comportamiento en tiempo real, identificación de amenazas y capacidades forenses que abarcan un resumen del comportamiento, comandos de alto riesgo, inyección de prompts y exfiltración de datos.

     • Página de resumen de estadísticas de auditoría de seguridad:

       • Esta página ofrece una instantánea de riesgos con conteos multidimensionales de operaciones de alto riesgo en una ventana de tiempo determinada. Muestra siete métricas (ejecuciones de comandos de alto riesgo, solicitudes web salientes, ejecuciones de línea de comandos salientes, comunicaciones salientes, acceso a archivos sensibles e inyección de prompts) junto con comparaciones respecto al periodo anterior para evaluar anomalías rápidamente.

       • Preste especial atención a las operaciones de alto riesgo que ocurren después de un evento de inyección de prompt. Aunque las operaciones de alto riesgo comunes pueden ser legítimas, un comportamiento de alto riesgo posterior a una inyección es una señal clara de amenaza que indica que instrucciones maliciosas impulsaron al agente a actuar. El indicador "Número de sesiones con llamadas a herramientas tras la inyección" es la señal de mayor confianza en esta página; tres sesiones de este tipo suelen justificar una prioridad más alta que cientos de comandos de alto riesgo ordinarios.

       • La tabla de sesiones de alto riesgo agrega los conteos de riesgo por sesión y los ordena según una puntuación de riesgo compuesta, lo que permite identificar primero las sesiones que requieren intervención manual.

     • Análisis de uso de Skills

       • Las Skills son el mecanismo de OpenClaw para ampliar sus capacidades, pero también constituyen un punto de entrada principal para la inyección de prompts. Los usuarios pueden instalar inadvertidamente Skills con vulnerabilidades o instrucciones maliciosas integradas. Por ello, la distribución de llamadas a Skills es fundamental para analizar las rutas de ataque.

       • El gráfico circular de distribución de uso establece una línea base para las llamadas a Skills. Un aumento repentino en una Skill poco común o la aparición de una nueva Skill suele indicar que el agente sigue una ruta no deseada y requiere investigación.

       • Las nuevas entradas en la tabla de Skills son críticas. Dado que las nuevas Skills no han sido evaluadas completamente en materia de seguridad, sus límites de permisos y patrones de comportamiento representan un punto ciego para el equipo de seguridad. Para detectar nuevas Skills tan pronto como aparezcan, ordénelas por hora de primera llamada en orden descendente. Esto le permite revisarlas antes de que sean explotadas.

     • Monitoreo de llamadas a comandos de alto riesgo

       • La capacidad de OpenClaw para ejecutar comandos del sistema lo convierte en un posible trampolín para atacantes. Un agente comprometido puede eliminar archivos, elevar privilegios o exfiltrar datos mientras aparenta un comportamiento normal de tareas.

       • El monitoreo de comandos de alto riesgo establece una capa de observability independiente de la protección en tiempo de ejecución. Los errores de configuración o los límites de permisos mal definidos pueden permitir que estos comandos pasen desapercibidos. La capa de observability garantiza que, incluso si fallan los controles en tiempo de ejecución, las operaciones de alto riesgo se detecten.

       • La vista de línea de tiempo identifica patrones de comportamiento más allá del simple conteo de eventos. Una ráfaga densa de llamadas de alto riesgo en un periodo breve —señal de un agente comprometido que ejecuta instrucciones maliciosas— requiere intervención inmediata. La tabla de detalles proporciona el contexto forense completo para rastrear anomalías hasta sesiones y comandos específicos.

     • Detección de inyección de prompts

       • La inyección de prompts es un método de ataque central que impulsa a una IA a realizar acciones dañinas. Independientemente de la ruta de ataque, las instrucciones maliciosas deben ingresar al prompt para afectar al agente. Estas rutas pueden incluir entradas directas del usuario, datos devueltos por llamadas a Skills o datos externos leídos por herramientas como web_fetch y read. El prompt es el punto de entrada final para todas las rutas de ataque.

       • La distribución de fuentes de inyección ayuda a determinar la naturaleza del riesgo. Las inyecciones provenientes de entradas directas del usuario suelen ser intencionales. En cambio, los usuarios a menudo desconocen las inyecciones entregadas mediante toolResult. Para agentes de asistencia personal como OpenClaw, la inyección indirecta representa la amenaza principal. Las Skills instaladas o el contenido externo accedido pueden convertirse en vectores de inyección difíciles de identificar y evitar para los usuarios.

       • Clasificar las inyecciones permite identificar la intención del ataque, no solo marcar anomalías. Por ejemplo, las inyecciones ROLE_HIJACK y JAILBREAK indican que un atacante intenta evadir los límites de comportamiento del agente. HIDDEN_INSTRUCTION representa una técnica de implantación más sigilosa. La prioridad de respuesta y los procedimientos de manejo difieren para cada tipo. Monitorear continuamente los cambios en la distribución de estas clasificaciones ayuda a detectar intentos focalizados sobre superficies de ataque específicas.

       • Una tabla de detalles registra la herramienta desencadenante, el contexto de la sesión y el contenido original de cada evento de inyección. Esta tabla permite a los equipos de seguridad pasar rápidamente de las estadísticas resumidas a incidentes específicos, cerrando el ciclo desde el reconocimiento de patrones hasta el análisis de causa raíz y la respuesta.

     • Detección de exfiltración de datos sensibles

       • La exfiltración de datos desde un agente de IA suele seguir una cadena: el agente lee un archivo sensible, el contenido ingresa al contexto del modelo y una llamada posterior a una herramienta lo transmite externamente. Solo la correlación entre el acceso a archivos y el comportamiento saliente revela la intención completa del ataque.

       • La detección utiliza un enfoque de embudo: la primera capa registra el acceso a archivos sensibles por tipo de activo (SSH_KEY, ENV_FILE, CREDENTIALS, CONFIG_SECRET, HISTORY). La segunda capa rastrea el comportamiento saliente por canal (API_CALL, MESSAGE_SEND, WEB_ACCESS, EMAIL). La tercera capa correlaciona ambos aspectos: si el acceso a un archivo sensible y una operación saliente ocurren en rápida sucesión dentro de la misma sesión, se marca un evento de exfiltración de alta prioridad.

       • El valor reside en la localización causal, no en alertas de puntos aislados. Leer un SSH_KEY por sí solo no constituye una amenaza, ni tampoco un API_CALL. Pero ambos en la misma sesión, separados por minutos, con parámetros salientes que contienen el contenido del archivo, aumentan drásticamente la confianza en la amenaza. La tabla de cadenas de comportamiento muestra la diferencia horaria y los parámetros completos de la llamada para facilitar el juicio forense sin necesidad de correlacionar registros manualmente.

   • Panel de análisis de tokens

     El consumo de tokens se relaciona directamente con los costos, y sus fluctuaciones suelen señalar anomalías como la inflación de contexto por inyección de prompts. El panel de análisis de tokens responde a: "¿En qué se gasta el dinero?, ¿es razonable? y ¿existen anomalías?".

     Acerca de los datos de costos: El campo cost del panel proviene del campo usage.cost de OpenClaw. OpenClaw no admite de forma nativa precios escalonados, y su lógica de cálculo de cacheRead + cacheWrite puede no coincidir con la del proveedor. Solo estima el costo de una sola llamada mediante una fórmula como inputTokens × input + outputTokens × output + ... . Por lo tanto, los costos mostrados en el panel son una línea base para la estimación de costos , no un estado de cuenta exacto. Para los modelos en los que cost no está configurado, la columna de costo mostrará 0.

     Ejemplo de configuración de Qwen3.5-Plus

     Tome como ejemplo el modelo Qwen3.5-Plus. Los costos de las llamadas a la API de Model Studio se encuentran en Model List.

     La configuración de costos del modelo en .openclaw es la siguiente:

     {
       "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
       },
     }

     • Resumen general y distribución por modelo

       • El panel muestra comparaciones diarias de tokens totales y costos con porcentajes respecto al periodo anterior. Si el cambio diario supera un umbral (por ejemplo, ±30%), suele indicar inflación de prompts, un bucle de llamadas o una sesión anómala que requiere investigación.

     • Tendencias de consumo por proveedor/modelo (series temporales)

       • Dos gráficos de series temporales (de 1 semana) muestran las tendencias de consumo de tokens y costos por modelo. Los picos de tokens suelen ser señales de seguridad: inyección de prompts que infla el contexto, bucles infinitos de llamadas a herramientas o expansión de sesiones no detectada. Al codificarse por colores según el modelo, los cambios aparecen como variaciones en la composición cromática para una identificación rápida.

     • Mayor consumo por sesión y por host/Pod (gráficos de barras)

       • La disposición de gráficos de barras de 2×2 responde a "¿quién gasta el dinero?" desde las perspectivas de sesión y host (o Pod):

         • Top tokens by session / Top cost by session: Muestra los tokens totales y los costos por sesión durante la última semana, ordenados de forma descendente. La distribución de costos suele seguir una distribución de cola larga: unas pocas sesiones concentran la mayor parte del consumo.

         • Top tokens by host / Top cost by host: Agrega tokens y costos por host o Pod para el análisis de costos y la localización de riesgos en despliegues de múltiples instancias. Combinado con la propiedad de los activos, esto asigna el consumo a los responsables y ayuda a identificar usuarios de riesgo o sesiones descontroladas.

     • Tabla de detalles de tokens por modelo (desglose de costos)

       • La tabla de detalles (relativa a 1 semana) enumera lo siguiente para cada modelo: totalTokens, inputTokens, outputTokens, cacheReadTokens y cacheWriteTokens, junto con sus correspondientes totalCost, inputCost, outputCost, cacheReadCost y cacheWriteCost. Admite ordenamiento y filtrado, lo que permite responder directamente "qué modelo gastó más dinero y cuál fue el desglose de entrada/salida". La proporción de inputTokens a outputTokens refleja el patrón de interacción del agente: una proporción alta de entrada sugiere prompts o contexto redundantes, mientras que una proporción alta de salida puede indicar que el modelo genera una gran cantidad de contenido no válido. El porcentaje de cacheReadTokens muestra directamente la ventaja de la estrategia de caché: cuanto mayor sea el porcentaje, menor será el monto facturado realmente, lo que proporciona una base cuantitativa para el prompt engineering y el ajuste de la caché.

   • Panel de análisis de comportamiento

     El panel de análisis de comportamiento registra y clasifica el comportamiento operativo de OpenClaw por sesión, respondiendo a: "¿Qué hizo el agente durante la ventana de tiempo actual?".

     • Estadísticas de sesión

       • Las tarjetas de conteo desglosan las llamadas a herramientas por tipo de comportamiento: ejecución de comandos, procesos en segundo plano, solicitudes web, herramientas de comunicación y E/S de archivos. Las excepciones de llamadas se listan por separado para evaluar la estabilidad.

       • La tabla de estadísticas de sesión registra los conteos de llamadas por tipo de comportamiento dentro de cada sesión, ordenados por última hora de actividad. Las sesiones inusualmente activas (por ejemplo, 1,925 llamadas a herramientas frente a los conteos bajos típicos) se resaltan para su revisión prioritaria.

     • Estadísticas de volumen de llamadas a herramientas y análisis de errores

       • Las llamadas a herramientas son el único canal de interacción externa del agente. La línea de tiempo de llamadas a herramientas muestra la frecuencia de llamadas a lo largo del tiempo, codificada por colores según el tipo de herramienta; los picos son el primer punto de entrada para la solución de problemas. El gráfico de tendencia de tasa de errores comparte el eje temporal; la diferencia de tiempo entre los picos de error y de volumen a menudo revela la verdadera fuente del problema.

       • El registro completo de llamadas a herramientas proporciona el error de protocolo, el estado de ejecución y el contenido devuelto para cada llamada, lo que le permite pasar rápidamente de una anomalía de tendencia a la llamada fallida específica para localizar la causa raíz.

     • Interacciones externas

       • Las interacciones externas registran todas las acciones salientes iniciadas por el agente durante su operación, incluidas llamadas a API, acceso web, envío de mensajes y envío de correos electrónicos. Los datos se presentan categorizados por sesión, nombre de herramienta y tipo de interacción.

       • Para un agente de IA, las interacciones externas son necesarias para completar tareas, pero también representan una fuente potencial de riesgo. Un registro completo del comportamiento de interacción externa ayuda a los equipos a comprender los límites reales de capacidad y los hábitos de uso del agente. Por otro lado, proporciona un contexto conductual completo cuando ocurren anomalías, lo que respalda el análisis de correlación y la investigación forense entre herramientas y sesiones.

Paso 3: Explorar datos con consultas personalizadas

Los paneles integrados son el punto de partida para descubrir problemas, no el final. Cuando un panel señala una sesión de alto riesgo, un pico anómalo o una alerta de métrica, necesita profundizar desde el resumen estadístico hasta el evento específico para reconstruir la cadena de comportamiento y confirmar la causa raíz.

Modelo de datos de registro para análisis personalizado

SLS crea previamente un índice para el análisis de auditoría, por lo que puede consultar datos directamente. Dos tipos de registro constituyen las fuentes de datos principales:

• Registros de sesión: Registran el comportamiento empresarial completo del agente y son la base principal para la auditoría de seguridad y el análisis de costos. Estos son los registros ingeridos en Step 1: Log ingestion (session log example).

  Ruta del campo	Tipo	Propósito
  __tag__:__session_id__	text	Identificador único de sesión. Campo clave para aislar y agregar datos por sesión.
  type	text	Tipo de entrada: session (metadatos de sesión), message (mensaje de conversación) o compaction (resumen de compresión de contexto). Úselo para filtrar registros de conversación auditables.
  message.role	text	Rol del mensaje: user (entrada del usuario), assistant (respuesta del modelo) o toolResult (retorno de herramienta). Úselo para identificar el sujeto de la acción.
  message.content	text	Cuerpo del mensaje. Incluye entradas del usuario, salidas del modelo y parámetros/valores de retorno de herramientas. Admite detección de inyecciones, coincidencia de datos sensibles y búsqueda de texto completo.
  message.provider message.model	text	Proveedor del modelo y nombre del modelo. Úselo para análisis de costos y estadísticas de comportamiento por modelo.
  message.usage.totalTokens message.usage.cost.total	long / double	Uso de tokens y costo estimado. Úselo para detectar consumos anómalos y clasificar costos a nivel de sesión.
  message.stopReason	text	Motivo de terminación de respuesta: stop (fin normal), toolUse (se activó una llamada a herramienta; la siguiente entrada suele ser toolResult), error / aborted / timeout (terminación anómala). Campo clave para filtrar sesiones anómalas.
  message.toolName message.isError	text / bool	Nombre de la llamada a herramienta y estado de ejecución. Úselo con el rol toolResult para auditoría a nivel de herramienta.
  id, parentId	text	ID de entrada e ID principal. Úselos para construir el árbol de conversación y reconstruir el orden de los mensajes. El id de una entrada de tipo session es el sessionId.
  timestamp	text	Marca de tiempo del evento. Úsela para filtrar ventanas de tiempo, ordenar y definir alcances de alertas.

• Registros de tiempo de ejecución: Registran el estado operativo de la puerta de enlace y varios subsistemas. Constituyen la base de datos para la solución de problemas y el análisis de salud del sistema.

  Nota

  Seleccione la tarjeta OpenClaw-Runtime Log y siga las instrucciones en Step 1: Log ingestion (session log example) para completar la ingesta.

  Ruta del campo	Tipo	Propósito
  _meta.logLevelName	text	Nivel de registro (TRACE / DEBUG / INFO / WARN / ERROR / FATAL). Úselo para centrarse en ERROR y FATAL durante la solución de problemas.
  _meta.path	text	Ruta del archivo de código fuente y número de línea. Vincula con precisión a ubicaciones de código para el análisis de seguimiento de pila.
  Clave numérica "0"	object (JSON)	Contexto estructurado. Generalmente contiene un campo subsystem (como gateway, channels, telegram o plugins).
  Clave numérica "1" y claves subsiguientes	text	Cuerpo del mensaje de registro y contenido del seguimiento de pila. Admite búsqueda de texto completo y coincidencia de palabras clave.

Profundización a nivel de sesión

Escenario típico: El panel de auditoría marca una sesión de alto riesgo. El equipo de seguridad necesita reconstruir su interacción completa para confirmar la amenaza.

En un despliegue de múltiples instancias, todos los registros se escriben centralmente en un LogStore de SLS. Aísle por ID de sesión para aclarar "quién activó qué solicitudes, qué herramientas se llamaron y cómo respondió el modelo".

1. Inicie sesión en la consola de Log Service. En Projects, seleccione el Project de destino.

2. En Log Storage, vaya al LogStore de destino y haga clic en Search & Analyze para explorar los datos. Utilice la consulta * and __tag__:__session_id__:<Session_Id> para filtrar, reemplazando <Session_Id> con el ID de sesión real.

3. Después de filtrar la sesión, en la sección Raw Logs, busque el registro objetivo en la pestaña Raw Data y haga clic en el icono para abrir la vista contextual del registro. Esto reconstruye la cadena de comportamiento completa dentro de esa sesión en su orden original: la entrada del usuario, la inference del modelo, las solicitudes de llamada a herramientas y los resultados de ejecución de herramientas se muestran claramente en secuencia. Esto es crucial para la auditoría, ya que identifica secuencias de llamadas anómalas (como la lectura de un archivo sensible seguida de una operación saliente) y proporciona el contexto completo para reproducir y preservar evidencia de incidentes de seguridad.

Solución de problemas de tiempo de ejecución: búsqueda por palabras clave y análisis de agregación

Escenario típico: Una alerta del panel de métricas de tiempo de ejecución indica un aumento repentino en la tasa de errores. Necesita localizar rápidamente el módulo defectuoso y la causa raíz a partir de un volumen masivo de registros de tiempo de ejecución.

SLS admite una combinación de búsqueda de texto completo y búsqueda de campos estructurados que, junto con el filtrado por rango de tiempo, le permite reducir progresivamente el alcance de la investigación. Una ruta típica de solución de problemas implica dos pasos: primero, reducir el alcance; luego, cuantificar la distribución.

Paso 1: Filtrar progresivamente para aislar el problema

1. Filtrar por nivel de registro: Utilice la consulta _meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL para filtrar todos los registros de error y advertencia, centrando la atención en eventos anómalos.

2. Profundizar por subsistema: Agregue una condición de campo a la consulta de registro de errores, como 0.subsystem: plugins. La declaración de análisis completa sería (_meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL) and 0.subsystem: plugins. Esto reduce el alcance a un subsistema específico. Estos dos pasos de filtrado pueden localizar rápidamente los registros de errores relevantes.

Paso 2: Usar agregación SQL para cuantificar la distribución global

Mientras que el filtrado por palabras clave identifica eventos individuales, el análisis de agregación SQL eleva esto a una vista estadística global. Por ejemplo, agrupar por el campo subsystem con la declaración de análisis _meta.logLevelName: ERROR or _meta.logLevelName: WARN or _meta.logLevelName: FATAL | select "0.subsystem" as subsystem, count(1) as c group by subsystem presenta visualmente la distribución de errores en todos los subsistemas. Esto le ayuda a identificar rápidamente anomalías concentradas y le orienta en la dirección correcta para una investigación más profunda.