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 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=b28565ec-73e0-41e6-9312-efcdd6841846, 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=ab4d7464-acee-40ae-af95-a521cc57c759, 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.