Anmerkung
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
GILT FÜR: Developer | 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 selbst gehostete Gateway unterstützt StatsD, ein vereinheitlichendes Protokoll für die Metriksammlung und -aggregation. 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. Sie greifen über den Dienst auf das Prometheus-Dashboard zu.
Hinweis
Im folgenden Beispiel werden öffentliche Containerimages von Docker Hub abgerufen. Richten Sie einen Pullschlüssel ein, um sich mit einem Docker Hub-Konto zu authentifizieren, anstatt eine anonyme Pullanforderung zu erstellen. Um die Zuverlässigkeit beim Arbeiten mit öffentlichen Inhalten zu verbessern, importieren und verwalten Sie die Bilder in einer privaten Azure-Containerregistrierung. 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 ist 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 die services zu überprüfen, die ausgeführt werden. Notieren Sie sich die CLUSTER-IP und den PORT des StatsD-Diensts, die Sie 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 sowohl StatsD als auch Prometheus bereitgestellt wurden, können Sie die Konfigurationen des selbst gehosteten Gateways aktualisieren, um mit dem Ausstrahlen von Metriken über StatsD zu beginnen. Verwenden Sie den telemetry.metrics.local Schlüssel in der ConfigMap der selbst gehosteten Gatewaybereitstellung, um dieses Feature zu aktivieren oder zu deaktivieren. Sie können auch zusätzliche Optionen festlegen. Die folgenden 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 selbst gehosteten Gatewaybereitstellung mit den vorherigen Konfigurationen, und wenden Sie die Änderungen mit dem folgenden Befehl an:
kubectl apply -f <file-name>.yaml
Um die neuesten Konfigurationsänderungen zu übernehmen, starten Sie die Gatewaybereitstellung mit dem folgenden Befehl neu:
kubectl rollout restart deployment/<deployment-name>
Anzeigen der Metriken
Nachdem Sie nun alles bereitgestellt und konfiguriert haben, meldet das selbst gehostete Gateway Metriken über StatsD. Prometheus übernimmt dann die Metriken von StatsD. Gehen Sie zum Prometheus-Dashboard, indem Sie EXTERNAL-IP und PORT des Prometheus-Dienstes verwenden.
Führen Sie einige API-Aufrufe über das selbst gehostete Gateway durch. Wenn alles richtig konfiguriert ist, können Sie die folgenden Metriken anzeigen:
| Metrik | BESCHREIBUNG |
|---|---|
| Anfragen_Gesamt | Anzahl von 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 die Ausführung aller Back-End-E/A-Vorgänge (Verbindungsherstellung, 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 in stdout und stderr aus. Sie können die Protokolle ganz einfach anzeigen, indem Sie den folgenden Befehl verwenden:
kubectl logs <pod-name>
Wenn Sie Ihr selbst gehostetes Gateway in Azure Kubernetes Service bereitstellen, können Sie Azure Monitor für Container aktivieren, um stdout und stderr aus Ihren Workloads zu erfassen und die Protokolle in Log Analytics anzuzeigen.
Das selbst gehostete Gateway unterstützt auch viele Protokolle, einschließlich localsyslog, rfc5424und journal. In der folgenden Tabelle sind alle unterstützten Optionen zusammengefasst.
| 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 | – | Gibt den lokalen Syslog-Endpunkt an. Ausführliche Informationen finden Sie unter Verwendung lokaler Syslog-Protokolle. |
| telemetry.logs.local.localsyslog.facility | – | 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
- Die lokale Diagnosefunktion unterstützt eine Nutzlast von bis zu 3.072 Byte für Anfrage und Antwort. Wenn die Nutzlastgröße diesen Grenzwert überschreitet, kann die Segmentierung das JSON-Format beschädigen.
Verwenden lokaler Syslogprotokolle
Konfigurieren des Gateways zum Streamen von Protokollen
Wenn Sie lokalen Syslog als Ziel für Protokolle verwenden, muss die Laufzeitumgebung das Streamen von Protokollen an das Ziel zulassen. Für Azure Kubernetes Service müssen Sie ein Volume bereitstellen, 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
Verbrauchen lokaler Syslog-Protokolle in Azure Kubernetes Service (AKS)
Wenn Sie lokalen Syslog für Azure Kubernetes Service konfigurieren, können Sie zwei Möglichkeiten zum Erkunden 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 diese problemlos nutzen, indem Sie Zugriff auf die Workerknoten erhalten:
- Erstellen Sie eine SSH-Verbindung mit dem Knoten (Docs).
- Finden Sie Protokolle 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 zum Beispiel in chroot /host ändern, muss der vorangehende Pfad diese Änderung widerspiegeln.
Verwandte Inhalte
- 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.