Usar el Agente de operaciones y el protocolo OpenTelemetry (OTLP)

En este documento se describe cómo puede usar el agente de operaciones y el receptor del protocolo OpenTelemetry (OTLP) para recoger métricas y trazas definidas por el usuario de aplicaciones instrumentadas con OpenTelemetry y que se ejecutan en Compute Engine.

Este documento se organiza de la siguiente manera:

• Descripción general de los casos prácticos del receptor OTLP.
• Requisitos para usar el receptor OTLP.
• Configurar el agente para que use el receptor OTLP
• Usar el receptor para recoger métricas. En esta sección se describe cómo consultar las métricas de OpenTelemetry en Cloud Monitoring.
• Usar el receptor para recoger trazas. En esta sección se describe cómo autorizar una cuenta de servicio para escribir datos en Cloud Trace.

Información general sobre el uso del receptor OTLP

Con el receptor OTLP del agente de Ops, puedes hacer lo siguiente:

• Instrumenta tu aplicación con uno de los SDKs específicos de lenguaje de OpenTelemetry. Para obtener información sobre los idiomas admitidos, consulta Instrumentación de OpenTelemetry. La combinación de los SDKs de OpenTelemetry y el agente de operaciones te permite hacer lo siguiente:
  • Recoge métricas de OTLP de tu aplicación y envíalas a Cloud Monitoring para analizarlas.
  • Recoge intervalos de OTLP (datos de trazas) de tu aplicación y, a continuación, envíalos a Cloud Trace para analizarlos.
• Recoger trazas de aplicaciones de terceros que tengan asistencia integrada para OTLP o complementos con dicha asistencia, como Nginx. El receptor OTLP del agente de operaciones puede recoger esas trazas. Por ejemplo, consulta el módulo nginx de OpenTelemetry.
• Usa la instrumentación personalizada de OpenTelemetry.
• Usa la instrumentación automática de OpenTelemetry.

Puedes usar el receptor para recoger métricas, trazas o ambas. Una vez que el agente de Ops haya recogido las métricas, puede usar las funciones de Cloud Monitoring, como gráficos, paneles de control y políticas de alertas, para monitorizarlas. Si tu aplicación también envía datos de traza, puedes usar Cloud Trace para analizarlos.

Ventajas

Antes de que estuviera disponible el complemento OTLP para el agente de operaciones, las principales formas de instrumentar tus aplicaciones para recoger métricas y trazas definidas por el usuario eran las siguientes:

• Usar bibliotecas de cliente que implementen la API Monitoring o la API Trace.
• Usar las bibliotecas OpenCensus anteriores.

Usar OpenTelemetry con el receptor OTLP ofrece varias ventajas con respecto a estos métodos, entre las que se incluyen las siguientes:

• OpenTelemetry sustituye a OpenCensus. El proyecto OpenCensus se va a archivar. Para obtener más información, consulta el artículo ¿Qué es OpenTelemetry?
• La ingestión se controla a nivel de agente, por lo que no tienes que volver a desplegar tus aplicaciones si cambia la configuración del agente.
• Tus aplicaciones no necesitan configurar credenciales de Google Cloud , ya que toda la autorización se gestiona a nivel del agente.
• El código de tu aplicación no contiene código de monitorización ni de seguimiento específicos de Google Cloud. No es necesario que uses directamente la API Monitoring ni la API Trace.
• Tu aplicación envía datos al agente de operaciones y, si falla, no se perderán los datos que haya recogido el agente.

Limitaciones

El receptor de Agente de operaciones expone el receptor OTLP, que admite el transporte gRPC. No se admite HTTP, que se usa principalmente para clientes JavaScript. Para obtener más información sobre el protocolo OpenTelemetry, consulte Detalles del protocolo.

El receptor OTLP no recoge registros. Puede recoger registros mediante el agente de operaciones y otros receptores, e incluir información de registro en los intervalos de OTLP, pero el receptor de OTLP no admite la recogida directa de registros. Para obtener información sobre cómo usar el agente de Ops para recoger registros, consulta Configuraciones de registro.

Requisitos previos

Para recoger métricas y trazas de OTLP mediante el receptor de OTLP y el agente de operaciones, debes instalar el agente de operaciones versión 2.37.0 o una posterior.

En este documento se da por hecho que ya tienes una aplicación basada en OpenTelemetry escrita con uno de los SDKs de OpenTelemetry. En este documento no se explica cómo usar los SDKs de OpenTelemetry. Para obtener información sobre los SDKs y los idiomas admitidos, consulta Instrumentación de OpenTelemetry.

Configurar el agente de operaciones

Para configurar el agente de operaciones de forma que use el receptor OTLP, haz lo siguiente:

1. Modifica el archivo de configuración de usuario del agente de operaciones para incluir el receptor OTLP.
2. Reinicia el agente de operaciones.

En las siguientes secciones se describe cada paso.

Modificar el archivo de configuración de usuario del agente de operaciones

Añada los elementos de configuración del receptor OTLP al archivo de configuración de usuario del agente de operaciones:

• En Linux: /etc/google-cloud-ops-agent/config.yaml
• En Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml

Para obtener información general sobre cómo configurar el agente, consulta el artículo sobre el modelo de configuración.

El receptor OTLP introduce la sección de configuración combined para el agente de operaciones. Para usar el receptor, debes configurar los servicios de métricas y de trazas, aunque no uses ambos.

En las siguientes secciones se describen los pasos de configuración del receptor OTLP.

Añade la sección de combined receptor

Coloca el receptor de métricas y trazas de OTLP en la sección combined. No se permiten procesadores ni servicios en la sección combined. No debes configurar ningún otro receptor con el mismo nombre que un receptor de la sección combined. En el siguiente ejemplo, se usa otlp como nombre del receptor.

La configuración mínima de combined para OTLP es la siguiente:

combined:
  receivers:
    otlp:
      type: otlp

El receptor otlp tiene las siguientes opciones de configuración:

• type: obligatorio. Debe ser otlp
• grpc_endpoint: opcional. El endpoint de gRPC en el que escucha el receptor OTLP. El valor predeterminado es 0.0.0.0:4317.

• metrics_mode: opcional. El valor predeterminado es googlemanagedprometheus, lo que significa que el receptor envía métricas de OTLP como métricas con formato de Prometheus mediante la API de Prometheus, que también usa Managed Service para Prometheus.

  Para enviar las métricas como métricas personalizadas de Cloud Monitoring mediante la API Monitoring, defina la opción metrics_mode con el valor googlecloudmonitoring.

  Esta opción afecta a la forma en que se ingieren las métricas y a cómo se miden para la facturación. Para obtener más información sobre los formatos de métricas, consulta Formatos de ingestión de métricas de OTLP.

Añadir canalizaciones OTLP a tus servicios

El receptor OTLP puede recoger métricas y trazas, por lo que debes definir un servicio para las métricas y otro para las trazas. Si no vas a recoger métricas ni trazas, puedes crear servicios vacíos. Si ya tienes servicios con otras canalizaciones, puedes añadirles la canalización OTLP.

A continuación, se muestran los servicios metrics y traces con el receptor OTLP incluido en las canalizaciones:

combined:
  receivers:
    otlp:
      type: otlp
metrics:
  service:
    pipelines:
      otlp:
        receivers: [otlp]
traces:
  service:
    pipelines:
      otlp:
        receivers: [otlp]

Si no quieres usar el servicio metrics ni el traces para la recogida de OTLP, deja el receptor de OTLP fuera de la canalización del servicio. El servicio debe existir, aunque no tenga ninguna canalización. Si tu aplicación envía datos de un tipo determinado y no hay ninguna canalización correspondiente que incluya el receptor, el agente de Ops descartará los datos.

Reiniciar el agente de operaciones

Para aplicar los cambios de configuración, debes reiniciar el agente de Ops.

Recoger métricas de OTLP

Cuando usas el receptor OTLP para recoger métricas de tus aplicaciones OpenTelemetry, la principal opción de configuración del receptor es la API que quieres usar para ingerir las métricas.

Para ello, cambia la opción metrics_mode en la configuración del receptor otlp o usa el valor predeterminado. Esta opción afecta a la forma en que se ingieren las métricas de OTLP en Cloud Monitoring y a cómo se miden esos datos a efectos de facturación.

La opción metrics_mode no afecta a tu capacidad para crear gráficos, paneles de control y políticas de alertas en Monitoring.

• Para obtener información sobre cómo crear gráficos y paneles de control, consulta el artículo Descripción general de los paneles de control y los gráficos.
• Para obtener información sobre las políticas de alertas, consulta el artículo Descripción general de las alertas.

En las siguientes secciones se describen las diferencias en los formatos que usan los modos de métrica y cómo consultar los datos insertados para usarlos en Monitoring.

Formatos de ingestión de métricas de OTLP

El receptor OTLP proporciona la opción metrics_mode, que especifica la API que se usa para ingerir los datos de métricas. De forma predeterminada, el receptor usa la API de Prometheus. El valor predeterminado de la opción metrics_mode es googlemanagedprometheus. Las métricas se ingieren mediante la misma API que usa Managed Service para Prometheus.

Puede configurar el receptor para que envíe los datos de métricas a la API de Cloud Monitoring. Para enviar datos a la API Monitoring, asigna el valor googlecloudmonitoring a la opción metrics_mode, como se muestra en el siguiente ejemplo:

combined:
  receivers:
    otlp:
      type: otlp
      metrics_mode: googlecloudmonitoring

El formato de ingestión que uses determinará cómo se asignan las métricas de OTLP a Cloud Monitoring. Puede crear gráficos, paneles de control y políticas de alertas en Monitoring para métricas de cualquiera de los dos formatos, pero las métricas se consultan de forma diferente.

El formato de ingestión también determina el modelo de precios que se utiliza para la ingestión de datos.

En las siguientes secciones se describen los precios, las diferencias estructurales entre una métrica insertada por la API de Prometheus y la misma métrica insertada por la API de Monitoring, y cómo hacer referencia a las métricas en las consultas.

Precios y cuotas

El formato de ingestión que uses determinará cómo se cobran las métricas de OTLP:

• API de Prometheus: cuando usas la API de Prometheus para ingerir las métricas de tu aplicación, los datos están sujetos a precios basados en muestras, como si las métricas se hubieran recibido mediante Managed Service para Prometheus.

  • Para ver los precios actuales, consulta el resumen de precios de Cloud Monitoring.
  • Para obtener más información sobre cómo se cuentan las muestras y se estiman los costes, consulta el artículo Métricas facturadas por muestras ingeridas.

• API Monitoring: cuando usas la API Monitoring para ingerir las métricas de tu aplicación, los datos están sujetos a precios basados en el volumen, como los datos de otras integraciones con el agente de operaciones.

  • Para ver los precios actuales, consulta el resumen de precios de Cloud Monitoring.
  • Para obtener más información sobre el volumen de ingestión y la estimación de costes, consulta Métricas cobradas por bytes ingeridos.

Las métricas ingeridas mediante el receptor OTLP se consideran tipos de métricas "personalizadas" cuando se ingieren en Cloud Monitoring y están sujetas a las cuotas y los límites de las métricas personalizadas.

Estructura de métricas

Cloud Monitoring describe el formato de los datos de métricas mediante un esquema llamado descriptor de métricas. El descriptor de métrica incluye el nombre de la métrica, el tipo de datos de los valores de la métrica, cómo se relaciona cada valor con los valores anteriores y las etiquetas asociadas a los valores. Si configura el receptor OTLP para que ingiera métricas mediante la API de Prometheus, el descriptor de métricas que se crea será diferente del que se crea cuando usa la API de Monitoring.

API de Prometheus: cuando usas la API de Prometheus para ingerir las métricas de tu aplicación, cada métrica se transforma mediante la transformación estándar de OpenTelemetry a Prometheus y se asigna a un tipo de recurso monitorizado de Cloud Monitoring.

• La transformación incluye los siguientes cambios:
  • El nombre de la métrica OTLP tiene el prefijo prometheus.googleapis.com/.
  • Los caracteres no alfanuméricos, como los puntos (.), del nombre de la métrica OTLP se sustituyen por guiones bajos (_).
  • El nombre de la métrica OTLP tiene un sufijo que indica el tipo de métrica, como /gauge o /counter.
• Las siguientes etiquetas, rellenadas con valores del recurso OTLP, se añaden a la métrica:
  • instance_name: valor del atributo de recurso host.name.
  • machine_type: valor del atributo de recurso host.type.

• El recurso monitorizado registrado con las mediciones de la métrica es del tipo genérico prometheus_target. La serie temporal de Prometheus generada incluye las siguientes etiquetas del recurso prometheus_target, rellenadas con valores del recurso OTLP:

  • location: valor del atributo cloud.availability_zone del recurso.
  • namespace: valor del atributo de recurso host.id.

  El tipo de recurso prometheus_target también incluye estas etiquetas:

  • project_id: el identificador del proyecto Google Cloud , como my-project, en el que se ejecuta el agente de operaciones.
  • cluster: el valor siempre es __gce__ cuando el Agente de operaciones recoge las métricas.

Si faltan los atributos de recurso que se usan para los valores de las etiquetas en los datos de OTLP entrantes, los valores se toman de la información sobre la máquina virtual que ejecuta el agente de Ops. Este comportamiento significa que los datos de OTLP sin estos atributos de recurso aparecen con las mismas etiquetas que los datos recogidos por el receptor de Prometheus del agente de operaciones.

API Monitoring: cuando usas la API Monitoring para ingerir las métricas de tu aplicación, cada métrica se gestiona de la siguiente manera:

• El nombre de la métrica OTLP tiene el prefijo de la cadena workload.googleapis.com/, a menos que ya contenga esta cadena u otro dominio de métrica válido, como custom.googleapis.com. Te recomendamos que uses el dominio "workload".
• El recurso monitorizado registrado con las mediciones de la métrica es el tipo de máquina virtual de Compute Engine gce_instance.

En los siguientes ejemplos se muestran los descriptores de métricas de un par de métricas de OpenTelemetry. Las métricas las crea una aplicación que usa la biblioteca de métricas Go OpenTelemetry. La pestaña API de Prometheus muestra el descriptor de métricas creado cuando el receptor de OTLP usa el modo de métricas de Prometheus predeterminado. En la pestaña API Monitoring (API Monitoring) se muestra el descriptor de métrica creado cuando el receptor OTLP usa el modo de métrica googlecloudmonitoring.

No cambia nada en la aplicación que crea la métrica. El único cambio es el modo de métrica que usa el receptor OTLP.

La aplicación crea una métrica de tipo Gauge de OTLP, otlp.test.gauge, que registra valores de coma flotante de 64 bits. En las siguientes pestañas se muestra el descriptor de métricas que crea cada API de ingesta:

{
  "name": "projects/PROJECT_ID/metricDescriptors/prometheus.googleapis.com/otlp_test_gauge/gauge",
  "labels": [
    {
      "key": "instance_name"
    },
    {
      "key": "machine_type"
    }
  ],
  "metricKind": "GAUGE",
  "valueType": "DOUBLE",
  "type": "prometheus.googleapis.com/otlp_test_gauge/gauge",
  "monitoredResourceTypes": [
    "prometheus_target"
  ]
}

{
  "name": "projects/PROJECT_ID/metricDescriptors/workload.googleapis.com/otlp.test.gauge",
  "labels": [
    {
      "key": "instrumentation_source"
    }
  ],
  "metricKind": "GAUGE",
  "valueType": "DOUBLE",
  "type": "workload.googleapis.com/otlp.test.gauge",
  "monitoredResourceTypes": [
    "gce_instance",
    ...many other types deleted...
  ]
}

La aplicación crea una métrica de contador OTLP, otlp.test.cumulative, que registra valores de coma flotante de 64 bits crecientes. En las siguientes pestañas se muestra el descriptor de métricas que crea cada API de ingesta:

{
  "name": "projects/PROJECT_ID/metricDescriptors/prometheus.googleapis.com/otlp_test_cumulative/counter",
  "labels": [
    {
      "key": "instance_name"
    },
    {
      "key": "machine_type"
    }
  ],
  "metricKind": "CUMULATIVE",
  "valueType": "DOUBLE",
  "type": "prometheus.googleapis.com/otlp_test_cumulative/counter",
  "monitoredResourceTypes": [
    "prometheus_target"
  ]
}

{
  "name": "projects/PROJECT_ID/metricDescriptors/workload.googleapis.com/otlp.test.cumulative",
  "labels": [
    {
      "key": "instrumentation_source"
    }
  ],
  "metricKind": "CUMULATIVE",
  "valueType": "DOUBLE",
  "type": "workload.googleapis.com/otlp.test.cumulative",
  "monitoredResourceTypes": [
    "gce_instance",
    ...many other types deleted...
  ]
}

En la siguiente tabla se resumen algunas de las diferencias de formato impuestas por las APIs que se usan para ingerir métricas de OTLP:

Formatos de ingestión y consultas

El modo de métricas usado en el receptor OTLP afecta a la forma en que consultas las métricas resultantes en Cloud Monitoring al crear gráficos, paneles de control y políticas de alertas.

Cuando configuras un gráfico, un panel de control o una política de alertas en Cloud Monitoring, la configuración incluye una consulta de los datos en los que se basa el gráfico, el panel de control o la política de alertas.

Cloud Monitoring admite las siguientes herramientas para consultar datos de métricas:

• Una interfaz basada en un creador de consultas integrada en herramientas como el explorador de métricas, la interfaz del creador de paneles de control y la interfaz de configuración de políticas de alertas.
• Lenguaje de consulta de Prometheus (PromQL): lenguaje de consulta basado en texto que utiliza Prometheus de código abierto.

Para obtener información sobre cómo consultar métricas de OTLP con estas herramientas, consulta los siguientes artículos:

• Consultar métricas de OTLP ingeridas mediante la API de Prometheus
• Consultar métricas de OTLP ingeridas mediante la API Monitoring

Consultar métricas de OTLP ingeridas mediante la API de Prometheus

En esta sección se muestra cómo consultar métricas de OTLP ingeridas mediante la API de Prometheus, que es el modo de métricas predeterminado del receptor de OTLP.

Las consultas se basan en las métricas de OTLP descritas en Estructura de métricas:

• otlp.test.gauge: una métrica de tipo Gauge de OTLP que registra valores de coma flotante de 64 bits.
• otlp.test.cumlative: una métrica de contador de OTLP que registra valores de punto flotante de 64 bits crecientes.

Estas métricas se ingieren en Cloud Monitoring con los siguientes tipos de métricas, que funcionan como nombres:

• prometheus.googleapis.com/otlp_test_gauge/gauge
• prometheus.googleapis.com/otlp_test_cumulative/counter

Las métricas ingeridas mediante la API de Prometheus se escriben en el tipo de recurso monitorizado prometheus_target.

En las pestañas se muestra el aspecto de las consultas básicas cuando se consultan las métricas mediante la consola Google Cloud . En estos ejemplos se usa Explorador de métricas, pero los principios son los mismos para los paneles de control y las políticas de alertas.

Consultar métricas de OTLP ingeridas mediante la API Monitoring

En esta sección se muestra cómo consultar las métricas de OTLP ingeridas mediante la API Monitoring. Para seleccionar la API de Cloud Monitoring, asigna el valor googlecloudmonitoring al campo metrics_mode del receptor OTLP.

Las consultas se basan en las métricas de OTLP descritas en Estructura de métricas:

• otlp.test.gauge: una métrica de tipo Gauge de OTLP que registra valores de coma flotante de 64 bits.
• otlp.test.cumlative: una métrica de contador de OTLP que registra valores de punto flotante de 64 bits crecientes.

Estas métricas se ingieren en Cloud Monitoring con los siguientes tipos de métricas, que funcionan como nombres:

• workload.googleapis.com/otlp.test.gauge
• workload.googleapis.com/otlp.test.cumulative

Las métricas ingeridas mediante la API Monitoring se escriben en el tipo de recurso monitorizado gce_instance.

En las pestañas se muestra el aspecto de las consultas básicas cuando se consultan las métricas mediante la consola Google Cloud . En estos ejemplos se usa Explorador de métricas, pero los principios son los mismos para los paneles de control y las políticas de alertas.

Ver el uso de las métricas y los diagnósticos en Cloud Monitoring

La página Gestión de métricas de Cloud Monitoring proporciona información que puede ayudarte a controlar la cantidad que gastas en métricas facturables sin que esto afecte a la observabilidad. En la página Gestión de métricas se muestra la siguiente información:

• Volúmenes de ingesta para la facturación basada en bytes y en muestras, en todos los dominios de métricas y para métricas individuales.
• Datos sobre las etiquetas y la cardinalidad de las métricas.
• Número de lecturas de cada métrica.
• Uso de métricas en políticas de alertas y paneles de control personalizados.
• Tasa de errores de escritura de métricas.

También puede usar la página Gestión de métricas para excluir las métricas que no necesite y, de esta forma, no incurrir en los costes de ingesta.

Para ver la página Gestión de métricas, haz lo siguiente:

1. En la Google Cloud consola, ve a la página query_stats Gestión de métricas:

   Ir a Gestión de métricas

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Monitorización.

2. En la barra de herramientas, selecciona el periodo que quieras. De forma predeterminada, la página Gestión de métricas muestra información sobre las métricas recogidas en el día anterior.

Para obtener más información sobre la página Gestión de métricas, consulta el artículo Ver y gestionar el uso de métricas.

Recoger trazas de OTLP

Si has configurado el agente de Ops para recoger trazas, pero no ves ninguna en Cloud Trace cuando ejecutas tu aplicación, puede que tengas que asignar un rol adicional a la cuenta de servicio de Compute Engine que usa el agente. De forma predeterminada, la cuenta de servicio obtiene los roles necesarios para escribir métricas y registros, pero no trazas.

En las siguientes secciones se describe cómo conceder a la cuenta de servicio la autorización de Cloud Trace necesaria.

Determinar los roles concedidos a la cuenta de servicio

Para ver los roles concedidos a una cuenta de servicio, ejecuta el siguiente comando gcloud projects get-iam-policy:

gcloud projects get-iam-policy PROJECT_ID --format="table(bindings.role)" --flatten="bindings[].members" --filter="bindings.members:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com"

Puede que veas un resultado como el siguiente:

ROLE
roles/logging.logWriter
roles/monitoring.metricWriter

Si el resultado incluye roles/cloudtrace.agent o roles/cloudtrace.admin, significa que la cuenta de servicio tiene permisos suficientes para escribir trazas. Para asignar uno de estos roles a la cuenta de servicio, consulta la siguiente sección.

Asignar el rol de Cloud Trace a la cuenta de servicio

En el caso de una cuenta de servicio, suele ser adecuado el rol Agente de Cloud Traceroles/cloudtrace.agent. Para conceder este rol a la cuenta de servicio, ejecuta el siguiente comando gcloud projects add-iam-policy-binding:

gcloud projects add-iam-policy-binding PROJECT_ID --member "serviceAccount:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com" --role="roles/cloudtrace.agent"

A continuación, puedes ejecutar el comando gcloud projects get-iam-policy para verificar que se ha realizado el cambio:

gcloud projects get-iam-policy PROJECT_ID --format="table(bindings.role)" --flatten="bindings[].members" --filter="bindings.members:SERVICE_ACCT_NAME@PROJECT_ID.iam.gserviceaccount.com"

El resultado ahora incluye roles/cloudtrace.agent:

ROLE
roles/cloudtrace.agent
roles/logging.logWriter
roles/monitoring.metricWriter

Para obtener más información sobre cómo gestionar roles de gestión de identidades y accesos, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Después de autorizar a la cuenta de servicio que usa el agente de Ops para escribir datos en Cloud Trace, cuando ejecutes tu aplicación basada en OpenTelemetry, las trazas aparecerán en Cloud Trace.

Inhabilitar el receptor OTLP

Si recoges métricas y trazas de OTLP con el agente de operaciones y quieres inhabilitar la recogida de métricas o de trazas, pero no de ambas, haz lo siguiente:

1. Para inhabilitar la recogida de métricas o de trazas, haz uno de los siguientes cambios en el archivo de configuración del usuario, config.yaml:

   • Elimina la canalización de otlp del servicio metrics.
   • Elimina la canalización de otlp del servicio traces.

2. Reinicia el agente de operaciones.

Para inhabilitar la recogida de métricas y trazas de OTLP por parte del agente de operaciones, haz lo siguiente:

1. Elimina la configuración de OTLP del archivo de configuración del usuario:

   • Elimina toda la sección combined, incluida la otlp receiver.
   • Elimina la canalización de otlp del servicio metrics.
   • Eliminar todo el servicio traces.

2. Reinicia el agente de operaciones.

Siguientes pasos

Una vez que se hayan ingerido las métricas y los rastreos de tu aplicación, puedes usar la Google Cloud consola para monitorizar y analizar tus datos.

• Para obtener información sobre los paneles de control y los tipos de gráficos que puedes crear, consulta el artículo Paneles de control y gráficos.
• Para obtener información sobre las políticas de alertas, consulta Usar políticas de alertas.
• Para obtener información sobre cómo analizar datos de trazas, consulta Buscar y explorar trazas.