Ver métricas

Estás viendo la versión 1.8 de la documentación de Apigee Hybrid. This version is end of life. You should upgrade to a newer version. Para obtener más información, consulta las Versiones compatibles.

Version 1.8 (unsupported)

   Versiones compatibles:

• v1.12 (más reciente)                        
• v1.11                         
• v1.10                                        
• Lista de versiones compatibles

   Versiones no compatibles

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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:

• Documentación del Explorador de métricas
• Introducción a las alertas
• Crea gráficos

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.

Nota: No se admiten métricas para la puerta de enlace de entrada de Apigee. Consulta Problemas conocidos.

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 /proxyv2/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/proxyv2/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.

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

El servicio Prometheus 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 y etiquetas que usa Prometheus. Estas etiquetas se usan en las entradas de registro de métricas.

Nombre de la métrica	Etiqueta	Usar
/proxyv2/request_count	method	La cantidad total de solicitudes de proxy de API recibidas.
/proxyv2/response_count	method response_code	La cantidad total de respuestas recibidas del proxy de API.
/proxyv2/latencies_percentile	method	Percentil de todas las respuestas de la política de la API a una solicitud.
/targetv2/request_count	method target_type target_endpoint	La cantidad total de solicitudes enviadas al destino del proxy.
/targetv2/response_count	method response_code target_type target_endpoint	La cantidad total de respuestas recibidas del destino del proxy.
/server/fault_count	source	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	state	La cantidad de sockets abiertos.
/server/num_threads		La cantidad de subprocesos activos que no son de daemon en el servidor.
/server/request_count	method type	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	method response_code type	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	method response_code type	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	method type	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	method response_code type	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	method response_code type	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

El servicio Prometheus recopila y procesa métricas (como se describe en la Descripción general de 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 y etiquetas que Prometheus usa en los datos de métricas de UDCA. Estas etiquetas se usan en las entradas de registro de métricas.

Nombre de la métrica	Etiqueta	Usar
/udca/server/local_file_oldest_ts	dataset state	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	dataset state	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	dataset state	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	dataset	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	dataset	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	service dataset response_code	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	service dataset	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	dataset	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	dataset	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	dataset state	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	dataset state	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	dataset	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

El servicio Prometheus 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 y etiquetas que Prometheus usa en los datos de métricas de Cassandra. Estas etiquetas se usan en las entradas de registro de métricas.

Nombre de la métrica (excluido el dominio)	Etiqueta	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	pool	Uso de memoria máximo de JVM para el grupo.
/cassandra/jvm_memory_pool_bytes_init	pol	Uso de memoria inicial de JVM para el grupo.
/cassandra/jvm_memory_bytes_max	area	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	area	Uso de memoria de montón de JVM
/cassandra/compaction_pendingtasks	unit	Compactaciones pendientes para los SSTables de Cassandra Consulta Compactaciones para obtener más información.
/cassandra/jvm_memory_bytes_init	area	Uso de memoria inicial del montón de JVM.
/cassandra/jvm_memory_pool_bytes_used	pool	Uso de memoria del grupo de JVM.
/cassandra/jvm_memory_pool_bytes_committed	pool	Uso de memoria de compromiso del grupo de JVM.
/cassandra/clientrequest_latency	scope unit	Latencia de solicitud de lectura en el rango del percentil 75 en microsegundos.
/cassandra/jvm_memory_bytes_committed	area	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
  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
  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étrica	Umbral	Duración del activador
kubernetes.io/pod/volume/utilization	85%	5 min
kubernetes.io/container/cpu/request_utilization	85%	3 min
Read request Latency 99thPercentile	5 s	3 min
Write request Latency 99thPercentile	5 s	3 min