Saltar al contenido principal
Vantage 3.0 autoalojado se ejecuta dentro de una malla de servicios con mTLS para el tráfico de la aplicación. La configuración de recopilación de métricas depende de si la implementación usa Istio o Linkerd.

​
Cómo Vantage expone las métricas

Los pods de la aplicación Vantage están instrumentados con los SDK de OpenTelemetry y exponen métricas en formato Prometheus en /metrics-text, en el puerto 8080 del contenedor. Los servicios que exponen este endpoint llevan la etiqueta:
Cada servicio asigna el puerto 80 al 8080 y usa http como nombre de puerto. Prometheus detecta y recopila métricas de estos servicios mediante un ServiceMonitor que selecciona esa etiqueta.

​
Consideraciones sobre la malla de servicios

​
Istio

El tráfico de la aplicación en el puerto 8080 es interceptado por el sidecar de Envoy y está sujeto a mTLS STRICT. Cualquier recopilador que quiera leer esas métricas debe presentar un certificado de cliente mTLS válido a los pods de destino. Inyectar un sidecar de Istio en el recopilador no basta por sí solo: los objetivos de recopilación de métricas de Prometheus se resuelven en la IP del pod y el puerto del contenedor, que el sidecar de Envoy no puede enrutar, por lo que todas las recopilaciones de métricas fallan con HTTP 503. En la configuración funcional documentada, Prometheus se ejecuta dentro de la malla con un sidecar de Istio que exporta los certificados de la malla a un volumen compartido (OUTPUT_CERTS), y el propio Prometheus presenta esos certificados al recopilar métricas mediante scheme: https, con las rutas de los certificados configuradas en tlsConfig de ServiceMonitor. Esto descarta los recopiladores que se ejecutan fuera de la malla, incluido el agente ama-metrics que Azure incluye con su oferta de Prometheus administrado. Para recopilar métricas de la aplicación Vantage en AKS, se despliega una instancia de Prometheus dentro de la malla que recopila métricas de Vantage mediante mTLS y usa remote-write a Azure Monitor.

​
Linkerd

La política permisiva predeterminada de Linkerd normalmente permite que un Prometheus fuera de la malla recopile métricas de los endpoints de métricas de Vantage con proxy a través de texto sin cifrar. Confirma que cada destino de Vantage esté UP antes de habilitar KEDA. Si tu política de autorización de Linkerd requiere tráfico de malla autenticado, inyecta el namespace observability en la malla o configura Prometheus y el ServiceMonitor con los certificados de cliente que requiere tu política. El requisito es que Prometheus pueda recopilar métricas correctamente de /metrics-text; Vantage no requiere un método específico de implementación de Prometheus.

Monitoreo con Prometheus

Prometheus autogestionado (kube-prometheus-stack) que funciona en cualquier entorno, con rutas de configuración para Istio y Linkerd.

Monitoreo administrado de Azure

Azure Monitor Workspace + Azure Managed Grafana, con un Prometheus en la malla que recopila métricas de Vantage mediante mTLS y las envía a Azure Monitor con remote-write. El agente ama-metrics sigue encargándose de las métricas de infraestructura de Kubernetes.

​
Métricas disponibles

Las aplicaciones de Vantage exponen tres categorías de métricas a través del SDK de OpenTelemetry:
  • Métricas de proceso: process_cpu_count, process_memory_usage_bytes, process_cpu_time_seconds_total, process_thread_count. Uso de recursos en tiempo de ejecución por pod.
  • Métricas de cliente/servidor HTTP: http_client_active_requests, http_client_connection_duration_seconds, etc. Latencia de las solicitudes y seguimiento de conexiones.
  • Métricas de la plataforma ABBYY: abbyy_platform_listener_*, abbyy_platform_redisstreamscontroller_*. Métricas de procesamiento y de cola a nivel de la aplicación.
Todas las métricas incluyen etiquetas para service, pod, namespace y otel_scope_name.