Compartir vía

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

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 es 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. Acceda 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. Configure 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 las imágenes en una instancia privada de Azure Container Registry. 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 de tu pod es diferente.

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

Ejecute el siguiente comando para comprobar los services se están ejecutando. Tome nota de CLUSTER-IP y PORT del servicio StatsD, que usará 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 se implementan StatsD y Prometheus, puede actualizar las configuraciones de la puerta de enlace autohospedada para empezar a emitir métricas a través de StatsD. Use la clave telemetry.metrics.local en ConfigMap de la implementación de puerta de enlace autohospedada para habilitar o deshabilitar esta característica. También puede establecer opciones adicionales. Las siguientes opciones están 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 seleccionar los cambios de configuración más recientes, 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 implementó y configuró todo, la puerta de enlace autohospedada notifica las métricas a través de 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 API a través de la puerta de enlace autohospedada. Si todo está configurado correctamente, puede 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

De forma predeterminada, la puerta de enlace autohospedada genera registros en stdout y stderr. Puede ver fácilmente los registros mediante el comando siguiente:

kubectl logs <pod-name>

Si implementa 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 muchos protocolos, como localsyslog, rfc5424y 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

  • La característica de diagnóstico local admite hasta 3072 bytes de carga de solicitud y respuesta. Si el tamaño de carga supera este límite, la fragmentación podría interrumpir el formato JSON.

Uso de registros de syslog local

Configuración de la puerta de enlace para transmitir registros

Cuando se usa syslog local como destino para los registros, el entorno de ejecución debe permitir el streaming de registros al destino. Para el servicio de Azure Kubernetes, debe montar un volumen que coincida con la ubicación de 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 syslog local en Azure Kubernetes Service, puede elegir dos maneras de explorar los registros:

Consumo de registros de nodos de trabajo

Para consumir fácilmente registros, obtenga acceso a los nodos de trabajo:

  1. Cree una conexión SSH al nodo (docs).
  2. Busque 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 cambia la raíz con chroot, por ejemplo chroot /host, entonces la ruta precedente debe reflejar ese cambio.

Contenido relacionado

  • Last updated on