Recoger registros operativos de tu proyecto de Asistente operativo

En esta sección se describe cómo recoger registros operativos de un servicio en un dispositivo con air gap de Google Distributed Cloud (GDC) para el registro del sistema y la observabilidad de los datos.

La plataforma Logging proporciona una API de Kubernetes personalizada para recoger los registros a nivel de proyecto que generan tus servicios a través de los destinos de registro del sistema. Debes desplegar un LoggingTarget recurso personalizado en el espacio de nombres de tu proyecto en el clúster de administrador de la organización. A partir de este recurso, la plataforma Logging empieza a recoger los datos de registro del sistema. Accede a esos registros mediante la interfaz de usuario de la herramienta de monitorización del sistema o la API de registro de GDC. Para ello, sigue los pasos que se indican en Consultar y ver registros.

Para obtener información sobre las prácticas recomendadas para implementar el registro de componentes de Kubernetes, consulta https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Antes de empezar

Para obtener los permisos que necesitas para recoger registros operativos o ver los registros operativos recogidos, pide al administrador de gestión de identidades y accesos de tu proyecto que te conceda uno de los siguientes roles en el espacio de nombres de tu proyecto:

  • Logging Target Creator: crea LoggingTarget recursos personalizados. Solicita el rol Creador de destino de Logging (loggingtarget-creator).
  • Editor de destino de registro: edita o modifica LoggingTarget recursos personalizados. Solicite el rol Editor de destino de registro (loggingtarget-editor).
  • Visor de destino de registro: ve recursos personalizados LoggingTarget. Solicita el rol Visor de destino de Logging (loggingtarget-viewer).

Configurar la recogida de registros operativos de un servicio

Los registros operativos registran las condiciones, los cambios y las acciones a medida que gestionas las operaciones en curso en las aplicaciones y los servicios de GDC. Implementa el recurso personalizado LoggingTarget en el clúster de administrador de la organización para configurar la canalización de registro del sistema y recopilar registros operativos de servicios específicos a nivel de proyecto.

Sigue estos pasos para recoger registros operativos de un servicio:

  1. Configura el LoggingTarget CR, especificando los pods seleccionados para recoger tus registros operativos, el espacio de nombres del proyecto y cualquier otro ajuste. Para obtener más información, consulta Configurar el recurso personalizado LoggingTarget.
  2. Despliega el LoggingTarget CR en el espacio de nombres de tu proyecto en el clúster de administrador de la organización. La canalización empieza a recoger registros de los componentes adicionales de tu proyecto.
  3. Consulta los registros desde la instancia de monitorización del sistema de tu proyecto. Para obtener más información, consulta Consultar y ver registros.

Usa la función de código de colores integrada para los diferentes niveles de registro del servicio. Para obtener más información sobre cómo definir valores de nivel de registro, consulta https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Configura el LoggingTarget recurso personalizado

El recurso personalizado LoggingTarget indica a la canalización de registro del sistema que recoja registros de servicios específicos de tu proyecto y proporcione observabilidad de los datos. Debes implementar este recurso en el espacio de nombres desde el que quieras recoger los registros.

En el siguiente archivo YAML se muestra un ejemplo de configuración de LoggingTarget:

# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods
  namespace: PROJECT_NAMESPACE
  name: my-service-logging-target
spec:
  # Choose a matching pattern that identifies the pods for this job
  # Optional
  # Relationship between different selectors: 'AND'
  selector:
    # The clusters to collect logs from.
    # The default configuration is to collect logs from all clusters.
    # The relationship between different clusters is an 'OR' relationship.
    # For example, the value '["admin", "system"]' indicates to consider
    # the admin cluster 'OR' the system cluster.
    # Optional
    matchClusters:
    - CLUSTER_NAME
    - CLUSTER_NAME

    # The pod name prefixes to collect logs from.
    # The Observability platform scrapes all pods with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional
    matchPodNames:
      - POD_NAME
      - POD_NAME

    # The container name prefixes to collect logs from.
    # The Observability platform scrapes all containers with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional
    matchContainerNames:
      - CONTAINER_NAME
      - CONTAINER_NAME

  # Choose the predefined parser for log entries.
  # Use parsers to map the log output to labels and extract fields.
  # Specify the log format.
  # Optional
  # Options: klog_text, klog_json, klogr, gdch_json, json
  parser: klog_text

  # Specify an access level for log entries.
  # The default value is 'ao'.
  # Optional
  # Options: ao, pa, io
  logAccessLevel: ao

  # Specify a service name to be applied as a label
  # For user workloads consider this field as a workload name
  # Required
  serviceName: SERVICE_NAME

  # The additional static fields to apply to log entries.
  # The field is a key-value pair, where the field name is the key and
  # the field value is the value.
  # Optional
  additionalFields:
    app: workload2
    key: value

Haz los cambios siguientes:

  • PROJECT_NAMESPACE: el espacio de nombres de tu proyecto
  • CLUSTER_NAME: el nombre del clúster
  • POD_NAME: el prefijo del nombre del pod
  • CONTAINER_NAME: el prefijo del nombre del contenedor
  • SERVICE_NAME: el nombre del servicio

Los campos parser, logAccessLevel y additionalFields contienen valores de ejemplo que puedes modificar.

De forma predeterminada, todas las entradas de registro operativas se guardan en el ID de arrendatario del espacio de nombres del proyecto. Para anular este comportamiento, proporcione un valor de logAccessLevel en el recurso personalizado LoggingTarget.