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

# Monitorización con Prometheus

> Recopile métricas de Vantage 3.0 autoalojado con Prometheus en mallas de servicio de Istio y Linkerd.

Esta guía configura una instancia autogestionada de Prometheus para recopilar métricas de Vantage 3.0 autoalojado en cualquier entorno. En AKS, donde Azure Monitor Workspace y Azure Managed Grafana están disponibles, consulte [Azure Managed Monitoring](/es/vantage/self-hosted/v3.0/monitoring/azure-managed) para una implementación con servicio administrado del mismo patrón.

<Note>
  Los ejemplos usan [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), pero el enfoque es genérico y se aplica a cualquier implementación de Prometheus. Para conocer las restricciones específicas de cada mesh, consulte [Monitoring Overview](/es/vantage/self-hosted/v3.0/monitoring/overview).
</Note>

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

Los pods de la aplicación Vantage están instrumentados con 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 `abbyy.platform.metrics.text.endpoint: "1"` y asignan un puerto del servicio (normalmente, el 80) al puerto del contenedor con el nombre de puerto `http`. Prometheus detecta estos servicios y recopila sus métricas mediante un `ServiceMonitor`; no se necesita un OpenTelemetry Collector independiente para la recopilación de métricas.

Para consultar el concepto completo y las restricciones de la malla de servicios, consulte [Monitoring Overview](/es/vantage/self-hosted/v3.0/monitoring/overview).

<div id="prerequisites">
  ## Requisitos previos
</div>

* Una instalación de Vantage en funcionamiento (operador y cargas de trabajo desplegados).
* Helm 3.
* Acceso al clúster mediante `kubectl`.
* Si KEDA está habilitado, una instancia de Prometheus accesible en `prometheus-operated.observability.svc.cluster.local:9090`.

<div id="configure-prometheus">
  ## Configurar Prometheus
</div>

Si tiene previsto ingerir métricas de OTLP (consulte [OTLP ingestion](#otlp-ingestion)), habilite la función `otlp-write-receiver` y pase el argumento `--web.enable-otlp-receiver` a la instancia de Prometheus.

Añada el repositorio de Helm:

```bash theme={null}
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
```

Cree un archivo de valores (`observability-values.yaml`):

```yaml theme={null}
prometheus:
  prometheusSpec:
    enableFeatures:
      - otlp-write-receiver
    additionalArgs:
      - name: web.enable-otlp-receiver
        value: ""
    retention: 15d
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    resources:
      requests:
        cpu: 500m
        memory: 2Gi
      limits:
        cpu: "2"
        memory: 4Gi
grafana:
  enabled: true
  adminPassword: "changeme"  # Reemplazar en producción
  persistence:
    enabled: true
    size: 10Gi
alertmanager:
  enabled: false
nodeExporter:
  enabled: true
kube-state-metrics:
  enabled: true
# Kubernetes administrado (p. ej., AKS, EKS, GKE) no expone los endpoints del plano de control.
# Deshabilitar estos para evitar errores de scrape.
kubeApiServer:
  enabled: false
kubeControllerManager:
  enabled: false
kubeScheduler:
  enabled: false
kubeEtcd:
  enabled: false
kubeProxy:
  enabled: false
```

Instalar:

```bash theme={null}
helm install observability prometheus-community/kube-prometheus-stack \
  -n observability --create-namespace \
  -f observability-values.yaml
```

Comprueba que los pods se inicien:

```bash theme={null}
kubectl get pods -n observability
```

Debería ver en ejecución los pods de Prometheus, Grafana, el operador, kube-state-metrics y node-exporter. Node-exporter se ejecuta como un DaemonSet; es normal que haya pods pendientes si el número de nodos aún está aumentando.

<div id="configure-prometheus-to-scrape-vantage">
  ## Configurar Prometheus para recopilar métricas de Vantage
</div>

El chart `vantage-selfhosted` puede crear los objetos `ServiceMonitor` necesarios para supervisar Vantage:

```bash theme={null}
helm upgrade --install abbyy-vantage \
  # ...
  --set observability.prometheus.serviceMonitor.create=true
```

Consulte la documentación del chart para conocer más opciones.

La clave `observability` está en el nivel superior y no debe anidarse en `vantage`.

<div id="linkerd-mtls">
  ## mTLS de Linkerd
</div>

Con la política permisiva predeterminada de Linkerd, Prometheus normalmente puede recopilar las métricas de los endpoints de Vantage con proxy de Linkerd mediante texto sin cifrar. Instale Prometheus en el espacio de nombres `observability`, habilite el `ServiceMonitor` de Vantage y confirme que todos los destinos de Vantage aparezcan como `UP`.

Si una política estricta de autorización de Linkerd bloquea la recopilación, use uno de estos enfoques:

1. Habilite la inyección de Linkerd para el espacio de nombres `observability` para que Prometheus participe en la malla de servicio.
2. Configure `observability.prometheus.serviceMonitor.scheme: https` y un `tlsConfig` que haga referencia a los certificados de cliente que su configuración de Linkerd pone a disposición de Prometheus.

No habilite KEDA hasta que Prometheus devuelva valores actualizados para las métricas de Vantage utilizadas por los recursos `ScaledObject`. Consulte [Escalado automático con KEDA](/es/vantage/self-hosted/v3.0/performance/autoscaling) para ver las consultas de inspección y las comprobaciones de preparación.

<div id="istio-mtls">
  ## Istio mTLS
</div>

Cuando Vantage se despliega en una malla de servicio de Istio con mTLS STRICT (lo predeterminado cuando `ingress.enabled` es `true` y `ingress.type` es `istio`), Prometheus y `ServiceMonitor` deben configurarse para recopilar métricas de los endpoints mediante mTLS, porque Prometheus usa directamente las IP de los pods en lugar del nombre del servicio.

Configure los pods de Prometheus con las siguientes anotaciones:

```yaml theme={null}
annotations:
  proxy.istio.io/config: |
    proxyMetadata:
      OUTPUT_CERTS: /etc/istio-output-certs
  sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
```

y los siguientes `volume` y `volumeMount` (los nombres y las rutas se pueden personalizar; en los ejemplos a continuación se usan estos):

```yaml theme={null}
volumes:
  - name: istio-certs
    emptyDir:
      medium: Memory
volumeMounts:
  - name: istio-certs
    mountPath: /etc/prom-certs/
    readOnly: true
```

Con kube-prometheus-stack, esto puede hacerse con los siguientes valores:

```yaml theme={null}
prometheus:
  prometheusSpec:
    podMetadata:
      annotations:
        # forzar a Istio a generar certificados en un directorio de volumen local
        "proxy.istio.io/config": |
          proxyMetadata:
            OUTPUT_CERTS: /etc/istio-output-certs
        "sidecar.istio.io/userVolumeMount": '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]'
    # volumen compartido donde Istio escribirá los certificados
    volumes:
      - name: istio-certs
        emptyDir: {}
    volumeMounts:
      - name: istio-certs
        mountPath: /etc/prom-certs
```

Como alternativa, consulte la [documentación oficial de Istio](https://istio.io/latest/docs/ops/integrations/prometheus/#tls-settings).

A continuación, instale el chart `vantage-selfhosted` para configurar los `ServiceMonitor` de modo que usen estos certificados:

```yaml theme={null}
# values.vantage-selfhosted.yaml
observability:
  prometheus:
    serviceMonitor:
      scheme: https
      tlsConfig:
        caFile: /etc/prom-certs/root-cert.pem
        certFile: /etc/prom-certs/cert-chain.pem
        keyFile: /etc/prom-certs/key.pem
        insecureSkipVerify: true  # Prometheus no admite la nomenclatura de seguridad de Istio, por lo que se omite la verificación del certificado del pod de destino
```

<div id="verify-metrics-are-flowing">
  ## Compruebe que las métricas se estén enviando
</div>

Configure el reenvío de puertos hacia la UI de Prometheus:

```bash theme={null}
kubectl port-forward -n observability svc/observability-kube-prometheus-prometheus 9090:9090
```

Comprueba que se detecten los destinos de Vantage y que estén en buen estado:

```bash theme={null}
curl -s http://localhost:9090/api/v1/targets \
  | jq '[.data.activeTargets[] | select(.scrapePool // "" | contains("vantage"))] | group_by(.health) | map({health: .[0].health, count: length})'
```

Consulta una métrica de una aplicación de Vantage:

```bash theme={null}
curl -s "http://localhost:9090/api/v1/query?query=process_cpu_count" \
  | jq '.data.result | length'
```

Un resultado distinto de cero confirma que las métricas se están recopilando. También puede consultar los objetivos en `http://localhost:9090/targets` para ver el estado de recopilación de cada uno.

<div id="access-grafana">
  ## Acceso a Grafana
</div>

```bash theme={null}
kubectl port-forward -n observability svc/observability-grafana 3000:80
```

Abra `http://localhost:3000`. Las credenciales predeterminadas son `admin` / la contraseña establecida en el archivo de valores. Prometheus está preconfigurado como fuente de datos.

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

Las aplicaciones de Vantage exponen métricas de proceso, de cliente y servidor HTTP, y de la plataforma ABBYY a través del SDK de OpenTelemetry, todas etiquetadas con `service`, `pod`, `namespace` y `otel_scope_name`. Consulte [Métricas disponibles](/es/vantage/self-hosted/v3.0/monitoring/overview#available-metrics) para ver el catálogo completo.

<div id="otlp-ingestion">
  ## Ingestión de OTLP
</div>

<Note>
  La ingestión de OTLP se realiza mediante push y es independiente del flujo `ServiceMonitor` basado en `scrape` descrito arriba. Úsela solo para servicios que envían métricas de OpenTelemetry por push, en lugar de exponer un endpoint de `scrape`.
</Note>

Cuando Prometheus está configurado con el receptor OTLP habilitado (`--web.enable-otlp-receiver`), cualquier servicio que envíe métricas OTLP a través de HTTP puede enviarlas a:

```text theme={null}
http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics
```