Ver métricas

En este tema, se explica cómo ver las métricas híbridas de Apigee en un panel de Stackdriver.

Sobre Stackdriver

Para obtener más información sobre las métricas, los paneles y Stackdriver, consulta lo siguiente:

Habilita métricas híbridas

Antes de que las métricas híbridas se puedan enviar a Stackdriver, 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, el híbrido propaga automáticamente las métricas de Stackdriver. El prefijo del nombre de dominio de las métricas creadas por el híbrido 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 Stackdriver es:

apigee.googleapis.com/proxy/request_count

Stackdriver te permite filtrar y agrupar datos de métricas basadas en etiquetas. Algunas etiquetas están predefinidas, y otras se agregan de forma explícita mediante componentes híbridos. 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 Stackdriver:

Abre el Explorador de métricas de Monitoring en un navegador. Como alternativa, si ya estás en la consola de Stackdriver, selecciona Explorador de métricas.
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. Por ejemplo, busca proxy/latencies de la siguiente forma:
Selecciona la métrica deseada.
Aplica filtros. Las opciones de filtro para cada métrica se enumeran en Métricas disponibles. Por ejemplo, para la métrica proxy_latencies, las opciones de filtro son: org=org_name.
Stackdriver muestra el gráfico de la métrica seleccionada.
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. Stackdriver 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 Stackdriver y, luego, agregar gráficos para ver los datos de las métricas:

Abre el Explorador de métricas de Monitoring en un navegador y, luego, selecciona Paneles.
Selecciona + Crear panel.
Proporciona un nombre al panel. Por ejemplo: Tráfico de solicitud de proxy híbrido
Haz clic en Confirmar.
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. Stackdriver muestra los datos de 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
`/proxy/request_count`	`method`	La cantidad total de solicitudes de proxy de API recibidas.
`/proxy/response_count`	`method` `response_code`	La cantidad total de respuestas recibidas del proxy de API.
`/proxy/latencies`	`method`	Cantidad total de milisegundos que se tardó en responder a una llamada. Esta vez incluye la sobrecarga del proxy de la API de Apigee y el tiempo de servidor objetivo.
`/target/request_count`	`method` `target_type` `target_endpoint`	La cantidad total de solicitudes enviadas al destino del proxy.
`/target/response_count`	`method` `response_code` `target_type` `target_endpoint`	La cantidad total de respuestas recibidas del destino del proxy.
`/target/latencies`	`method` `response_code` `target_type` `target_endpoint`	Cantidad total de milisegundos que se tardó en responder a una llamada. Esta vez no incluye la sobrecarga del proxy de la API de Apigee.
`/policy/latencies`	`policy_name`	La cantidad total de milisegundos que necesitó esta política con nombre para ejecutarse.
`/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` indica que el agente está atrasado. `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.