Lokale metrische gegevens en logboeken configureren voor azure API Management zelf-hostende gateway

Artikel
04/15/2024

VAN TOEPASSING OP: Ontwikkelaar | Premie

Dit artikel bevat informatie over het configureren van lokale metrische gegevens en logboeken voor de zelf-hostende gateway die is geïmplementeerd in een Kubernetes-cluster. Zie dit artikel voor het configureren van metrische gegevens en logboeken van de cloud.

Metrische gegevens voor

De zelf-hostende gateway ondersteunt StatsD, dat een samenvoegingsprotocol is geworden voor verzameling en aggregatie van metrische gegevens. In deze sectie worden de stappen beschreven voor het implementeren van StatsD in Kubernetes, het configureren van de gateway voor het verzenden van metrische gegevens via StatsD en het gebruik van Prometheus om de metrische gegevens te bewaken.

StatsD en Prometheus implementeren in het cluster

Met de volgende YAML-voorbeeldconfiguratie worden StatsD en Prometheus geïmplementeerd in het Kubernetes-cluster waar een zelf-hostende gateway wordt geïmplementeerd. Er wordt ook een service voor elke service gemaakt. De zelf-hostende gateway publiceert vervolgens metrische gegevens naar de StatsD-service. We hebben toegang tot het Prometheus-dashboard via de service.

Notitie

In het volgende voorbeeld worden openbare containerinstallatiekopieën opgehaald uit Docker Hub. U wordt aangeraden een pull-geheim in te stellen voor verificatie met behulp van een Docker Hub-account in plaats van een anonieme pull-aanvraag te maken. Als u de betrouwbaarheid wilt verbeteren bij het werken met openbare inhoud, importeert en beheert u de installatiekopieën in een privé-Azure-containerregister. Meer informatie over het werken met openbare afbeeldingen.

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

Sla de configuraties op in een bestand met de naam metrics.yaml. Gebruik de volgende opdracht om alles in het cluster te implementeren:

kubectl apply -f metrics.yaml

Zodra de implementatie is voltooid, voert u de volgende opdracht uit om te controleren of de pods worden uitgevoerd. De podnaam is anders.

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

Voer de onderstaande opdracht uit om te controleren of de services uitvoering wordt uitgevoerd. Noteer de CLUSTER-IP en PORT van de StatsD-service, die we later gebruiken. U kunt het Prometheus-dashboard bezoeken met behulp van EXTERNAL-IP het en 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

De zelf-hostende gateway configureren om metrische gegevens te verzenden

Nu zowel StatsD als Prometheus zijn geïmplementeerd, kunnen we de configuraties van de zelf-hostende gateway bijwerken om metrische gegevens via StatsD te verzenden. De functie kan worden ingeschakeld of uitgeschakeld met behulp van de telemetry.metrics.local sleutel in de ConfigMap van de zelf-hostende gatewayimplementatie met extra opties. Hier volgen de beschikbare opties:

Veld	Default	Beschrijving
telemetry.metrics.local	`none`	Hiermee schakelt u logboekregistratie via StatsD in. Waarde kan zijn `none`, `statsd`.
telemetry.metrics.local.statsd.endpoint	n.v.t.	Hiermee geeft u het statsd-eindpunt op.
telemetry.metrics.local.statsd.sampling	n.v.t.	Hiermee geeft u de steekproeffrequentie van metrische gegevens op. De waarde kan tussen 0 en 1 zijn. Voorbeeld: `0.5`
telemetry.metrics.local.statsd.tag-format	n.v.t.	De tagindeling statsD-exporteur. Waarde kan zijn`none`, `librato`, `dogStatsD`, . `influxDB`

Hier volgt een voorbeeldconfiguratie:

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"

Werk het YAML-bestand van de zelf-hostende gatewayimplementatie bij met de bovenstaande configuraties en pas de wijzigingen toe met behulp van de onderstaande opdracht:

kubectl apply -f <file-name>.yaml

Als u de meest recente configuratiewijzigingen wilt ophalen, start u de gatewayimplementatie opnieuw met behulp van de onderstaande opdracht:

kubectl rollout restart deployment/<deployment-name>

De metrische gegevens weergeven

Nu alles is geïmplementeerd en geconfigureerd, moet de zelf-hostende gateway metrische gegevens rapporteren via StatsD. Prometheus haalt vervolgens de metrische gegevens op uit StatsD. Ga naar het Prometheus-dashboard met behulp van de EXTERNAL-IP prometheus-service PORT .

Voer enkele API-aanroepen uit via de zelf-hostende gateway, als alles correct is geconfigureerd, kunt u de onderstaande metrische gegevens bekijken:

Metrisch	Beschrijving
requests_total	Aantal API-aanvragen in de periode
request_duration_seconds	Aantal milliseconden vanaf het moment dat de gateway de aanvraag ontving tot het moment dat het antwoord volledig werd verzonden
request_backend_duration_seconds	Aantal milliseconden dat in totaal is besteed aan IO van de back-end (verbinding maken, bytes verzenden en ontvangen)
request_client_duration_seconds	Aantal milliseconden dat is besteed aan de totale io van de client (verbinding maken, verzenden en ontvangen van bytes)

Logboeken

De zelf-hostende gateway voert logboeken uit naar stdout en stderr standaard. U kunt de logboeken eenvoudig weergeven met behulp van de volgende opdracht:

kubectl logs <pod-name>

Als uw zelf-hostende gateway is geïmplementeerd in Azure Kubernetes Service, kunt u Azure Monitor inschakelen voor containers voor het verzamelen stdout en stderr ophalen van uw workloads en het weergeven van de logboeken in Log Analytics.

De zelf-hostende gateway ondersteunt ook veel protocollen, waaronder localsyslog, rfc5424en journal. De volgende tabel bevat een overzicht van alle ondersteunde opties.

Veld	Default	Beschrijving
telemetry.logs.std	`text`	Hiermee kunt u logboekregistratie naar standaardstreams inschakelen. Waarde kan zijn`none`, `textjson`
telemetry.logs.local	`auto`	Hiermee schakelt u lokale logboekregistratie in. Waarde kan zijn`none`, `auto`, `localsyslog`, `rfc5424`, , `journaljson`
telemetry.logs.local.localsyslog.endpoint	n.v.t.	Hiermee geeft u het lokale syslog-eindpunt. Zie voor meer informatie het gebruik van lokale Syslog-logboeken.
telemetry.logs.local.localsyslog.facility	n.v.t.	Hiermee geeft u lokale syslog faciliteit code. Voorbeeld: `7`
telemetry.logs.local.rfc5424.endpoint	n.v.t.	Hiermee geeft u rfc5424-eindpunt.
telemetry.logs.local.rfc5424.facility	n.v.t.	Hiermee geeft u faciliteitcode per rfc5424. Voorbeeld: `7`
telemetry.logs.local.journal.endpoint	n.v.t.	Hiermee geeft u het logboekeindpunt op.
telemetry.logs.local.json.endpoint	127.0.0.1:8888	Hiermee geeft u UDP-eindpunt dat JSON-gegevens accepteert: bestandspad, IP:poort of hostnaam:poort.

Hier volgt een voorbeeldconfiguratie van lokale logboekregistratie:

    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"

Lokaal JSON-eindpunt gebruiken

Bekende beperkingen

We ondersteunen alleen maximaal 3072 bytes aan nettolading van aanvragen/antwoorden voor lokale diagnostische gegevens. Alles hierboven kan de JSON-indeling verbreken vanwege segmentering.

Lokale Syslog-logboeken gebruiken

Gateway configureren voor het streamen van logboeken

Wanneer u lokale syslog gebruikt als bestemming voor logboeken, moet de runtime streaminglogboeken naar de bestemming toestaan. Voor Kubernetes moet een volume worden gekoppeld dat overeenkomt met het doel.

Gegeven de volgende configuratie:

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

U kunt eenvoudig streaminglogboeken naar dat lokale Syslog-eindpunt 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

Lokale Syslog-logboeken gebruiken in Azure Kubernetes Service (AKS)

Wanneer u configureert voor het gebruik van lokale syslog in Azure Kubernetes Service, kunt u twee manieren kiezen om de logboeken te verkennen:

Syslog-verzameling gebruiken met Container Insights
Logboeken verbinden en verkennen op de werkknooppunten

Logboeken van werkknooppunten gebruiken

U kunt ze eenvoudig gebruiken door toegang te krijgen tot de werkknooppunten:

Een SSH-verbinding met het knooppunt maken (docs)
Logboeken vindt u onder host/var/log/syslog

U kunt bijvoorbeeld alle syslogs filteren op alleen syslogs van de zelf-hostende gateway:

$ 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"