Configuración de los registros y las métricas locales para la puerta de enlace autohospedada de Azure API Management

Artículo
06/24/2024

SE APLICA A: Desarrollador | Premium

En este artículo se proporcionan detalles para configurar los registros y las métricas locales para la puerta de enlace autohospedada implementada en un clúster de Kubernetes. Para configurar los registros y las métricas en la nube, consulte este artículo.

Métricas

La puerta de enlace autohospedada admite StatsD que se ha convertido en un protocolo de unificación para la recopilación y agregación de métricas. En esta sección se describen los pasos para implementar StatsD en Kubernetes, configurar la puerta de enlace para emitir métricas mediante StatsD y usar Prometheus para supervisar las métricas.

Implementación de StatsD y Prometheus en el clúster

La siguiente configuración de YAML de ejemplo implementa StatsD y Prometheus en el clúster de Kubernetes donde se implementa una puerta de enlace autohospedada. También crea un servicio para cada uno de ellos. La puerta de enlace autohospedada publica después las métricas en el servicio StatsD. Accederemos al panel de Prometheus a través de su servicio.

Nota:

En el ejemplo siguiente se extrae una imagen de contenedor público de Docker Hub. Se recomienda configurar un secreto de extracción para autenticarse mediante una cuenta de Docker Hub en lugar de realizar una solicitud de extracción anónima. Para mejorar la confiabilidad al trabajar con contenido público, importe y administre la imagen en un registro de contenedor privado de Azure. Más información sobre cómo trabajar con imágenes públicas.

apiVersion: v1
kind: ConfigMap
metadata:
  name: sputnik-metrics-config
data:
  statsd.yaml: ""
  prometheus.yaml: |
    global:
      scrape_interval:     3s
      evaluation_interval: 3s
    scrape_configs:
      - job_name: 'prometheus'
        static_configs:
          - targets: ['localhost:9090']
      - job_name: 'test_metrics'
        static_configs:
          - targets: ['localhost:9102']
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sputnik-metrics
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sputnik-metrics
  template:
    metadata:
      labels:
        app: sputnik-metrics
    spec:
      containers:
      - name: sputnik-metrics-statsd
        image: prom/statsd-exporter
        ports:
        - name: tcp
          containerPort: 9102
        - name: udp
          containerPort: 8125
          protocol: UDP
        args:
          - --statsd.mapping-config=/tmp/statsd.yaml
          - --statsd.listen-udp=:8125
          - --web.listen-address=:9102
        volumeMounts:
          - mountPath: /tmp
            name: sputnik-metrics-config-files
      - name: sputnik-metrics-prometheus
        image: prom/prometheus
        ports:
        - name: tcp
          containerPort: 9090
        args:
          - --config.file=/tmp/prometheus.yaml
        volumeMounts:
          - mountPath: /tmp
            name: sputnik-metrics-config-files
      volumes:
        - name: sputnik-metrics-config-files
          configMap:
            name: sputnik-metrics-config
---
apiVersion: v1
kind: Service
metadata:
  name: sputnik-metrics-statsd
spec:
  type: NodePort
  ports:
  - name: udp
    port: 8125
    targetPort: 8125
    protocol: UDP
  selector:
    app: sputnik-metrics
---
apiVersion: v1
kind: Service
metadata:
  name: sputnik-metrics-prometheus
spec:
  type: LoadBalancer
  ports:
  - name: http
    port: 9090
    targetPort: 9090
  selector:
    app: sputnik-metrics

Guarde las configuraciones en un archivo denominado metrics.yaml. Use el siguiente comando para implementar todo en el clúster:

kubectl apply -f metrics.yaml

Una vez finalizada la implementación, ejecute el siguiente comando para comprobar que los pods se están ejecutando. El nombre del pod será diferente.

kubectl get pods
NAME                                   READY   STATUS    RESTARTS   AGE
sputnik-metrics-f6d97548f-4xnb7        2/2     Running   0          1m

Ejecute el siguiente comando para comprobar que los services se están ejecutando. Tome nota de CLUSTER-IP y PORT del servicio StatsD, que usaremos más adelante. Puede visitar el panel de Prometheus con EXTERNAL-IP y PORT.

kubectl get services
NAME                         TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                      AGE
sputnik-metrics-prometheus   LoadBalancer   10.0.252.72   13.89.141.90    9090:32663/TCP               18h
sputnik-metrics-statsd       NodePort       10.0.41.179   <none>          8125:32733/UDP               18h

Configuración de la puerta de enlace autohospedada para emitir métricas

Ahora que StatsD y Prometheus se han implementado, podemos actualizar las configuraciones de la puerta de enlace autohospedada para empezar a emitir métricas mediante StatsD. La característica se puede habilitar o deshabilitar con la clave telemetry.metrics.local en ConfigMap de la implementación de puerta de enlace autohospedada con opciones adicionales. A continuación se indican las opciones disponibles:

Campo	Valor predeterminado	Descripción
telemetry.metrics.local	`none`	Habilita el registro mediante StatsD. El valor puede ser `none`, `statsd`.
telemetry.metrics.local.statsd.endpoint	N/D	Especifica el punto de conexión de StatsD.
telemetry.metrics.local.statsd.sampling	N/D	Especifica la frecuencia de muestreo de las métricas. El valor puede estar comprendido entre 0 y 1. Ejemplo: `0.5`
telemetry.metrics.local.statsd.tag-format	N/D	Formato de etiquetado del exportador de StatsD. El valor puede ser `none`, `librato`, `dogStatsD`, `influxDB`.

Esta es una configuración de ejemplo:

apiVersion: v1
kind: ConfigMap
metadata:
    name: contoso-gateway-environment
data:
    config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
    telemetry.metrics.local: "statsd"
    telemetry.metrics.local.statsd.endpoint: "10.0.41.179:8125"
    telemetry.metrics.local.statsd.sampling: "1"
    telemetry.metrics.local.statsd.tag-format: "dogStatsD"

Actualice el archivo YAML de la implementación de puerta de enlace autohospedada con las configuraciones anteriores y aplique los cambios con el siguiente comando:

kubectl apply -f <file-name>.yaml

Para recoger los últimos cambios de configuración, reinicie la implementación de la puerta de enlace con el siguiente comando:

kubectl rollout restart deployment/<deployment-name>

Visualización de las métricas

Ahora que hemos implementado y configurado todo, la puerta de enlace autohospedada debe notificar las métricas mediante StatsD. Después, Prometheus recoge las métricas de StatsD. Vaya al panel de Prometheus mediante EXTERNAL-IP y PORT del servicio Prometheus.

Realice algunas llamadas de API mediante la puerta de enlace autohospedada; si todo está configurado correctamente, debería poder ver las métricas siguientes:

Métrica	Descripción
requests_total	Número de solicitudes de API en el período
request_duration_seconds	Número de milisegundos transcurridos desde el momento en que la puerta de enlace recibió la solicitud hasta que se envió toda la respuesta
request_backend_duration_seconds	Número de milisegundos empleados en la E/S global de back-end (conexión, envío y recepción de bytes)
request_client_duration_seconds	Número de milisegundos empleados en la E/S global del cliente (conexión, envío y recepción de bytes)

Registros

La puerta de enlace autohospedada genera registros en stdout y stderr de forma predeterminada. Puede ver fácilmente los registros con el siguiente comando:

kubectl logs <pod-name>

Si la puerta de enlace autohospedada está implementada en Azure Kubernetes Service, puede habilitar Azure Monitor para contenedores con el fin de recopilar stdout y stderr de sus cargas de trabajo y ver los registros en Log Analytics.

La puerta de enlace autohospedada también admite varios protocolos, como localsyslog, rfc5424 y journal. En la tabla siguiente se resumen todas las opciones admitidas.

Campo	Valor predeterminado	Descripción
telemetry.logs.std	`text`	Habilita el registro en flujos estándares. El valor puede ser `none`, `text`, `json`.
telemetry.logs.local	`auto`	Habilita el registro local. El valor puede ser `none`, `auto`, `localsyslog`, `rfc5424`, `journal`, `json`
telemetry.logs.local.localsyslog.endpoint	N/D	Especifica el punto de conexión de syslog local. Para más información, consulte uso de registros de syslog local.
telemetry.logs.local.localsyslog.facility	N/D	Especifica el código de instalación del syslog local. Ejemplo: `7`
telemetry.logs.local.rfc5424.endpoint	N/D	Especifica el punto de conexión rfc5424.
telemetry.logs.local.rfc5424.facility	N/D	Especifica el código de componente por rfc5424. Ejemplo: `7`
telemetry.logs.local.journal.endpoint	N/D	Especifica el punto de conexión del diario.
telemetry.logs.local.json.endpoint	127.0.0.1:8888	Especifica el punto de conexión UDP que acepta datos JSON: ruta de archivo, IP:puerto o nombreDeHost:puerto.

Esta es una configuración de ejemplo del registro local:

    apiVersion: v1
    kind: ConfigMap
    metadata:
        name: contoso-gateway-environment
    data:
        config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
        telemetry.logs.std: "text"
        telemetry.logs.local.localsyslog.endpoint: "/dev/log"
        telemetry.logs.local.localsyslog.facility: "7"

Uso del punto de conexión JSON local

Restricciones conocidas

Solo se admiten hasta 3072 bytes de carga de solicitud/respuesta para diagnósticos locales. Cualquier cosa por encima puede interrumpir el formato JSON debido a la fragmentación.

Uso de registros de syslog local

Configuración de la puerta de enlace para transmitir registros

Al usar el syslog local como destino de los registros, el runtime debe permitir la transmisión de los registros al destino. Para Kubernetes, es necesario montar un volumen que coincida con el destino.

Dada la siguiente configuración:

apiVersion: v1
kind: ConfigMap
metadata:
    name: contoso-gateway-environment
data:
    config.service.endpoint: "<self-hosted-gateway-management-endpoint>"
    telemetry.logs.local: localsyslog
    telemetry.logs.local.localsyslog.endpoint: /dev/log

Puede iniciar fácilmente la transmisión de registros a ese punto de conexión de syslog local:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-deployment
  labels:
    app: contoso
spec:
  replicas: 1
  selector:
    matchLabels:
      app: contoso
  template:
    metadata:
      labels:
        app: contoso
    spec:
      containers:
        name: azure-api-management-gateway
        image: mcr.microsoft.com/azure-api-management/gateway:2.5.0
        imagePullPolicy: IfNotPresent
        envFrom:
        - configMapRef:
            name: contoso-gateway-environment
        # ... redacted ...
+       volumeMounts:
+       - mountPath: /dev/log
+         name: logs
+     volumes:
+     - hostPath:
+         path: /dev/log
+         type: Socket
+       name: logs

Consumo de registros de syslog local en Azure Kubernetes Service (AKS)

Al configurar para usar syslog local en Azure Kubernetes Service, puede elegir dos maneras de explorar los registros:

Uso de Recopilación de Syslog con Container Insights
Conexión y registros de exploración en los nodos de trabajo

Consumo de registros de nodos de trabajo

Para consumirlos fácilmente, obtenga acceso a los nodos de trabajo de esta forma:

Cree una conexión SSH al nodo (documentación).
Puede encontrar los registros en host/var/log/syslog.

Por ejemplo, puede filtrar todos los syslog a solo los de la puerta de enlace autohospedada:

$ cat host/var/log/syslog | grep "apimuser"
May 15 05:54:20 aks-agentpool-43853532-vmss000000 apimuser[8]: Timestamp=2023-05-15T05:54:20.0445178Z, isRequestSuccess=True, totalTime=290, category=GatewayLogs, callerIpAddress=141.134.132.243, timeGenerated=2023-05-15T05:54:20.0445178Z, region=Repro, correlationId=aaaa0000-bb11-2222-33cc-444444dddddd, method=GET, url="http://20.126.242.200/echo/resource?param1\=sample", backendResponseCode=200, responseCode=200, responseSize=628, cache=none, backendTime=287, apiId=echo-api, operationId=retrieve-resource, apimSubscriptionId=master, clientProtocol=HTTP/1.1, backendProtocol=HTTP/1.1, apiRevision=1, backendMethod=GET, backendUrl="http://echoapi.cloudapp.net/api/resource?param1\=sample"
May 15 05:54:21 aks-agentpool-43853532-vmss000000 apimuser[8]: Timestamp=2023-05-15T05:54:21.1189171Z, isRequestSuccess=True, totalTime=150, category=GatewayLogs, callerIpAddress=141.134.132.243, timeGenerated=2023-05-15T05:54:21.1189171Z, region=Repro, correlationId=bbbb1111-cc22-3333-44dd-555555eeeeee, method=GET, url="http://20.126.242.200/echo/resource?param1\=sample", backendResponseCode=200, responseCode=200, responseSize=628, cache=none, backendTime=148, apiId=echo-api, operationId=retrieve-resource, apimSubscriptionId=master, clientProtocol=HTTP/1.1, backendProtocol=HTTP/1.1, apiRevision=1, backendMethod=GET, backendUrl="http://echoapi.cloudapp.net/api/resource?param1\=sample"

Nota

Si cambió la raíz con chroot (por ejemplo, chroot /host), la ruta de acceso anterior debe reflejar ese cambio.

Pasos siguientes

Obtenga información sobre las capacidades de observación de las puertas de enlace de Azure API Management.
Obtenga más información sobre la puerta de enlace autohospedada de Azure API Management.
Más información acerca de la configuración y persistencia de registros en la nube.

Compartir vía