Recopila registros operativos de tu proyecto de AO

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

La plataforma de Logging proporciona una API de Kubernetes personalizada para recopilar los registros a nivel del proyecto que generan tus servicios a través de destinos de registro del sistema. Debes implementar un recurso personalizado LoggingTarget en el espacio de nombres de tu proyecto en el clúster de administrador de la organización. Según este recurso, la plataforma de Logging comienza a recopilar los datos de registro del sistema. Accede a esos registros con la interfaz de usuario (IU) de la herramienta de supervisión del sistema o la API de GDC Logging, siguiendo los pasos de Cómo consultar y ver registros.

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

Antes de comenzar

Para obtener los permisos que necesitas para recopilar registros operativos o ver los registros operativos recopilados, pídele al administrador de IAM del proyecto que te otorgue uno de los siguientes roles en el espacio de nombres de tu proyecto:

  • Logging Target Creator: Crea recursos personalizados de LoggingTarget. Solicita el rol de creador de destino de Logging (loggingtarget-creator).
  • Editor de destino de Logging: Edita o modifica recursos personalizados de LoggingTarget. Solicita el rol de editor de destino de Logging (loggingtarget-editor).
  • Logging Target Viewer: Visualiza recursos personalizados de LoggingTarget. Solicita el rol de Logging Target Viewer (loggingtarget-viewer).

Configura la recopilación de registros operativos de un servicio

Los registros operativos registran las condiciones, los cambios y las acciones a medida que administras 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 registros del sistema y recopilar registros operativos de servicios específicos a nivel del proyecto.

Completa los siguientes pasos para recopilar registros operativos de un servicio:

  1. Configura el CR de LoggingTarget y especifica los Pods seleccionados para recopilar tus registros operativos, el espacio de nombres del proyecto y cualquier otro parámetro de configuración adicional. Para obtener más información, consulta Cómo configurar el recurso personalizado LoggingTarget.
  2. Implementa el CR LoggingTarget en el espacio de nombres de tu proyecto en el clúster de administrador de la organización. La canalización comienza a recopilar registros de los componentes adicionales de tu proyecto.
  3. Consulta tus registros desde la instancia de Grafanainstancia de supervisión del sistema de tu proyecto. Para obtener más información, consulta Cómo consultar y ver registros.

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

Configura el recurso personalizado LoggingTarget

El recurso personalizado LoggingTarget indica a la canalización de registro del sistema que recopile 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 deseas recopilar 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

Reemplaza lo siguiente:

  • PROJECT_NAMESPACE: Es el espacio de nombres de tu proyecto.
  • CLUSTER_NAME: es el nombre del clúster
  • POD_NAME: Es el prefijo del nombre del Pod.
  • CONTAINER_NAME: Es 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 operativo se guardan para el ID de inquilino del espacio de nombres del proyecto. Para anular este comportamiento, proporciona un valor de logAccessLevel en el recurso personalizado LoggingTarget.