Directrices de monitorización de clústeres

Información general

En esta guía se ofrecen directrices sobre qué y cómo monitorizar un despliegue de Apigee Hybrid. Está dirigido a administradores de clústeres híbridos y administradores de organizaciones.

Si no tienes experiencia con la monitorización de Google Cloud, consulta la documentación de Google Cloud Monitoring para obtener información sobre cómo crear gráficos con el Explorador de métricas y cómo funcionan las alertas.

Los clústeres de Apigee Hybrid proporcionan métricas de indicadores de nivel de servicio (SLIs) para ayudarte a entender el rendimiento de los servicios de aplicaciones y del sistema en cualquier momento. Puede consultar una lista completa de las métricas disponibles.

Google Cloud Monitoring usa el tipo de recurso para identificar cada métrica de SLI. Hay tres tipos de recursos comunes que se usan en todas las métricas de Apigee Hybrid.

  • k8s_container para métricas a nivel de sistema.
  • Proxy de las métricas de proxy de API de Apigee.
  • Target para las métricas de destino de la API de Apigee

Los tipos de recursos tienen etiquetas comunes que se aplican a todas las métricas asociadas. Por ejemplo, todas las métricas con el tipo de recurso k8s_container tienen las etiquetas cluster_name, pod_name y container_name disponibles, además de las etiquetas de métricas. Se debe usar una combinación de etiquetas de tipo de recurso y de métricas para monitorizar de forma eficaz el estado y el rendimiento de los clústeres.

Umbral de alerta: en un mundo perfecto, los umbrales de alerta serían obvios y la documentación proporcionada incluiría los valores que deberían activar las alertas. En realidad, para Apigee es menos obvio definir qué es un rendimiento aceptable y qué es una utilización peligrosa de los recursos de los servicios y las infraestructuras. Los valores de umbral de las alertas variarán considerablemente en función de los patrones de tráfico concretos y de los acuerdos de nivel de servicio.

La optimización y la determinación de los umbrales de alerta son procesos continuos, ya que pueden cambiar en función del uso del servicio y de la infraestructura. Usa los umbrales de advertencia y crítico para las notificaciones y las alertas.

  • Correcto: el valor es inferior al umbral de advertencia.
  • Concerning (Preocupante): el valor es superior al umbral de advertencia, pero inferior al umbral crítico.
  • Crítico: el valor es superior al umbral crítico.

Los clientes deben usar las herramientas proporcionadas para determinar el umbral óptimo, ya sean los paneles de Cloud Monitoring que pueden crear con el lenguaje PromQL que se indica más abajo o las analíticas de Apigee, para identificar qué aspecto tiene la situación "normal" y, a continuación, ajustar los umbrales de las alertas en consecuencia.

La monitorización de clústeres híbridos se puede clasificar en cuatro grupos generales diferentes. Por ejemplo, la monitorización de tráfico, bases de datos, plano de control de Apigee e infraestructura. En las siguientes secciones se describen estos grupos en detalle:

Tráfico

Las métricas de SLI de proxy y de destino de Apigee proporcionan recuentos de solicitudes y respuestas, así como latencias de proxies y destinos de API. La métrica SLI de latencia de la política de Apigee proporciona latencias de respuesta de la política. Estas métricas de SLI proporcionan cobertura para monitorizar el tráfico de las APIs de Apigee.

Tasa de solicitudes

Número de solicitudes de proxy

Caso práctico: usa proxy/request_count para monitorizar el número de solicitudes de proxy. El gráfico proxy/request_count muestra la tasa de solicitudes de los proxies. Este gráfico es útil para identificar qué proxy recibe una tasa de solicitudes más alta, los patrones de la tasa de solicitudes y cualquier pico anormal en las llamadas de solicitudes de un proxy concreto. Cualquier pico anormal inesperado en el tráfico de las APIs podría ser un problema de seguridad relacionado con un bot o un ataque a los proxies de las APIs. Del mismo modo, una gran caída en el tráfico general puede indicar problemas con los clientes o con la conectividad de los componentes upstream de Apigee.

Tipos de recursos Proxy
Métrica proxy/request_count
Agrupar por method y todas las etiquetas de tipo de recurso Proxy
Agregador suma
Consideración de las alertas Eventos como las alertas de picos o descensos anómalos de request_count
Umbral de alerta Ninguno
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method) (
 rate({"apigee.googleapis.com/proxy/request_count", monitored_resource="apigee.googleapis.com/Proxy"}[1m])
)

Número de solicitudes de destino

Caso práctico: usa target/request_count para monitorizar el número de solicitudes de destino del tiempo de ejecución de Apigee. El gráfico target/request_count muestra la tasa de solicitudes recibidas por el destino de Apigee. Este gráfico puede ser útil para ver qué objetivo tiene una tasa de solicitudes más alta, el patrón de la tasa de solicitudes y cualquier pico anormal en las llamadas de solicitudes de un objetivo concreto.

Tipos de recursos Objetivo
Métrica target/request_count
Agrupar por method y todas las etiquetas de tipo de recurso Target
Agregador suma
Consideración de las alertas Eventos como las alertas de picos o descensos anómalos de request_count
Umbral de alerta Ninguno
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method, type, endpoint) (
 rate({"apigee.googleapis.com/target/request_count", monitored_resource="apigee.googleapis.com/Target"}[1m])
)

Tasa de errores

Recuento de respuestas de error de proxy

Caso práctico: usa proxy/response_count para monitorizar la tasa de respuestas de error del proxy. El gráfico proxy/response_count muestra la tasa de solicitudes del proxy de API. Este gráfico es útil para saber qué proxy tiene una tasa de errores de solicitud más alta o cualquier pico de error anormal en las llamadas de solicitud de un proxy concreto.

Tipos de recursos Proxy
Métrica proxy/response_count
Filtrar por response_code != 200
Agrupar por method, response_code, fault_code, fault_source, apigee_fault, y todas las etiquetas de tipo de recurso Proxy
Agregador suma
Consideración de las alertas La proporción de errores de respuesta del proxy: Total de errores de respuesta/Total de respuestas.
  • Total de errores de respuesta = Suma de proxy/response_count con el filtro response_code != 200
  • Número total de respuestas = Suma de proxy/response_count
Umbral de alerta Depende del SLO de la instalación. Las instalaciones de producción y no de producción pueden tener umbrales diferentes. Por ejemplo, en producción, activa una notificación de evento si la proporción de errores 500 de respuesta del proxy es del 5% durante 5 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method, response_code, fault_code, fault_source, apigee_fault) (
 rate({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy", response_code!="200"}[1m])
)
Ejemplo de PromQL de una política de alertas de operaciones de Google Cloud: 
100 * (
 sum by (method, org, apigee_fault, location, resource_container, env, proxy_name, fault_code, fault_source) ({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy", response_code="500"})
/
 sum by (method, org, apigee_fault, location, resource_container, env, proxy_name, fault_code, fault_source) ({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy"})
) > 5

Número de respuestas de error de destino

Caso práctico: usa target/response_count para monitorizar la tasa de respuesta de error de Target de la API. El gráfico target/response_count muestra la tasa de solicitudes de API Target. Este gráfico puede ser útil para identificar qué destino está recibiendo una tasa de solicitudes más alta o cualquier pico de errores anormal en las llamadas de solicitud.

Tipos de recursos Objetivo
Métrica target/response_count
Filtrar por response_code != 200
Agrupar por method y todas las etiquetas de tipo de recurso Target
Agregador suma
Consideración de las alertas Por ejemplo, la proporción de errores de respuesta de proxy: Número total de errores de respuesta/Número total de respuestas.
  • Total de errores de respuesta = Suma de target/response_count con el filtro response_code != 200
  • Número total de respuestas = Suma de target/response_count
Umbral de alerta Depende del SLO de la instalación. Por ejemplo, para producción, activa una notificación de evento si la proporción de errores de respuesta de destino es del 5% durante 3 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method, type, endpoint, response_code) (
 rate({"apigee.googleapis.com/target/response_count", monitored_resource="apigee.googleapis.com/Target", response_code!="200"}[1m])
)

Latencias

Latencias de proxy

Caso práctico: usa proxy/latencies para monitorizar las latencias de todas las respuestas de los proxies de API a una solicitud. El gráfico de latencias de proxy puede ser útil para identificar la latencia del proxy de API de Apigee en la latencia general de las solicitudes del proxy de API.

Tipos de recursos Proxy
Métrica proxy/latencies
Agrupar por method y todas las etiquetas de tipo de recurso Proxy
Agregador p99 (percentil 99)
Consideración de las alertas Valor alto del percentil de latencia p99.
Umbral de alerta Depende del SLO de la instalación. Por ejemplo, para producción, activa una notificación de evento si el valor del percentil 99 de latencia del proxy es de 5 segundos durante 5 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
histogram_quantile(
 0.99,
 sum by (le, method) (
   rate({"apigee.googleapis.com/proxy/latencies/bucket", monitored_resource="apigee.googleapis.com/Proxy"}[1m])
 )
)

Latencias objetivo

Caso práctico: usa target/latencies para monitorizar las latencias de todas las respuestas de destino del proxy de API a una solicitud. El gráfico de latencias de destino identifica el tiempo total que tarda el destino del proxy de API de Apigee en responder a una solicitud. Este valor no incluye la sobrecarga del proxy de API de Apigee.

Tipos de recursos Objetivo
Métrica target/latencies
Agrupar por Método, percentil y todas las etiquetas de tipo de recurso Target
Agregador p99 (percentil 99)
Consideración de las alertas Valor alto del percentil de latencia p99.
Umbral de alerta Depende del SLO de la instalación. Por ejemplo, en producción, activa una notificación de evento si el valor del percentil 99 de latencia de destino es de 5 segundos durante 5 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
histogram_quantile(
  0.99,
  sum by (le, method) (
    rate({"apigee.googleapis.com/target/latencies/bucket", monitored_resource="apigee.googleapis.com/Target"}[1m])
  )
)

Base de datos

Cassandra

El servicio de base de datos de Apigee Cassandra tiene varias métricas de SLI de Cassandra. Estas métricas de SLI pueden proporcionar una monitorización completa del servicio Apigee Cassandra. Como mínimo, junto con el uso de recursos de Cassandra (CPU, memoria y volumen de disco), se debe monitorizar la latencia de las solicitudes de lectura y escritura del cliente para comprobar el estado del servicio de Cassandra.

Tasa de solicitudes de lectura de Cassandra

Caso práctico: la métrica de SLI cassandra/clientrequest_rate (con scope=Read) proporciona información valiosa sobre la tasa media de solicitudes de lectura de los servicios de Cassandra en cualquier momento. Esta métrica ayuda a comprender las tendencias del nivel de actividad de las solicitudes de lectura de los clientes.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_rate
Filtrar por scope = Read y unit = OneMinuteRate
Agrupar por scope, unit y todas las etiquetas de tipo de recurso k8s_container
Agregador suma
Consideración de las alertas Si se detectan problemas o cambios significativos en los patrones de consulta de los clientes; por ejemplo, un aumento o una disminución repentinos e inesperados de la tasa de solicitudes de lectura.
Umbral de alerta Ninguno
Consulta PromQL del panel de Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Read",
   unit="OneMinuteRate"
 }[1m])
)

Tasa de solicitudes de escritura de Cassandra

Caso práctico: la métrica de SLI cassandra/clientrequest_rate (con scope=Write) proporciona información valiosa sobre la tasa media de solicitudes de escritura de los servicios de Cassandra en cualquier momento. Esta métrica ayuda a comprender las tendencias del nivel de actividad de las solicitudes de escritura de los clientes.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_rate
Filtrar por scope = Read y unit = OneMinuteRate
Agrupar por scope, unit y todas las etiquetas de tipo de recurso k8s_container
Agregador suma
Consideración de las alertas Si se detectan problemas o cambios significativos en los patrones de consulta de los clientes, como un aumento o una disminución repentinos e inesperados de las solicitudes de escritura que requieran una investigación más a fondo.
Umbral de alerta Ninguno
Consulta PromQL del panel de Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Write",
   unit="OneMinuteRate"
 }[1m])
)

Latencia de las solicitudes de lectura de Cassandra

Caso de uso: la métrica SLI cassandra/clientrequest_latency (con scope=Read) proporciona la latencia de las solicitudes de lectura de los servicios de Cassandra (en los percentiles 99, 95 o 75). Estas métricas ayudan a obtener una visión general del rendimiento de Cassandra y pueden indicar cualquier cambio en los patrones de uso o un problema que se manifieste con el tiempo.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_latency
Filtrar por scope = Read y unit = 99thPercentile
Agrupar por scope, unit y todas las etiquetas de tipo de recurso k8s_container
Agregador suma
Consideración de las alertas Si el SLI de latencia de las solicitudes de lectura muestra constantemente que la latencia del percentil 99 tiende al alza de forma continua.
Umbral de alerta Depende del SLO de los servicios de Cassandra. Por ejemplo, en producción, activa una notificación de evento si el valor de lectura clientrequest_latency del percentil 99 es de 5 segundos durante 3 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Read",
   unit="99thPercentile"
 }[1m])
)

Latencia de solicitudes de escritura de Cassandra

Caso práctico: la métrica SLI cassandra/clientrequest_latency (con scope=Write) proporciona la latencia de las solicitudes de escritura de los servicios de Cassandra (en los percentiles 99, 95 o 75). Estas métricas ayudan a obtener una visión general del rendimiento de Cassandra y pueden indicar cualquier cambio en los patrones de uso o un problema que se manifieste con el tiempo.

Tipos de recursos k8s_container
Métrica cassandra/clientrequest_latency
Filtrar por scope = Write y unit = 99thPercentile
Agrupar por scope, unit y todas las etiquetas de tipo de recurso k8s_container
Agregador suma
Consideración de las alertas Si el SLI de latencia de solicitudes de escritura muestra de forma constante que la latencia del percentil 99 tiende a aumentar continuamente.
Umbral de alerta Depende del SLO de los servicios de Cassandra. Por ejemplo, en producción, activa una notificación de evento si el valor de escritura clientrequest_latency del percentil 99 es de 5 segundos durante 3 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Write",
   unit="99thPercentile"
 }[1m])
)

Plano de control de Apigee

Las métricas de SLI del servicio Sincronizador de Apigee proporcionan recuentos de solicitudes y respuestas, así como latencias entre el plano de control de Apigee y el plano de tiempo de ejecución de Hybrid. Se espera que las instancias de sincronizador que se ejecutan en el plano de tiempo de ejecución sondeen el plano de control con regularidad, descarguen los contratos y los pongan a disposición de las instancias de tiempo de ejecución locales.

Frecuencia de solicitudes

Número de solicitudes de upstream

Caso práctico: Las métricas upstream/request_count indican el número de solicitudes realizadas por el servicio Synchronizer al plano de control de Apigee.

Tipos de recursos k8s_container
Métrica upstream/request_count
Filtrar por container_name = apigee-synchronizer y type = CONTRACT
Agrupar por method, type, container_name y todas las etiquetas del tipo de recurso k8s_container.
Agregador suma
Consideración de las alertas Úsalo para detectar anomalías en el tráfico, como un pico anormal en request_count o una alerta de descenso.
Umbral de alerta Ninguno
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method, type, container_name) (
 rate({"apigee.googleapis.com/upstream/request_count",
   monitored_resource="k8s_container",
   container_name="apigee-synchronizer",
   type="CONTRACT"
 }[1m])
)

Porcentaje de errores

Recuento de respuestas de la fuente original

Caso práctico: la métrica de SLI upstream/response_count proporciona el número de respuestas que los servicios de sincronizador han recibido del plano de control de Apigee. Este gráfico puede ser útil para identificar cualquier problema de conectividad o configuración entre el plano de ejecución de Apigee Hybrid y el plano de control.

Tipos de recursos k8s_container
Métrica upstream/request_count
Filtrar por method, response_type, container_name y todas las etiquetas del tipo de recurso k8s_container.
Agrupar por
Agregador suma
Consideración de las alertas Si hay errores en las métricas upstream/response_count con códigos de respuesta distintos de 200 devueltos por el plano de control de Apigee, es necesario investigar más a fondo esos errores.
Umbral de alerta Depende del SLO de los servicios de Cassandra. Por ejemplo, en producción, activa una notificación de evento si Synchronizer experimenta más de un error response_code cada tres minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (method, response_code, type, container_name) (
 rate({"apigee.googleapis.com/upstream/response_count",
   monitored_resource="k8s_container",
   container_name="apigee-synchronizer",
   response_code!="200"
   type="CONTRACT"
 }[1m])
)

Infraestructura

GKE y otras plataformas de Kubernetes proporcionan métricas de SLI a nivel de sistema. Las etiquetas de métricas de SLI se pueden filtrar y agrupar para monitorizar un contenedor específico y su uso de recursos. Para monitorizar el estado y la disponibilidad de la infraestructura del clúster de Apigee Runtime, un administrador del clúster puede monitorizar el uso de recursos comunes de contenedores y pods, como la CPU, la memoria, el disco y el número de reinicios de contenedores. Para obtener más información sobre las métricas y las etiquetas disponibles, consulta la documentación de GKE.

En la siguiente tabla se enumeran algunos de los servicios y los contenedores que puedes monitorizar en cada servicio.

Nombre del servicio Nombre del contenedor
Cassandra apigee-cassandra
Procesador de mensajes(MP) apigee-runtime
Sincronizador apigee-synchronizer
Telemetría apigee-prometheus-app
apigee-prometheus-proxy
apigee-prometheus-agg
apigee-stackdriver-exporter

Contenedores o pods

Número de reinicios

Caso práctico: La métrica SLI del sistema kubernetes.io/container/restart_count proporciona el número de veces que se ha reiniciado un contenedor. Este gráfico puede ser útil para identificar si un contenedor falla o se reinicia con frecuencia. El contenedor de servicio específico se puede filtrar por etiquetas de métricas para monitorizar el contenedor de un servicio concreto.

A continuación, se muestra cómo usar la métrica kubernetes.io/container/restart_count para el contenedor de Cassandra. Puede usar esta métrica en cualquiera de los contenedores de la tabla anterior.

Tipos de recursos k8s_container
Métrica kubernetes.io/container/restart_count
Filtrar por namespace_name = apigee y container_name =~ .*cassandra.*
Agrupar por cluster_name, namespace_name, pod_name, container_name y todas las etiquetas del tipo de recurso k8s_container
Agregador suma
Consideración de las alertas Si un contenedor se reinicia con frecuencia, es necesario investigar más a fondo la causa raíz. Un contenedor puede reiniciarse por varios motivos, como OOMKilled, que el disco de datos esté lleno o que haya problemas de configuración, entre otros.
Umbral de alerta Depende del SLO de la instalación. Por ejemplo, para producción, activa una notificación de evento si un contenedor se reinicia más de 5 veces en 30 minutos.
Consulta PromQL del panel de Cloud Monitoring: 
sum by (cluster_name, namespace_name, pod_name, container_name) (
 rate({"kubernetes.io/container/restart_count",
   monitored_resource="k8s_container",
   container_name=~".*cassandra.*",
   namespace_name="apigee"
 }[1m])
)