Esta página se ha traducido con Cloud Translation API.

Recoger registros de tus flujos de trabajo

En esta página se describe el proceso para recoger registros de sus flujos de trabajo en entornos de dispositivos aislados de Google Distributed Cloud (GDC) para facilitar el registro y la observabilidad de los datos.

Los registros registran las condiciones y las acciones a medida que gestionas las operaciones de tus servicios en GDC. Puedes extraer los registros que generan tus componentes para registrar eventos y actividades. La plataforma de registro ofrece una API personalizada para recoger los registros a nivel de proyecto generados por tus flujos de trabajo a través de los destinos de registro.

Para empezar a recoger datos de registro, implementa un recurso personalizado LoggingTarget en el espacio de nombres de tu proyecto en el servidor de la API Management. Una vez que el recopilador de registros extrae datos de tus flujos de trabajo, la plataforma de registro agrega registros de todas las fuentes de registros, añade índices y asocia registros con etiquetas según la configuración del recurso personalizado LoggingTarget.

Accede a los registros recogidos mediante la interfaz de usuario de Grafana, tal como se explica en el artículo Consultar y ver registros.

Para consultar las prácticas recomendadas sobre la implementación del registro para la observabilidad de los datos, consulta las directrices de la comunidad de Kubernetes:

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Antes de empezar

Para obtener los permisos que necesitas para gestionar recursos personalizados de LoggingTarget, pide a tu administrador de gestión de identidades y accesos de la organización o del proyecto que te conceda uno de los roles de LoggingTarget asociados.

En función del nivel de acceso y de los permisos que necesites, puedes obtener los roles de creador, editor o lector de este recurso en una organización o en un proyecto. Para obtener más información, consulta Preparar permisos de gestión de identidades y accesos.

Operadores de aplicaciones: para obtener los permisos que necesitas para gestionar recursos personalizados de LoggingTarget en un proyecto en el servidor de la API de gestión, 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:
- Creador de LoggingTarget: crea recursos personalizados de LoggingTarget. Solicita el rol Creador de LoggingTarget (loggingtarget-creator).
- Editor de LoggingTarget: edita o modifica recursos personalizados de LoggingTarget. Solicita el rol Editor de LoggingTarget (loggingtarget-editor).
- Visor de LoggingTarget: muestra recursos personalizados de LoggingTarget. Solicita el rol LoggingTarget Viewer (loggingtarget-viewer).
Administradores de la plataforma: para obtener los permisos que necesitas para gestionar los recursos personalizados de LoggingTarget en el espacio de nombres platform-obs del servidor de la API de gestión, pide al administrador de gestión de identidades y accesos de tu organización que te conceda uno de los siguientes roles de clúster en el espacio de nombres platform-obs:
- Creador de LoggingTarget PA: crea LoggingTarget recursos personalizados. Solicita el rol de clúster Creador de PA de LoggingTarget (loggingtarget-pa-creator).
- Editor de PA de LoggingTarget: edita o modifica recursos personalizados de LoggingTarget. Solicita el rol de clúster Editor de PA de LoggingTarget (loggingtarget-pa-editor).
- LoggingTarget PA Viewer: muestra recursos personalizados de LoggingTarget. Solicita el rol de clúster LoggingTarget PA Viewer (loggingtarget-pa-viewer).

Recoger registros operativos

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 servidor de la API Management para configurar la canalización de registro del sistema y recoger registros operativos de servicios específicos a nivel de proyecto.

Sigue estos pasos para recoger registros operativos de un servicio:

Configura el recurso personalizado LoggingTarget en el servidor de la API Management, especificando los pods seleccionados para recoger los registros operativos, el espacio de nombres del proyecto y cualquier otro ajuste. Para saber cómo debe ser el LoggingTarget, consulta Configurar el recurso personalizado LoggingTarget.
Implementa el recurso personalizado LoggingTarget en el espacio de nombres de tu proyecto en el servidor de la API Management:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
```
Haz los cambios siguientes:
- MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API Management zonal.
- LOGGING_TARGET_NAME: el nombre del recurso personalizado LoggingTarget, como my-service-logging-target.yaml.
La canalización empieza a recoger registros de los componentes adicionales de tu proyecto.
Consulta los registros de la instancia de Grafana de tu proyecto. Para obtener más información, consulta Consultar y ver registros.

Usa la función de código de colores integrada de Grafana 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 que recoja registros de servicios específicos de tu proyecto de GDC. Puede especificar los destinos de los que quiere recoger registros, un analizador de registros, niveles de acceso y cualquier otro ajuste.

Este recurso define las siguientes configuraciones:

Destinos: los criterios para seleccionar los pods y los contenedores de los que quieras recoger registros. Puedes especificar nombres de clústeres, prefijos de nombres de pods y prefijos de nombres de contenedores.
Analizador de registros: un analizador predefinido para interpretar entradas de registro, asignar salidas de registro a etiquetas y extraer campos relevantes.
Identificación del servicio: el nombre del servicio aplicado como etiqueta a las entradas de registro para facilitar la identificación y el filtrado.
Autorización: el nivel de acceso de las entradas de registro, que controla quién puede ver los registros recogidos.

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

Si configuras estos parámetros en el recurso personalizado LoggingTarget, puedes controlar con precisión la recogida y la organización de los registros de tus servicios.

Sigue estos pasos para recoger los registros operativos de un servicio:

Determina el proyecto de GDC del que quieras recoger los registros.
En la configuración de LoggingTarget, especifica los pods para recoger los registros operativos, el espacio de nombres del proyecto y cualquier otro ajuste.

El siguiente archivo YAML muestra un ejemplo de configuración de LoggingTarget en my-project-namespace, donde el prefijo del nombre del pod del que se van a recoger los registros es my-pod-prefix, el nivel de acceso a las entradas de registro se concede a los operadores de aplicaciones (ao), el nombre del servicio es my-service-name y el formato de registro es JSON:
```
# 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: my-project-namespace
  name: my-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name
```
Consulte las especificaciones completas de LoggingTarget y la documentación de referencia de la API para obtener más campos y opciones.
Aplica la configuración de LoggingTarget al servidor de la API Management en el mismo espacio de nombres que tus pods de destino:
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
```
Haz los cambios siguientes:
- KUBECONFIG_PATH: la ruta al archivo kubeconfig del servidor de la API Management.
- LOGGING_TARGET_NAME: el nombre del archivo de definición de LoggingTarget, como my-service-logging-target.
La canalización de registro empieza a recoger registros de los componentes adicionales de tu proyecto.

Puede consultar los registros recogidos mediante la interfaz de usuario de Grafana o la API LogQuery. Para obtener más información, consulta Consultar y ver registros.

Si usas Grafana para consultar tus registros, puedes usar 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/.

Especificación completa de `LoggingTarget`

En el siguiente archivo YAML se muestra un ejemplo de la especificación completa del recurso personalizado LoggingTarget. Para obtener más información y una descripción completa de los campos, consulta la documentación de referencia de la API.

# 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: LOGGING_TARGET_NAME
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.
    # Optional
    matchClusters:
    - my-cluster
    - another-cluster

    # The pod name prefixes to collect logs from.
    # The logging 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:
      - my-pod-prefix
      - another-pod-prefix

    # The container name prefixes to collect logs from.
    # The logging 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:
      - my-container-prefix
      - another-container-prefix

  # 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: my-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.
LOGGING_TARGET_NAME: el nombre del archivo de LoggingTarget definición.