Esquema de registro de Container Insights

Container Insights almacena los datos de registro que recopila en una tabla denominada ContainerLogV2. Este artículo describe el esquema de la tabla, así como la comparación con la tabla ContainerLog y la migración desde esta.

Importante

ContainerLogV2 será el esquema predeterminado a través de ConfigMap para la versión 2.54.0 de la CLI y versiones posteriores. ContainerLogV2 será el formato de ingesta predeterminado para los clientes que van a incorporar información de contenedor con la autenticación de identidad administrada mediante ARM, Bicep, Terraform, Policy y la incorporación del portal. ContainerLogV2 se puede habilitar explícitamente a través de la versión 2.51.0 o posterior de la CLI mediante la configuración de recopilación de datos.

La compatibilidad con la tabla ContainerLog se retirará el 30 de septiembre de 2026.

Comparación de tablas

En la tabla siguiente se destacan las principales diferencias entre el uso de los esquemas ContainerLogV2 y ContainerLog.

Diferencias de características	ContainerLog	ContainerLogV2
Esquema	Detalles en ContainerLog.	Detalles en ContainerLogV2. Las columnas adicionales son: - ContainerName - PodName - PodNamespace - LogLevel1 - KubernetesMetadata2
Incorporación	Configurable solamente a través de ConfigMap.	Configurable a través de ConfigMap y DCR. 3
Precios	Solo compatible con los registros de análisis de precio completo.	Admite el nivel de registros básicos de bajo costo, además de los registros de análisis.
Consultas	Requiere varias operaciones de combinación con tablas de inventario para las consultas estándar.	Incluye metadatos adicionales de pod y contenedor para reducir la complejidad de las consultas y las operaciones de combinación.
Multilínea	No se admite, las entradas de varias líneas se dividen en varias filas.	Compatibilidad con el registro de varias líneas para permitir entradas únicas y consolidadas para la salida de varias líneas.

¹Si LogMessage es un JSON válido y tiene una clave denominada nivel, se usará su valor. De lo contrario, se usa un enfoque de coincidencia de palabras clave basada en regex para inferir LogLevel desde el propio LogMessage. Tenga en cuenta que es posible que vea algunas clasificaciones incorrectas, ya que este valor se deduce.

²KubernetesMetadata es una columna opcional y la colección de este campo se puede habilitar con la característica Metadatos de Kubernetes. El valor de este campo es JSON y contiene campos como podLabels, podAnnotations, podUid, Image, Image, ImageTag e Image repo.

³La configuración de DCR no se admite para clústeres que usan clústeres basados en la autenticación de la entidad de servicio. Para usar esta experiencia, migrar los clústeres con la entidad de servicio a la identidad administrada.

Nota:

No se admite la exportación al centro de eventos y a la cuenta de almacenamiento si LogMessage entrante no es un JSON válido. Para obtener el mejor rendimiento, se recomienda emitir registros de contenedor en formato JSON.

Evalúa el impacto las alertas existentes

Antes de habilitar el esquema ContainerLogsV2, debe comprobar si tiene reglas de alerta que dependan de la tabla ContainerLog. Todas estas alertas deben actualizarse para usar la nueva tabla.

Para buscar las alertas que puedan hacer referencia a la tabla ContainerLog, ejecute la consulta de Azure Resource Graph siguiente:

resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

Habilitar el esquema ContainerLogV2

Puede habilitar el esquema ContainerLogV2 en el nivel de clúster a través de la regla de recopilación de datos (DCR) del clúster o ConfigMap. Si ambas opciones están habilitadas, ConfigMap tiene prioridad. Los registros Stdout y stderr solo se ingieren en la tabla ContainerLog cuando DCR y ConfigMap se establecen explícitamente en desactivados.

Filtrado de metadatos y registros de Kubernetes

El filtrado de metadatos y registros de Kubernetes mejora el esquema ContainerLogsV2 con más metadatos de Kubernetes, como PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo e ImageTag. Además, la característica Filtrado de registros proporciona funcionalidades de filtrado para contenedores de cargas de trabajo y plataforma (es decir, espacios de nombres del sistema). Con estas características, los usuarios obtienen un contexto más completo y mejoran la visibilidad de sus cargas de trabajo.

Características clave

• Esquema de ContainerLogV2 mejorado con campos de metadatos de Kubernetes: Los metadatos de registros de Kubernetes presentan otros campos de metadatos opcionales que mejoran la experiencia de solución de problemas con consultas sencillas de Log Analytics y quita la necesidad de unirse con otras tablas. Estos campos incluyen información esencial, como "PodLabels", "PodAnnotations", "PodUid", "Image", "ImageID", "ImageRepo" y "ImageTag". Al tener este contexto de fácil acceso, los usuarios pueden agilizar la solución de problemas e identificarlos rápidamente.

• Configuración de lista de inclusión personalizada: los usuarios pueden personalizar los nuevos campos de metadatos que desean ver mediante la edición del mapa de configuración. Tenga en cuenta que todos los campos de metadatos se recopilan de manera predeterminada cuando metadata_collection está habilitado y si desea seleccionar campos específicos, quite la marca de comentario include_fields y especifique los campos que deben recopilarse.

• Esquema De ContainerLogV2 mejorado con nivel de registro: los usuarios ahora pueden evaluar el estado de la aplicación en función de los niveles de gravedad codificados por colores, como CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE o UNKNOWN. Es una herramienta fundamental para la respuesta a incidentes y la supervisión proactiva. Al distinguir visualmente los niveles de gravedad, los usuarios pueden identificar rápidamente los recursos afectados. El sistema codificado en colores simplifica el proceso de investigación y permite a los usuarios explorar en profundidad aún más seleccionando el panel para una experiencia de exploración para una depuración adicional. Sin embargo, es importante tener en cuenta que esta funcionalidad solo es aplicable cuando se usa Grafana. Si usa el área de trabajo de Log Analytics, LogLevel es simplemente otra columna de la tabla ContainerLogV2.

• Filtrado de registros basado en anotaciones para cargas de trabajo: técnica eficaz de filtrado de registros mediante anotaciones de pod. Los usuarios pueden centrarse en la información relevante sin examinar el ruido. El filtrado basado en anotaciones permite a los usuarios excluir la recopilación de registros para determinados pods y contenedores anotando el pod, lo que ayudaría a reducir significativamente el costo de Log Analytics.

• Filtrado de registros basado en ConfigMap para registros de plataforma (espacios de nombres de Kubernetes del sistema): los contenedores emiten registros de plataforma en los espacios de nombres del sistema (o restringidos similares). De manera predeterminada, se excluyen todos los registros de contenedor del espacio de nombres del sistema para minimizar el costo de Log Analytics. Sin embargo, en escenarios de solución de problemas específicos, los registros del contenedor del sistema desempeñan un papel fundamental. Por ejemplo, considere el contenedor coredns dentro del espacio de nombres kube-system. Para recopilar registros (stdout y stderr) exclusivamente desde el formulario de contenedor coredns kube-system, puede habilitar la siguiente configuración en el mapa de configuración.

• Panel de Grafana para la visualización: el panel de Grafana no solo muestra visualizaciones codificadas en color de niveles de registro que van desde CRITICAL a UNKNOWN, sino que también profundiza en el volumen de registro, la tasa de registro, los registros de registro, los registros. Los usuarios pueden obtener análisis sensibles al tiempo, información dinámica sobre las tendencias de nivel de registro a lo largo del tiempo y la supervisión crucial en tiempo real. También proporcionamos un desglose detallado por equipo, pod y contenedor, que permite el análisis detallado y la solución de problemas identificada Y, por último, en la nueva experiencia de la tabla Registros, los usuarios pueden ver detalles detallados con la vista de expansión y ver los datos de cada columna y acercar la información que desean ver.

Este es un vídeo que muestra el panel de Grafana:

Habilitación del filtrado de metadatos y registros de Kubernetes

Requisitos previos

1. Migre a la autenticación de identidad administrada. Más información.

2. Asegúrese de que ContainerLogV2 está habilitado. Los clústeres de autenticación de identidad administrada tienen este esquema habilitado de manera predeterminada. Si no es así, habilite el esquema ContainerLogV2.

Limitaciones

No se admite el Panel de Grafana de ContainerLogV2 con el SKU de registros básicos en la tabla ContainerLogV2.

Habilitación de metadatos de Kubernetes

1. Descargue el mapa de configuración y modifique la configuración de false a true como se ve en la siguiente captura de pantalla. Tenga en cuenta que todos los campos de metadatos admitidos se recopilan de manera predeterminada. Si desea recopilar campos específicos, especifique los campos necesarios en include_fields.

2. Aplique ConfigMap. Consulte configuración de configmap para obtener más información sobre la implementación y configuración de ConfigMap.

3. Después de unos minutos, los datos deben fluir a la tabla ContainerLogV2 con metadatos de registros de Kubernetes, como se muestra en la captura de pantalla siguiente.

Incorporación a la experiencia del panel de Grafana

1. En la pestaña Insights, seleccione supervisar la configuración e incorporarla al panel de Grafana con la versión 10.3.4+

2. Asegúrese de que tiene uno de los roles Grafana Admin/Editor/Reader mediante la comprobación del control de acceso (IAM). De lo contrario, agréguelos.

3. Asegúrese de que la instancia de Grafana tiene acceso al área de trabajo de Azure Logs Analytics(LA). Si no tiene acceso, debe conceder acceso al rol Lector de supervisión de instancias de Grafana al área de trabajo de LA.

4. Vaya a su área de trabajo Grafana e importe el Panel ContainerLogV2 desde la galería Grafana.

5. Seleccione la información de DataSource, Subscription, ResourceGroup, Cluster, Namespace y Labels. A continuación, el panel se rellena como se muestra en la captura de pantalla siguiente.

Nota:

Al cargar inicialmente el panel de Grafana, podría producir algunos errores debido a que las variables aún no están seleccionadas. Para evitar que esto sea recurrente, guarde el panel después de seleccionar un conjunto de variables para que se convierta en el valor predeterminado en la primera apertura.

Habilitación del filtrado basado en anotaciones

Siga los pasos mencionados a continuación para habilitar el filtrado basado en anotaciones. Busque el vínculo aquí una vez publicada la documentación de filtrado relacionada.

1. Descargue el mapa de configuración y modifique la configuración de false a true, como se muestra en la captura de pantalla siguiente.

2. Aplique ConfigMap. Consulte configuración de configmap para obtener más información sobre la implementación y configuración de ConfigMap.

3. Agregue las anotaciones necesarias en la especificación del pod de carga de trabajo. En la tabla siguiente se resaltan diferentes anotaciones y descripciones de pod posibles de lo que hacen.

Annotation	Descripción
fluentbit.io/exclude: "true"	Excluye los flujos stdout y stderr en todos los contenedores del pod
fluentbit.io/exclude_stdout: "true"	Excluye solo el flujo stdout en todos los contenedores del pod
fluentbit.io/exclude_stderr: "true"	Excluye solo el flujo stderr en todos los contenedores del pod.
fluentbit.io/exclude_container1: "true"	Excluya los flujos stdout y stderr solo para el container1 en el pod
fluentbit.io/exclude_stdout_container1: "true"	Excluir solo stdout para el container1 en el pod

Nota:

Estas anotaciones están basadas en bits fluidas. Si usa su propia solución de recopilación de registros basada en fluent-bit con el filtro del complemento de Kubernetes y la exclusión basada en anotaciones, dejará de recopilar registros de Container Insights y la solución.

Este es un ejemplo de anotación fluentbit.io/exclude: "true" en la especificación pod:

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs 

Filtrado de registros basado en ConfigMap para registros de plataforma (espacios de nombres de System Kubernetes)

1. Descargue el mapa de configuración y modifique la configuración relacionada con collect_system_pod_logs y exclude_namespaces.

Por ejemplo, para recopilar registros stdout y stderr del contenedor coredns en el espacio de nombres kube-system, asegúrese de que el espacio de nombres kube-system no está en exclude_namespaces y esta característica solo está restringida a los siguientes espacios de nombres del sistema: kube-system, gatekeeper-system, calico-system, azure-arc, kube-public y kube-node-lease espacios de nombres.

2. Aplique ConfigMap. Consulte configuración de configmap para obtener más información sobre la implementación y configuración de ConfigMap.

Registro de varias líneas en Container Insights

Con el registro de varias líneas habilitado, los registros de contenedor divididos previamente se unen y se envían como entradas únicas a la tabla ContainerLogV2. Si la línea de registro unida es superior a 64 KB, se truncará debido a los límites del área de trabajo de Log Analytics. Esta característica también admite seguimientos de la pila de .NET, Go, Python y Java, que aparecen como entradas únicas en la tabla ContainerLogV2. Habilite el registro de varias líneas con ConfigMap tal como se describe en Configuración de la recopilación de datos en Container Insights mediante ConfigMap.

Nota:

El mapa de configuración ahora incluye una opción de especificación de idioma, donde los clientes pueden seleccionar solo los idiomas en los que están interesados. Esta característica se puede habilitar editando los idiomas de la opción stacktrace_languages del mapa de configuración.

En las capturas de pantalla siguientes se muestra el registro de varias líneas para el seguimiento de la pila de excepciones de Go:

Registro de varias líneas deshabilitado

Registro de varias líneas habilitado

Seguimiento de la pila de Java

Seguimiento de la pila de Python

Pasos siguientes

• Configuración de Registros básicos para ContainerLogV2.
• Obtenga información sobre cómo consultar datos de ContainerLogV2