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 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:

1. Erstellen einer SSH-Verbindung mit dem Knoten (Dokumentation)
2. 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=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"

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.