> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Resumen de la supervisión

> Cómo funciona la supervisión de Vantage 3.0 autoalojado en las mallas de servicios Istio y Linkerd.

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.

<div id="how-vantage-exposes-metrics">
  ## Cómo Vantage expone las métricas
</div>

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:

```text theme={null}
abbyy.platform.metrics.text.endpoint: "1"
```

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.

<div id="service-mesh-considerations">
  ## Consideraciones sobre la malla de servicios
</div>

<div id="istio">
  ### Istio
</div>

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.

<div id="linkerd">
  ### Linkerd
</div>

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.

<div id="recommended-approach">
  ## Enfoque recomendado
</div>

<CardGroup cols={2}>
  <Card title="Monitoreo con Prometheus" icon="chart-line" href="/es/vantage/self-hosted/v3.0/monitoring/prometheus">
    Prometheus autogestionado (kube-prometheus-stack) que funciona en cualquier entorno, con rutas de configuración para Istio y Linkerd.
  </Card>

  <Card title="Monitoreo administrado de Azure" icon="cloud" href="/es/vantage/self-hosted/v3.0/monitoring/azure-managed">
    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.
  </Card>
</CardGroup>

<div id="available-metrics">
  ## Métricas disponibles
</div>

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`.