Konfigurieren von lokalen Metriken und Protokollen für selbstgehostete Gateways für Azure API Management
GILT FÜR: Entwickler*in | Premium
Dieser Artikel enthält Details zum Konfigurieren lokaler Metriken und Protokolle für das selbstgehostete Gateway, das in einem Kubernetes-Cluster bereitgestellt ist. Informationen zum Konfigurieren von Cloudmetriken und -protokollen finden Sie in diesem Artikel.
Metriken
Das selbstgehostete Gateway unterstützt StatsD, das zu einem Standardprotokoll für die Erfassung und Aggregation von Metriken geworden ist. In diesem Abschnitt werden die Schritte für die Bereitstellung von StatsD in Kubernetes, die Konfiguration des Gateways zur Ausgabe von Metriken über StatsD und die Verwendung von Prometheus zum Überwachen der Metriken erläutert.
Bereitstellen von StatsD und Prometheus im Cluster
Die folgende YAML-Beispielkonfiguration stellt StatsD und Prometheus im Kubernetes-Cluster bereit, in dem ein selbstgehostetes Gateway bereitgestellt wird. Außerdem wird für beide ein Dienst erstellt. Das selbstgehostete Gateway veröffentlicht dann Metriken im StatsD-Dienst. Der Zugriff auf das Prometheus-Dashboard erfolgt über seinen Dienst.
Hinweis
Im folgenden Beispiel werden öffentliche Containerimages von Docker Hub abgerufen. Es wird empfohlen, ein Pullgeheimnis für die Authentifizierung mithilfe eines Docker Hub-Kontos einrichten, anstatt einen anonymen Pull Request zu verwenden. Um die Zuverlässigkeit bei der Arbeit mit öffentlichen Inhalten zu verbessern, sollten Sie die Images in eine private Azure-Containerregistrierung importieren und dort verwalten. Erfahren Sie mehr über die Arbeit mit öffentlichen Images.
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
Speichern Sie die Konfigurationen in einer Datei mit dem Namen metrics.yaml. Verwenden Sie den folgenden Befehl, um alles im Cluster bereitzustellen:
kubectl apply -f metrics.yaml
Führen Sie nach Abschluss der Bereitstellung den folgenden Befehl aus, um zu prüfen, ob die Pods ausgeführt werden. Ihr Podname lautet anders.
kubectl get pods
NAME READY STATUS RESTARTS AGE
sputnik-metrics-f6d97548f-4xnb7 2/2 Running 0 1m
Führen Sie den folgenden Befehl aus, um zu prüfen, ob die services ausgeführt werden. Notieren Sie sich die CLUSTER-IP und PORT des StatsD-Diensts, die wir später verwenden. Sie können das Prometheus-Dashboard besuchen, indem Sie dessen EXTERNAL-IP und PORT angeben.
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
Konfigurieren des selbstgehosteten Gateways zum Ausgeben von Metriken
Nachdem jetzt sowohl StatsD und als auch Prometheus bereitgestellt sind, können wir die Konfigurationen des selbstgehosteten Gateways so aktualisieren, dass die Ausgabe von Metriken über StatsD beginnt. Das Feature kann über den Schlüssel telemetry.metrics.local in der ConfigMap in der selbstgehosteten Gatewaybereitstellung mit zusätzlichen Optionen aktiviert oder deaktiviert werden. Folgende Optionen sind verfügbar:
| Feld | Standard | Beschreibung |
|---|---|---|
| telemetry.metrics.local | none |
Aktiviert die Protokollierung durch StatsD. Mögliche Werte: none oder statsd. |
| telemetry.metrics.local.statsd.endpoint | – | Gibt den StatsD-Endpunkt an. |
| telemetry.metrics.local.statsd.sampling | – | Gibt die Stichprobenhäufigkeit für Metriken an. Der Wert kann im Bereich 0 bis 1 liegen. Beispiel: 0.5 |
| telemetry.metrics.local.statsd.tag-format | – | Taggingformat der Exportfunktion von StatsD. Mögliche Werte: none, librato, dogStatsD, influxDB. |
Hier sehen Sie eine Beispielkonfiguration:
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"
Aktualisieren Sie die YAML-Datei der selbstgehosteten Gatewaybereitstellung mit den obigen Konfigurationen, und übernehmen Sie die Änderungen mit dem nachstehenden Befehl:
kubectl apply -f <file-name>.yaml
Um die jüngsten Konfigurationsänderungen zu übernehmen, starten Sie die Gatewaybereitstellung mit dem folgenden Befehl neu:
kubectl rollout restart deployment/<deployment-name>
Anzeigen der Metriken
Nachdem wir alles eingerichtet und konfiguriert haben, sollte das selbstgehostete Gateway über StatsD Metriken melden. Prometheus übernimmt dann die Metriken von StatsD. Wechseln Sie zum Prometheus-Dashboard durch Angeben von EXTERNAL-IP und PORT des Prometheus-Diensts.
Rufen Sie die API über das selbstgehostete Gateway auf. Wenn alles richtig konfiguriert ist, sollten Sie die folgenden Metriken anzeigen können:
| Metrik | BESCHREIBUNG |
|---|---|
| requests_total | Anzahl der API-Anforderungen innerhalb des Zeitraums |
| request_duration_seconds | Anzahl von Millisekunden zwischen dem Zeitpunkt, zu dem das Gateway die Anforderung empfangen hat, und dem Zeitpunkt, zu dem die Antwort vollständig gesendet wurde |
| request_backend_duration_seconds | Anzahl von Millisekunden für alle Back-End-E/A-Vorgänge (Verbindungsherstellung sowie Senden und Empfangen von Bytes) |
| request_client_duration_seconds | Anzahl von Millisekunden für alle Client-E/A-Vorgänge (Verbindungsherstellung, Senden und Empfangen von Bytes) |
Protokolle
Das selbstgehostete Gateway gibt Protokolle standardmäßig in stdout und stderr aus. Sie können die Protokolle mit dem folgenden Befehl mühelos einsehen:
kubectl logs <pod-name>
Wenn Ihr selbstgehostetes Gateway in Azure Kubernetes Service bereitgestellt ist, können Sie Azure Monitor für Container aktivieren, um stdout und stderr aus Ihren Workloads zu sammeln und die Protokolle in Log Analytics anzuzeigen.
Das selbstgehostete Gateway unterstützt auch viele Protokolle, einschließlich localsyslog, rfc5424 und journal. Die folgende Tabelle fasst alle unterstützten Optionen zusammen.
| Feld | Standard | Beschreibung |
|---|---|---|
| telemetry.logs.std | text |
Ermöglicht die Protokollierung in Standarddatenströmen. Möglicher Wert: none, text, json |
| telemetry.logs.local | auto |
Aktiviert die lokale Protokollierung. Der Wert kann none, auto, localsyslog, rfc5424, journal oder json lauten. |
| telemetry.logs.local.localsyslog.endpoint | Nicht zutreffend | Gibt den lokalen Syslog-Endpunkt an. Ausführliche Informationen finden Sie unter Verwendung lokaler Syslog-Protokolle. |
| telemetry.logs.local.localsyslog.facility | Nicht zutreffend | Gibt den lokalen Syslog-Einrichtungscode an. Beispiel: 7 |
| telemetry.logs.local.rfc5424.endpoint | – | Gibt den rfc5424-Endpunkt an. |
| telemetry.logs.local.rfc5424.facility | – | Gibt den Facilitycode gemäß rfc5424 an. Beispiel: 7 |
| telemetry.logs.local.journal.endpoint | – | Gibt den Endpunkt des Journals an. |
| telemetry.logs.local.json.endpoint | 127.0.0.1:8888 | Gibt den UDP-Endpunkt an, von dem JSON-Daten akzeptiert werden: Dateipfad, „IP:port“ oder „hostname:port“. |
Hier ist eine Beispielkonfiguration für die lokale Protokollierung:
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"
Verwenden des lokalen JSON-Endpunkts
Bekannte Einschränkungen
- Wir unterstützen nur bis zu 3072 Byte Anforderungs-/Antwortnutzlast für die lokale Diagnose. Alles darüber kann das JSON-Format aufgrund von Blöcken unterbrechen.
Verwenden lokaler Syslogprotokolle
Konfigurieren des Gateways zum Streamen von Protokollen
Wenn Sie lokales Syslog als Ziel für Protokolle verwenden, muss die Runtime das Streaming von Protokollen an das Ziel zulassen. Für Kubernetes muss ein Volume eingebunden werden, das dem Ziel entspricht.
In Anbetracht der folgenden Konfiguration:
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
Sie können das Streaming von Protokolle zu diesem lokalen Syslog-Endpunkt ganz einfach starten:
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
Einlesen lokaler Syslog-Protokolle in Azure Kubernetes Service (AKS)
Beim Konfigurieren der Verwendung des lokalen Syslog in Azure Kubernetes Service können Sie zwei Möglichkeiten zur Erkundung der Protokolle auswählen:
- Verwenden der Syslog-Sammlung mit Container Insights
- Verbinden und Erkunden von Protokollen auf den Workerknoten
Nutzen von Protokollen von Workerknoten
Sie können sie problemlos nutzen, indem Sie Zugriff auf die Workerknoten erhalten:
- Erstellen einer SSH-Verbindung mit dem Knoten (Dokumentation)
- Protokolle finden Sie unter
host/var/log/syslog.
Sie können beispielsweise alle Syslogs auf nur die Syslogs des selbstgehosteten Gateways filtern:
$ 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"
Hinweis
Wenn Sie den Stamm mit chroot geändert haben, z. B chroot /host, muss der obige Pfad diese Änderung widerspiegeln.
Nächste Schritte
- Erfahren Sie mehr über die Einblickfunktionen der Azure API Management-Gateways.
- Erfahren Sie mehr über das selbstgehostete Azure API Management-Gateway.
- Erfahren Sie mehr über das Konfigurieren und Beibehalten von Protokollen in der Cloud.