Configurar el registro y la supervisión

Google Distributed Cloud (solo software) para equipos físicos admite varias opciones de registro y supervisión de clústeres, incluidos los servicios administrados basados en la nube, las herramientas de código abierto y la compatibilidad validada con soluciones comerciales de terceros. En esta página, se explican estas opciones y se proporciona orientación básica para seleccionar la solución adecuada para tu entorno.

Esta página está destinada a administradores, arquitectos y operadores que desean supervisar el estado de las aplicaciones o los servicios implementados, por ejemplo, para verificar el cumplimiento del objetivo de nivel de servicio (SLO). Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que se hace referencia en el contenido de Google Cloud , consulta Roles de usuario y tareas comunes de GKE.

Opciones para Google Distributed Cloud

Tienes varias opciones de registro y supervisión para tu clúster de Anthos:

  • Cloud Logging y Cloud Monitoring, habilitados de forma predeterminada en los componentes del sistema de bare metal.
  • Prometheus y Grafana están disponibles en Cloud Marketplace.
  • Opciones de configuración validadas con soluciones de terceros

Cloud Logging y Cloud Monitoring

Google Cloud Observability es la solución de observabilidad integrada paraGoogle Cloud. Ofrece una solución de registro completamente administrada, recopilación de métricas, supervisión, paneles y alertas. Cloud Monitoring supervisa los clústeres de Google Distributed Cloud de manera similar a como supervisa los clústeres de GKE basados en la nube.

Cloud Logging y Cloud Monitoring están habilitados de forma predeterminada cuando creas clústeres con las cuentas de servicio y los roles de IAM requeridos. No puedes inhabilitar Cloud Logging ni Cloud Monitoring. Para obtener más información sobre las cuentas de servicio y los roles necesarios, consulta Configura cuentas de servicio.

Los agentes se pueden configurar para cambiar lo siguiente:

  • El alcance del registro y la supervisión, desde solo componentes del sistema (predeterminado) hasta componentes y aplicaciones del sistema.
  • Nivel de métricas recopiladas, desde solo un conjunto optimizado de métricas (el valor predeterminado) hasta todas las métricas.

Consulta Configura agentes de Stackdriver para Google Distributed Cloud en este documento para obtener más información.

Logging y Monitoring proporcionan una solución de observabilidad única, potente, fácil de configurar y basada en la nube. Recomendamos usar Logging y Monitoring cuando se ejecutan cargas de trabajo en Google Distributed Cloud. En el caso de las aplicaciones con componentes en ejecución en Google Distributed Cloud y en la infraestructura local estándar, puedes considerar otras soluciones para obtener una vista de extremo a extremo de esas aplicaciones.

Prometheus y Grafana

Prometheus y Grafana son dos productos populares de supervisión de código abierto disponibles en Cloud Marketplace:

  • Prometheus recopila métricas de aplicaciones y sistemas.

  • Alertmanager maneja el envío de alertas con varios mecanismos de alerta diferentes.

  • Grafana es una herramienta de paneles.

Te recomendamos que uses Google Cloud Managed Service para Prometheus, que se basa en Cloud Monitoring, para todas tus necesidades de supervisión. Con el servicio administrado de Google Cloud Managed Service para Prometheus, puedes supervisar los componentes del sistema sin cargo. Google Cloud Managed Service para Prometheus también es compatible con Grafana. Sin embargo, si prefieres un sistema de supervisión local puro, puedes instalar Prometheus y Grafana en tus clústeres.

Si instalaste Prometheus de forma local y deseas recopilar métricas de los componentes del sistema, debes otorgar permiso a tu instancia local de Prometheus para acceder a los extremos de métricas de los componentes del sistema:

  • Vincula la cuenta de servicio de tu instancia de Prometheus al ClusterRole gke-metrics-agent predefinido y usa el token de la cuenta de servicio como credencial para recopilar métricas de los siguientes componentes del sistema:

    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • node-exporter

  • Usa la clave y el certificado del cliente almacenados en el secreto kube-system/stackdriver-prometheus-etcd-scrape para autenticar la extracción de métricas de etcd.

  • Crea una NetworkPolicy para permitir el acceso desde tu espacio de nombres a kube-state-metrics.

Soluciones de terceros

Google trabajó con varios proveedores de soluciones de registro y supervisión de terceros para ayudar a que sus productos funcionen bien con Google Distributed Cloud. Entre estos, se incluyen Datadog, Elastic y Splunk. En el futuro, se agregarán más proveedores validados.

Las siguientes guías de soluciones están disponibles para usar soluciones de terceros con Google Distributed Cloud:

Cómo funcionan Logging y Monitoring para Google Distributed Cloud

Cloud Logging y Cloud Monitoring se instalan y se activan en cada clúster cuando creas un nuevo clúster de administrador o de usuario.

Los agentes de Stackdriver incluyen varios componentes en cada clúster:

  • Operador de Stackdriver (stackdriver-operator-*): Administra el ciclo de vida de todos los demás agentes de Stackdriver implementados en el clúster.

  • Recurso personalizado de Stackdriver. Es un recurso que se crea automáticamente como parte del proceso de instalación de Google Distributed Cloud.

  • Agente de métricas de GKE (gke-metrics-agent-*). Un DaemonSet basado en OpenTelemetry Collector que realiza scraping de métricas de cada nodo en Cloud Monitoring. También se incluyen un DaemonSet node-exporter y una implementación kube-state-metrics para proporcionar más métricas sobre el clúster.

  • Servidor de reenvío de registros de Stackdriver (stackdriver-log-forwarder-*). Un DaemonSet de Fluent Bit que reenvía los registros de cada máquina a Cloud Logging. El servidor de reenvío almacena en búfer las entradas de registro en el nodo de forma local y vuelve a enviarlas durante un máximo de 4 horas. Si el búfer se llena o si el servidor de reenvío no puede llegar a la API de Cloud Logging durante más de 4 horas, se descartan los registros.

  • Agente de metadatos (stackdriver-metadata-agent-): Es una implementación que envía metadatos de los recursos de Kubernetes, como Pods, implementaciones o nodos, a la API de Config Monitoring para API de operaciones. Esta adición de metadatos te permite consultar tus datos de métricas por nombre de implementación, nombre de nodo o incluso nombre de servicio de Kubernetes.

Puedes ver los agentes que instaló Stackdriver mediante la ejecución del siguiente comando:

kubectl -n kube-system get pods -l "managed-by=stackdriver"

El resultado de este comando es similar al siguiente:

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Métricas de Cloud Monitoring

Para obtener una lista de las métricas recopiladas por Cloud Monitoring, consulta Visualiza las métricas de Google Distributed Cloud.

Configura agentes de Stackdriver para Google Distributed Cloud

Los agentes de Stackdriver instalados con Google Distributed Cloud recopilan datos sobre los componentes del sistema para mantener y solucionar problemas con los clústeres. En las siguientes secciones, se describen la configuración de Stackdriver y los modos operativos.

Solo componentes del sistema (modo predeterminado)

Luego de la instalación, los agentes de Stackdriver se configuran de forma predeterminada para recopilar registros y métricas, incluidos los detalles de rendimiento (por ejemplo, el uso de CPU y memoria) y metadatos similares, que corresponden a componentes del sistema que proporciona Google. Entre estos, se incluyen todas las cargas de trabajo del clúster de administrador y, en el caso de los clústeres de usuario, las cargas de trabajo de los espacios de nombres de kube-system, gke-system, gke-connect, istio-system y config-management-system.

Componentes y aplicaciones del sistema

Para habilitar el registro y la supervisión de la aplicación sobre el modo predeterminado, sigue los pasos que se indican en Habilita el registro y la supervisión de la aplicación.

Métricas optimizadas (métricas predeterminadas)

De forma predeterminada, las implementaciones kube-state-metrics que se ejecutan en el clúster recopilan y, luego, informan un conjunto optimizado de métricas de kube a Google Cloud Observability (antes conocido como Stackdriver).

Se necesitan menos recursos para recopilar este conjunto optimizado de métricas, lo que mejora el rendimiento general y la escalabilidad.

Para inhabilitar las métricas optimizadas (no recomendado), anula la configuración predeterminada en tu recurso personalizado de Stackdriver.

Usa Google Cloud Managed Service para Prometheus en componentes del sistema seleccionados

Google Cloud Managed Service para Prometheus forma parte de Cloud Monitoring y está disponible como opción para los componentes del sistema. Los beneficios de Google Cloud Managed Service para Prometheus incluyen los siguientes:

  • Puedes seguir usando tu supervisión existente basada en Prometheus sin alterar tus alertas ni los paneles de Grafana.

  • Si usas GKE y Google Distributed Cloud, puedes usar el mismo lenguaje de consulta de Prometheus (PromQL) para las métricas de todos tus clústeres. También puedes usar la pestaña PromQL en el Explorador de métricas en la consola de Google Cloud .

Habilita y, luego, inhabilita Google Cloud Managed Service para Prometheus

A partir de la versión 1.30.0-gke.1930 de Google Distributed Cloud, Google Cloud Managed Service para Prometheus siempre está habilitado. En versiones anteriores, puedes editar el recurso de Stackdriver, stackdriver, para habilitar o inhabilitar Google Cloud Managed Service para Prometheus. Para inhabilitar Google Cloud Managed Service para Prometheus en versiones de clúster anteriores a 1.30.0-gke.1930, establece spec.featureGates.enableGMPForSystemMetrics en el recurso stackdriver como false.

Cómo ver los datos de las métricas

Cuando enableGMPForSystemMetrics se establece en true, las métricas de los siguientes componentes tienen un formato diferente para su almacenamiento y consulta en Cloud Monitoring:

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet y cAdvisor
  • kube-state-metrics
  • exportador de nodos

En el nuevo formato, puedes consultar las métricas anteriores con PromQL o el lenguaje de consulta de Monitoring (MQL):

PromQL

Ejemplo de consulta de PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

MQL

Para usar MQL, configura el recurso supervisado en prometheus_target, usa el nombre de la métrica con el prefijo kubernetes.io/anthos y agrega el tipo de Prometheus como sufijo al nombre de la métrica.

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Cómo configurar paneles de Grafana con Google Cloud Managed Service para Prometheus

Para usar Grafana con datos de métricas del servicio administrado de Google Cloud Managed Service para Prometheus, primero debes configurar y autenticar la fuente de datos de Grafana. Para configurar y autenticar la fuente de datos, usa el sincronizador de fuentes de datos (datasource-syncer) para generar credenciales OAuth2 y sincronizarlas con Grafana a través de la API de la fuente de datos de Grafana. El sincronizador de fuente de datos establece la API de Cloud Monitoring como la URL del servidor de Prometheus (el valor de la URL comienza con https://monitoring.googleapis.com) en la fuente de datos de Grafana.

Sigue los pasos que se indican en Consulta con Grafana para autenticar y configurar una fuente de datos de Grafana para consultar datos del servicio administrado de Google Cloud Managed Service para Prometheus.

En el repositorio anthos-samples en GitHub, se proporciona un conjunto de paneles de Grafana de muestra. Para instalar los paneles de muestra, haz lo siguiente:

  1. Descarga los archivos JSON de muestra:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Si tu fuente de datos de Grafana se creó con un nombre diferente de Managed Service for Prometheus, cambia el campo datasource en todos los archivos JSON:

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    Reemplaza [DATASOURCE_NAME] por el nombre de la fuente de datos en tu Grafana que apuntaba al servicio frontend de Prometheus.

  3. Accede a la IU de Grafana desde tu navegador y selecciona + Importar en el menú Paneles de control.

    Navega a la importación de paneles en Grafana.

  4. Sube el archivo JSON o copia y pega el contenido del archivo, y selecciona Cargar. Una vez que se cargue correctamente el contenido del archivo, selecciona Importar. De manera opcional, también puedes cambiar el nombre y el UID del panel antes de importarlo.

    Importación del panel en Grafana.

  5. El panel importado debería cargarse correctamente si Google Distributed Cloud y la fuente de datos están configurados correctamente. Por ejemplo, en la siguiente captura de pantalla, se muestra el panel configurado por cluster-capacity.json.

    Panel de capacidad del clúster en Grafana.

Recursos adicionales

Para obtener más información sobre Google Cloud Managed Service para Prometheus, consulta los siguientes recursos:

Configura los recursos del componente de Stackdriver

Cuando creas un clúster, Google Distributed Cloud crea automáticamente un recurso personalizado de Stackdriver. Puedes editar la especificación en el recurso personalizado a fin de anular los valores predeterminados para las solicitudes de CPU y memoria y los límites de un componente de Stackdriver, y puedes anular por separado la configuración de métricas optimizada predeterminada.

Anula las solicitudes y los límites predeterminados de CPU y memoria para un componente de Stackdriver

Los clústeres con una alta densidad de Pods generan una sobrecarga de registro y supervisión más alta. En casos extremos, los componentes de Stackdriver pueden informarse cerca del límite de uso de CPU y memoria o, incluso, pueden estar sujetos a reinicios constantes debido a los límites de recursos. En este caso, a fin de anular los valores predeterminados para los requisitos de CPU y memoria de un componente de Stackdriver, sigue estos pasos:

  1. Ejecuta el siguiente comando para abrir tu recurso personalizado de Stackdriver en un editor de línea de comandos:

    kubectl -n kube-system edit stackdriver stackdriver

  2. En el recurso personalizado de Stackdriver, agrega la sección resourceAttrOverride en el campo spec:

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Ten en cuenta que la sección resourceAttrOverride anula todos los límites y solicitudes predeterminados existentes para el componente que especificas. Los siguientes componentes son compatibles con resourceAttrOverride:

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    Un archivo de ejemplo se ve de la siguiente manera:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Para guardar los cambios en el recurso personalizado de Stackdriver, guarda y sal del editor de línea de comandos.

  4. Verifica el estado de tu Pod:

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    Una respuesta para un Pod en buen estado se ve de la siguiente manera:

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. Verifica las especificaciones del pod del componente para asegurarte de que los recursos estén configurados correctamente.

    kubectl -n kube-system describe pod POD_NAME

    Reemplaza POD_NAME con el nombre del Pod que acabas de cambiar. Por ejemplo, gke-metrics-agent-4th8r

    La respuesta es similar a la siguiente:

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Inhabilita las métricas optimizadas

De forma predeterminada, las implementaciones kube-state-metrics que se ejecutan en el clúster recopilan y, luego, informan un conjunto optimizado de métricas de kube a Stackdriver. Si necesitas métricas adicionales, te recomendamos encontrar un reemplazo de la lista de métricas de Google Distributed Cloud.

Estos son algunos ejemplos de reemplazos que puedes usar:

Métrica inhabilitada Reemplazos
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

Para inhabilitar la configuración predeterminada de las métricas optimizadas (no recomendado), haz lo siguiente:

  1. Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Configura el campo optimizedMetrics como false:

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. Guarda los cambios y cierra el editor de la línea de comandos.

Servidor de métricas

El Servidor de métricas es la fuente de las métricas de recursos del contenedor para varias canalizaciones con ajuste de escala automático. El servidor de métricas recupera las métricas de kubelets y las expone a través de la API de Metrics de Kubernetes. El HPA y el VPA usan estas métricas para determinar cuándo activar el ajuste de escala automático. El servidor de métricas se escala mediante el cambio de tamaño del complemento.

En casos extremos en los que la alta densidad del Pod crea demasiada sobrecarga de registro y supervisión, el servidor de métricas podría detenerse y reiniciarse debido a las limitaciones de recursos. En este caso, puedes asignar más recursos al servidor de métricas si editas el configmap metrics-server-config en el espacio de nombres gke-managed-metrics-server y cambias el valor de cpuPerNode y memoryPerNode.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

El contenido de ejemplo del ConfigMap es el siguiente:

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

Después de actualizar el ConfigMap, vuelve a crear los Pods del servidor de métricas con el siguiente comando:

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Enrutamiento de registros y métricas

El agente de reenvío de registros de Stackdriver (stackdriver-log-forwarder) envía registros de cada máquina de nodo a Cloud Logging. Del mismo modo, el agente de métricas de GKE (gke-metrics-agent) envía métricas de cada máquina de nodo a Cloud Monitoring. Antes de que se envíen los registros y las métricas, el operador de Stackdriver (stackdriver-operator) adjunta el valor del campo clusterLocation en el recurso personalizado stackdriver a cada entrada de registro y métrica antes de que se enruten a Google Cloud. Además, los registros y las métricas se asocian con el proyecto Google Cloud especificado en la especificación del recurso personalizado stackdriver (spec.projectID).

El recurso stackdriver obtiene valores para los campos clusterLocation y projectID de los campos location y projectID en la sección clusterOperations del recurso Cluster en el momento de la creación del clúster.

Todas las métricas y las entradas de registro que envían los agentes de Stackdriver se enrutan a un extremo de transferencia global. Desde allí, los datos se reenvían al extremo regional Google Cloud más cercano para garantizar la confiabilidad del transporte de datos.

Una vez que el extremo global recibe la métrica o la entrada de registro, lo que sucede a continuación depende del servicio:

  • Cómo se configura el enrutamiento de registros: Cuando el extremo de registro recibe un mensaje de registro, Cloud Logging pasa el mensaje a través del enrutador de registros. Los receptores y los filtros en la configuración del enrutador de registros determinan cómo enrutar el mensaje. Puedes enrutar las entradas de registro a destinos como los buckets de registros regionales, que almacenan la entrada de registro, o a Pub/Sub. Para obtener más información sobre cómo funciona el enrutamiento de registros y cómo configurarlo, consulta Descripción general del enrutamiento y el almacenamiento.

    En este proceso de enrutamiento, no se tienen en cuenta ni el campo clusterLocation en el recurso personalizado stackdriver ni el campo clusterOperations.location en la especificación del clúster. En el caso de los registros, clusterLocation se usa solo para etiquetar las entradas de registro, lo que puede ser útil para filtrar en el Explorador de registros.

  • Cómo se configura el enrutamiento de métricas: Cuando el extremo de métricas recibe una entrada de métrica, esta se enruta automáticamente para almacenarse en la ubicación especificada por la métrica. La ubicación en la métrica provino del campo clusterLocation en el recurso personalizado stackdriver.

  • Planifica tu configuración: Cuando configures Cloud Logging y Cloud Monitoring, configura el enrutador de registros y especifica un clusterOperations.location adecuado con ubicaciones que satisfagan mejor tus necesidades. Por ejemplo, si deseas que los registros y las métricas se envíen a la misma ubicación, establece clusterOperations.location en la misma región Google Cloud que el enrutador de registros usa para tu proyecto Google Cloud .

  • Actualiza la configuración de tus registros cuando sea necesario: Puedes realizar cambios en cualquier momento en la configuración de destino de los registros debido a requisitos comerciales, como planes de recuperación ante desastres. Los cambios en la configuración de Log Router enGoogle Cloud entran en vigencia rápidamente. Los campos location y projectID de la sección clusterOperations del recurso Cluster son inmutables, por lo que no se pueden actualizar después de crear el clúster. No te recomendamos que cambies los valores directamente en el recurso stackdriver. Este recurso vuelve al estado de creación del clúster original cada vez que una operación del clúster, como una actualización, activa una reconciliación.

Requisitos de configuración para Logging y Monitoring

Existen varios requisitos de configuración para habilitar Cloud Logging y Cloud Monitoring con Google Distributed Cloud. Estos pasos se incluyen en Configura una cuenta de servicio para usar con Logging y Monitoring en la página Habilita servicios de Google y en la siguiente lista:

  1. Se debe crear un lugar de trabajo de Cloud Monitoring dentro del proyectoGoogle Cloud . Para ello, haz clic en Monitoring en la consola deGoogle Cloud y sigue el flujo de trabajo.

  2. Debes habilitar las siguientes API de Stackdriver:

  3. Debes asignar las siguientes funciones de IAM a la cuenta de servicio que usan los agentes de Stackdriver:

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Etiquetas de registro

Muchos registros de Google Distributed Cloud tienen una etiqueta F:

logtag: "F"

Esta etiqueta significa que la entrada de registro está completa o llena. Para obtener más información sobre esta etiqueta, consulta Formato de registro en las propuestas de diseño de Kubernetes en GitHub.

Precios

No se aplican cargos por los registros y las métricas del sistema de la edición Google Kubernetes Engine (GKE) Enterprise.

En un clúster de Google Distributed Cloud, los registros y las métricas del sistema de la edición Enterprise de Google Kubernetes Engine (GKE) incluyen lo siguiente:

  • Registros y métricas de todos los componentes en un clúster de administrador
  • Registros y métricas de los componentes de estos espacios de nombres en un clúster de usuario: kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system.

Para obtener más información, consulta Precios de Google Cloud Observability.

Si quieres obtener información sobre los créditos de las métricas de Cloud Logging, comunícate con Ventas para obtener información sobre los precios.