Monitorización con Prometheus

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 para una implementación con servicio administrado del mismo patrón.

Los ejemplos usan 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.

Cómo Vantage expone métricas

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.

Requisitos previos

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.

Configurar Prometheus

Si tiene previsto ingerir métricas de OTLP (consulte 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:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

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

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:

helm install observability prometheus-community/kube-prometheus-stack \
  -n observability --create-namespace \
  -f observability-values.yaml

Comprueba que los pods se inicien:

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.

Configurar Prometheus para recopilar métricas de Vantage

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

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.

mTLS de Linkerd

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:

Habilite la inyección de Linkerd para el espacio de nombres observability para que Prometheus participe en la malla de servicio.
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 para ver las consultas de inspección y las comprobaciones de preparación.

Istio mTLS

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:

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):

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:

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. A continuación, instale el chart vantage-selfhosted para configurar los ServiceMonitor de modo que usen estos certificados:

# 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

Compruebe que las métricas se estén enviando

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

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:

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:

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.

Acceso a Grafana

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.

Métricas disponibles

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 para ver el catálogo completo.

Ingestión de OTLP

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.

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:

http://observability-kube-prometheus-prometheus.observability:9090/api/v1/otlp/v1/metrics

Configuration

Lifecycle

Monitoring

Performance

Diagnostics

Migration

Cómo Vantage expone métricas

Requisitos previos

Configurar Prometheus

Configurar Prometheus para recopilar métricas de Vantage

mTLS de Linkerd

Istio mTLS

Compruebe que las métricas se estén enviando

Acceso a Grafana

Métricas disponibles

Ingestión de OTLP

​Cómo Vantage expone métricas

​Requisitos previos

​Configurar Prometheus

​Configurar Prometheus para recopilar métricas de Vantage

​mTLS de Linkerd

​Istio mTLS

​Compruebe que las métricas se estén enviando

​Acceso a Grafana

​Métricas disponibles

​Ingestión de OTLP

Cómo Vantage expone métricas

Requisitos previos

Configurar Prometheus

Configurar Prometheus para recopilar métricas de Vantage

mTLS de Linkerd

Istio mTLS

Compruebe que las métricas se estén enviando

Acceso a Grafana

Métricas disponibles

Ingestión de OTLP