Ver métricas

En este tema, se explica cómo ver las métricas de Apigee Hybrid en un panel de Cloud Operations.

Acerca de Cloud Operations

Para obtener más información sobre las métricas, los paneles y las Cloud Operations, consulta las siguientes páginas:

Habilita métricas híbridas

Antes de que las métricas híbridas se puedan enviar a Cloud Operations, primero debes habilitar la recopilación de métricas. Consulta Configura la recopilación de métricas para este procedimiento.

Información sobre las etiquetas y los nombres de métricas híbridas

Cuando está habilitada, Apigee Hybrid propaga de forma automática las métricas de Cloud Operations. El prefijo del nombre de dominio de las métricas creadas por Apigee Hybrid es el siguiente:

apigee.googleapis.com/

Por ejemplo, la métrica /proxy/request_count contiene la cantidad total de solicitudes que recibió un proxy de API. Por lo tanto, el nombre de la métrica en Cloud Operations es el siguiente:

apigee.googleapis.com/proxy/request_count

Cloud Operations te permite filtrar y agrupar datos de métricas según las etiquetas. Algunas etiquetas están predefinidas, y otras se agregan de forma explícita mediante Apigee Hybrid. En la sección Métricas disponibles a continuación, se enumeran todas las métricas híbridas disponibles y las etiquetas agregadas específicamente para una métrica que puedes usar para filtrar y agrupar.

Cómo ver métricas

En el siguiente ejemplo, se muestra cómo ver las métricas en Cloud Monitoring:
  1. Abre el Explorador de métricas de Monitoring en un navegador. Como alternativa, si ya estás en la consola de Cloud Operations, selecciona Explorador de métricas.

  2. En Find resource type and metric, busca y selecciona la métrica que deseas examinar. Elige una métrica específica que aparezca en Métricas disponibles o busca una.

  3. Selecciona la métrica deseada.
  4. Aplica filtros. Las opciones de filtro para cada métrica se enumeran en Métricas disponibles.
  5. Cloud Operations muestra el gráfico de la métrica seleccionada.
  6. Haz clic en Guardar.

Crea un panel

Los paneles son una forma de ver y analizar los datos de las métricas que son importantes para ti. Cloud Operations proporciona paneles predefinidos para los recursos y servicios que usas, y también puedes crear paneles personalizados.

Utiliza un gráfico para mostrar una métrica de Apigee en tu panel personalizado. Con los paneles personalizados, tienes el control total sobre los gráficos que se muestran y su configuración. Para obtener más información sobre cómo crear gráficos, consulta Crea gráficos.

En el siguiente ejemplo, se muestra cómo crear un panel en Cloud Operations y, luego, agregar gráficos para ver datos de métricas:

  1. Abre el Explorador de métricas de Monitoring en un navegador y, luego, selecciona Paneles.
  2. Selecciona + Crear panel.
  3. Proporciona un nombre al panel. Por ejemplo: Tráfico de solicitud de proxy híbrido
  4. Haz clic en Confirmar.

  5. Para cada gráfico que desees agregar a tu panel, sigue estos pasos:

    1. En el panel, selecciona Agregar gráfico.
    2. Selecciona la métrica deseada como se describió con anterioridad en Visualiza métricas.
    3. Completa el cuadro de diálogo para definir tu gráfico.
    4. Haz clic en Guardar. Cloud Operations muestra los datos para la métrica seleccionada.

Métricas disponibles

En las siguientes tablas, se enumeran las métricas para analizar el tráfico del proxy. Para obtener más información sobre cada métrica de Apigee, consulta Métricas de Google Cloud.

Métricas de tráfico del servidor, de destino y de proxies

Open Telemetry recopila y procesa métricas (como se describe en Recopilación de métricas) para tráfico del servidor, de proxies y de destino.

En la siguiente tabla, se describen las métricas que usa el recopilador de Open Telemetry.

Nombre de la métrica Usar
/proxy/request_count Cantidad de solicitudes al proxy de Apigee desde que se registró la última muestra.
/proxy/response_count Cantidad de respuestas que envía el proxy de API de Apigee.
/proxy/latencies Distribución de latencias, que se calculan desde el momento en que el proxy de Apigee recibió la solicitud hasta el momento en que se envió la respuesta del proxy de Apigee al cliente.
/proxyv2/request_count La cantidad total de solicitudes de proxy de API recibidas.
/proxyv2/response_count La cantidad total de respuestas recibidas del proxy de API.
/proxyv2/latencies_percentile Percentil de todas las respuestas de la política de la API a una solicitud.
/target/request_count Cantidad de solicitudes enviadas al destino de Apigee desde que se registró el último muestreo.
/target/response_count Cantidad de respuestas recibidas del destino de Apigee desde que se registró la última muestra.
/target/latencies Distribución de latencias, que se calculan desde el momento en que se envió la solicitud al objetivo de Apigee hasta el momento en que el proxy de Apigee recibió la respuesta. Este tiempo no incluye la sobrecarga del proxy de la API de Apigee.
/targetv2/request_count La cantidad total de solicitudes enviadas al destino del proxy.
/targetv2/response_count La cantidad total de respuestas recibidas del destino del proxy.
/server/fault_count

La cantidad total de fallas para la aplicación del servidor.

Por ejemplo, la aplicación puede ser apigee-runtime, apigee-synchronizer o apigee-udca. Usa la etiqueta pod_name para filtrar los resultados por aplicación.

/server/nio Esta es una métrica de medidor que se puede filtrar por la etiqueta state para recuperar detalles de varias etiquetas. Los valores representan diferentes operaciones del sistema y de E/S. Las etiquetas como accepted, accepted_total, close_failed, close_success, conn_pending, connected, connected_total, max_conn y timeouts se relacionan con las operaciones de socket y conexión. Las etiquetas restantes pertenecen a otras operaciones del sistema.
/server/num_threads La cantidad de subprocesos activos que no son de daemon en el servidor.
/server/request_count

La cantidad total de solicitudes que recibió la aplicación del servidor.

Por ejemplo, la aplicación puede ser apigee-runtime, apigee-synchronizer o apigee-udca. Usa la etiqueta pod_name para filtrar los resultados por aplicación.
/server/response_count

Cantidad total de respuestas que envía la aplicación del servidor.

Por ejemplo, la aplicación puede ser apigee-runtime, apigee-synchronizer o apigee-udca. Usa la etiqueta pod_name para filtrar los resultados por aplicación.
/server/latencies

La latencia es la latencia en milisegundos que presenta la aplicación de servidor.

Por ejemplo, la aplicación puede ser apigee-runtime, apigee-synchronizer o apigee-udca. Usa la etiqueta pod_name para filtrar los resultados por aplicación.
/upstream/request_count

El número de solicitudes enviadas por la aplicación del servidor a su aplicación ascendente.

Por ejemplo, para el apigee-synchronizer, el plano de control es ascendente. Por lo tanto, upstream/request_count para apigee-synchronizer es una métrica que indica las solicitudes que apigee-synchronizer realizó en el plano de control.
/upstream/response_count

El número de respuestas que recibe la aplicación del servidor desde su aplicación ascendente.

Por ejemplo, para apigee-synchronizer, el plano de control es ascendente. Por lo tanto, upstream/response_count para apigee-synchronizer es una métrica que indica las solicitudes que apigee-synchronizer recibió del plano de control.
/upstream/latencies

La latencia incurrida en la aplicación de servidor ascendente en milisegundos.

Por ejemplo, para apigee-synchronizer, el plano de control es ascendente. Por lo tanto, upstream/latencies para apigee-synchronizer es una métrica que indica la latencia del plano de control.

Métricas de UDCA

Open Telemetry recopila y procesa métricas (como se describe en la Recopilación de métricas) para el servicio de UDCA, así como lo hace con otros servicios híbridos.

En la siguiente tabla, se describen las métricas que el recopilador de Open Telemetry usa en los datos de métricas de UDCA.

state

state

Nombre de la métrica Usar
/udca/server/local_file_oldest_ts

La marca de tiempo, en milisegundos, desde el inicio de la época de Unix en el archivo más antiguo del conjunto de datos.

Esta se calcula cada 60 segundos y no refleja el estado en tiempo real. Si el UDCA está actualizado y no hay archivos en espera para subir cuando se calcula esta métrica, este valor será 0.

Si este valor continúa aumentando, significa que los archivos anteriores aún se encuentran en el disco.
/udca/server/local_file_latest_ts

La marca de tiempo, en milisegundos desde el inicio de la época de Unix, para el último archivo en el disco según el estado

Esta se calcula cada 60 segundos y no refleja el estado en tiempo real. Si el UDCA está actualizado y no hay archivos en espera para subir cuando se calcula esta métrica, este valor será 0.
/udca/server/local_file_count

Un conteo de la cantidad de archivos en el disco en el pod de recopilación de datos.

Idealmente, el valor estará cerca de 0. Un valor alto coherente indica que los archivos no se están subiendo o que el UDCA no puede subirlos con la velocidad suficiente.

Este valor se calcula cada 60 segundos y no refleja el estado del UDCA en tiempo real.
/udca/server/total_latencies

El intervalo de tiempo, en segundos, entre la creación del archivo de datos y el momento en que el archivo de datos se subió de forma correcta.

Los buckets serán de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s y 64 s.

Histograma de la latencia total desde el momento de creación del archivo hasta el momento en que el archivo se subió de forma correcta.
/udca/server/upload_latencies

El tiempo total, en segundos, que UDCA necesitó para subir un archivo de datos.

Los buckets serán de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s y 64 s.

Las métricas mostrarán un histograma para la latencia de carga total, incluidas todas las llamadas ascendentes.
/udca/upstream/http_error_count

El conteo total de errores HTTP que UDCA encontró. Esta métrica es útil para determinar qué parte de las dependencias externas de la UDCA falla y por qué.

Estos errores pueden surgir para varios servicios (getDataLocation, Cloud storage, Token generator) y para varios conjuntos de datos (como api y trace) con varios códigos de respuesta.
/udca/upstream/http_latencies

La latencia ascendente de los servicios, en segundos.

Los buckets serán de 100 ms, 250 ms, 500 ms, 1 s, 2 s, 4 s, 8 s, 16 s, 32 s y 64 s.

Histograma de la latencia desde los servicios ascendentes.
/udca/upstream/uploaded_file_sizes

El tamaño del archivo que se sube a los servicios de Apigee, en bytes.

Los buckets serán de 1 KB, 10 KB, 100 KB, 1 MB, 10 MB, 100 MB y 1 GB.

Histograma del tamaño de archivo por conjunto de datos, organización y entorno
/udca/upstream/uploaded_file_count Un conteo de los archivos que UDCA subió a los servicios de Apigee.

Ten en cuenta lo siguiente:

  • El valor del conjunto de datos event debe seguir aumentando.
  • El valor del conjunto de datos api debería seguir aumentando si la organización o el entorno tiene tráfico constante.
  • El valor del conjunto de datos trace debería aumentar cuando uses las herramientas de seguimiento de Apigee para depurar o inspeccionar tus solicitudes.
/udca/disk/used_bytes

El espacio que ocupan los archivos de datos en el disco del pod de recopilación de datos, expresado en bytes.

Un aumento en este valor a lo largo del tiempo:

  • ready_to_upload implica que el agente se retrasa.
  • failed indica que los archivos se están acumulando en el disco y no se están subiendo. Este valor se calcula cada 60 segundos.
/udca/server/pruned_file_count El recuento de archivos que se borraron debido a que el período de vida útil (TTL) superó el límite establecido. El conjunto de datos puede incluir la API, el seguimiento entre otros, y el estado puede ser UPLOADED, FAILED o DISCARDED.
/udca/server/retry_cache_size

Un conteo de la cantidad de archivos, por conjunto de datos, que UDCA intenta subir.

Después de 3 reintentos para cada archivo, UDCA mueve el archivo al subdirectorio /failed y lo quita de esta caché. Un aumento de este valor a lo largo del tiempo implica que no se está borrando la caché, lo que sucede cuando los archivos se mueven al subdirectorio /failed después de 3 reintentos.

Métricas de Cassandra

Open Telemetry recopila y procesa métricas (como se describe en Recopilación de métricas) para Cassandra tal como lo hace con otros servicios híbridos.

En la siguiente tabla, se describen las métricas que el recopilador de Open Telemetry usa en los datos de métricas de Cassandra.

Nombre de la métrica (excluido el dominio) Usar
/cassandra/process_max_fds Cantidad máxima de descriptores de archivos abiertos.
/cassandra/process_open_fds Abre los descriptores de archivos.
/cassandra/jvm_memory_pool_bytes_max Uso de memoria máximo de JVM para el grupo.
/cassandra/jvm_memory_pool_bytes_init Uso de memoria inicial de JVM para el grupo.
/cassandra/jvm_memory_bytes_max Uso máximo de memoria del montón de JVM.
/cassandra/process_cpu_seconds_total Tiempo de CPU del sistema y usuario de uso en segundos.
/cassandra/jvm_memory_bytes_used Uso de memoria de montón de JVM
/cassandra/compaction_pendingtasks Compactaciones pendientes para los SSTables de Cassandra Consulta Compactaciones para obtener más información.
/cassandra/jvm_memory_bytes_init Uso de memoria inicial del montón de JVM.
/cassandra/jvm_memory_pool_bytes_used Uso de memoria del grupo de JVM.
/cassandra/jvm_memory_pool_bytes_committed Uso de memoria de compromiso del grupo de JVM.
/cassandra/clientrequest_latency Latencia de solicitud de lectura en el rango del percentil 75 en microsegundos.
/cassandra/jvm_memory_bytes_committed Uso de memoria confirmado del montón de JVM.

Trabajar con métricas de Cassandra

Apigee recomienda que las siguientes métricas sean fundamentales para supervisar tu base de datos de Cassandra:

  • Tasa de solicitudes de Cassandra: Usa esta métrica para supervisar la tasa de solicitudes de lectura y escritura de Cassandra.
    Métrica: apigee.googleapis.com/cassandra/clientrequest_latency
    Etiquetas de recursos project_id, location, cluster_name, namespace_name, pod_name, container_name
    Etiquetas de métrica scope, unit

    Usa estas etiquetas para filtrar el recurso específico o agrupar.

    Para supervisar la tasa de las solicitudes de lectura de cassandra, aplica el siguiente filtro.

    Filtros: metric.scope == 'Read'
    metric.unit == 'OneMinuteRate'

    Para supervisar la tasa de solicitudes de escritura de Cassandra, aplica el siguiente filtro.

    Filtros: metric.scope == 'Write'
    metric.unit == 'OneMinuteRate'
  • Latencia de solicitudes de Cassandra: Usa esta métrica para supervisar la latencia de solicitudes de lectura y escritura de Cassandra. Esta es la misma métrica que la tasa de solicitudes, apigee.googleapis.com/cassandra/clientrequest_latency, con diferentes filtros aplicados.

    Para supervisar la latencia de las solicitudes de lectura de cassandra, aplica el siguiente filtro.

    Filtros: metric.scope == 'Read'
    metric.unit == '99thPercentile' o '95thPercentile' o '75thPercentile'

    Para supervisar la latencia de las solicitudes de escritura de Cassandra, aplica el siguiente filtro.

    Filtros: metric.scope == 'Write'
    metric.unit == '99thPercentile' o '95thPercentile' o '75thPercentile'
  • Uso de solicitudes de CPU de Pod de Cassandra
    Métrica: kubernetes.io/container/cpu/request_utilization (GKE on Google Cloud)
    kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)
    Etiquetas de recursos project_id, location, cluster_name, namespace_name, pod_name, container_name

    Usa estas etiquetas para filtrar el recurso específico o agrupar.

  • Uso del volumen de datos de Cassandra
    Métrica: kubernetes.io/pod/volume/utilization (GKE on Google Cloud)
    kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)
    Etiquetas de recursos project_id, location, cluster_name, namespace_name, pod_name
    Etiquetas de métrica volume_name

    Usa estas etiquetas para filtrar el recurso específico o agrupar.

Recomendaciones para escalar el clúster de Cassandra

Los siguientes lineamientos pueden servir para tomar la decisión de escalar tu clúster de Cassandra. En general, si las solicitudes de lectura o escritura muestran de forma constante una latencia del percentil 99 o si la latencia aumenta de forma continua y ves los aumentos correspondientes en el aumento de uso de la solicitud de CPU y las tasas de solicitudes de lectura o escritura, se puede considerar que tu clúster de Cassandra está bajo estrés. Recomendamos que aumentes la escala del clúster. Para obtener más información, consulta Escala Cassandra.

MétricaUmbralDuración del activador
kubernetes.io/pod/volume/utilization85%5 min
kubernetes.io/container/cpu/request_utilization85%3 min
Read request Latency 99thPercentile5 s3 min
Write request Latency 99thPercentile5 s3 min