Konfigurowanie lokalnych metryk i dzienników dla własnej bramy usługi Azure API Management

Artykuł
04/15/2024

DOTYCZY: Developer | Premium

Ten artykuł zawiera szczegółowe informacje dotyczące konfigurowania lokalnych metryk i dzienników dla bramy hostowanej samodzielnie wdrożonej w klastrze Kubernetes. Aby skonfigurować metryki i dzienniki w chmurze, zobacz ten artykuł.

Metryki

Brama hostowana samodzielnie obsługuje funkcję StatsD, która stała się jednoczącym protokołem zbierania i agregacji metryk. W tej sekcji opisano kroki wdrażania funkcji StatsD na platformie Kubernetes, konfigurowania bramy w celu emitowania metryk za pośrednictwem statystykD oraz monitorowania metryk przy użyciu rozwiązania Prometheus .

Wdrażanie statystyk i rozwiązania Prometheus w klastrze

Poniższa przykładowa konfiguracja YAML wdraża usługi StatsD i Prometheus w klastrze Kubernetes, w którym wdrożono własną bramę. Tworzy również usługę dla każdej z nich. Brama hostowana samodzielnie publikuje następnie metryki w usłudze StatsD. Uzyskamy dostęp do pulpitu nawigacyjnego rozwiązania Prometheus za pośrednictwem jego usługi.

Uwaga

Poniższy przykład ściąga publiczne obrazy kontenerów z usługi Docker Hub. Zalecamy skonfigurowanie wpisu tajnego ściągania w celu uwierzytelniania przy użyciu konta usługi Docker Hub zamiast tworzenia anonimowego żądania ściągnięcia. Aby zwiększyć niezawodność podczas pracy z zawartością publiczną, zaimportuj obrazy i zarządzaj nimi w prywatnym rejestrze kontenerów platformy Azure. Dowiedz się więcej o pracy z obrazami publicznymi.

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

Zapisz konfiguracje w pliku o nazwie metrics.yaml. Użyj następującego polecenia, aby wdrożyć wszystko w klastrze:

kubectl apply -f metrics.yaml

Po zakończeniu wdrażania uruchom następujące polecenie, aby sprawdzić, czy zasobniki są uruchomione. Nazwa zasobnika będzie inna.

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

Uruchom poniższe polecenie, aby sprawdzić, czy polecenie jest uruchomione services . Zanotuj CLUSTER-IP wartości i PORT usługi StatsD Service, której używamy później. Pulpit nawigacyjny rozwiązania Prometheus można odwiedzić przy użyciu jego EXTERNAL-IP i 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

Konfigurowanie własnej bramy w celu emitowania metryk

Teraz, po wdrożeniu funkcji StatsD i Prometheus, możemy zaktualizować konfiguracje własnej bramy, aby rozpocząć emitowanie metryk za pomocą funkcji StatsD. Tę funkcję można włączyć lub wyłączyć przy użyciu telemetry.metrics.local klucza w ConfigMap wdrożenia bramy własnej z dodatkowymi opcjami. Dostępne są następujące opcje:

Pole	Domyślny	opis
telemetry.metrics.local	`none`	Włącza rejestrowanie za pomocą funkcji StatsD. Wartość może mieć wartość `none`, `statsd`.
telemetry.metrics.local.statsd.endpoint	nie dotyczy	Określa punkt końcowy StatsD.
telemetry.metrics.local.statsd.sampling	nie dotyczy	Określa częstotliwość próbkowania metryk. Wartość może należeć do zakresu od 0 do 1. Przykład: `0.5`
telemetry.metrics.local.statsd.tag-format	nie dotyczy	Format tagowania eksportera StatsD. Wartość może mieć `none`wartość , , `libratodogStatsD`, `influxDB`.

Oto przykładowa konfiguracja:

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"

Zaktualizuj plik YAML wdrożenia własnej bramy przy użyciu powyższych konfiguracji i zastosuj zmiany przy użyciu poniższego polecenia:

kubectl apply -f <file-name>.yaml

Aby pobrać najnowsze zmiany konfiguracji, uruchom ponownie wdrożenie bramy przy użyciu poniższego polecenia:

kubectl rollout restart deployment/<deployment-name>

Wyświetlanie metryk

Teraz mamy wszystko wdrożone i skonfigurowane, brama self-hosted powinna zgłaszać metryki za pośrednictwem statsD. Prometheus następnie pobiera metryki z StatsD. Przejdź do pulpitu nawigacyjnego rozwiązania Prometheus przy użyciu polecenia EXTERNAL-IP i PORT usługi Prometheus.

Wykonaj wywołania interfejsu API za pośrednictwem bramy hostowanej samodzielnie, jeśli wszystko jest poprawnie skonfigurowane, powinno być możliwe wyświetlenie poniższych metryk:

Metryczne	opis
requests_total	Liczba żądań interfejsu API w danym okresie
request_duration_seconds	Liczba milisekund od momentu odebrania żądania w bramie do momentu pełnego wysłania odpowiedzi
request_backend_duration_seconds	Liczba milisekund wydanych na ogólne operacje we/wy zaplecza (łączenie, wysyłanie i odbieranie bajtów)
request_client_duration_seconds	Liczba milisekund wydanych na ogólne operacje we/wy klienta (łączenie, wysyłanie i odbieranie bajtów)

Dzienniki

Brama self-hosted generuje dzienniki do stdout i stderr domyślnie. Dzienniki można łatwo wyświetlić przy użyciu następującego polecenia:

kubectl logs <pod-name>

Jeśli brama hostowana samodzielnie jest wdrożona w usłudze Azure Kubernetes Service, możesz włączyć usługę Azure Monitor dla kontenerów w celu zbierania stdout i stderr z obciążeń oraz wyświetlania dzienników w usłudze Log Analytics.

Brama hostowana samodzielnie obsługuje również wiele protokołów, w tym localsyslog, rfc5424i journal. Poniższa tabela zawiera podsumowanie wszystkich obsługiwanych opcji.

Pole	Domyślny	opis
telemetry.logs.std	`text`	Umożliwia rejestrowanie w standardowych strumieniach. Wartość może mieć `none`wartość , , `textjson`
telemetry.logs.local	`auto`	Włącza rejestrowanie lokalne. Wartość może być `none`, , `localsyslogauto`, `rfc5424`, `journaljson`
telemetry.logs.local.localsyslog.endpoint	nie dotyczy	Określa lokalny punkt końcowy dziennika systemu. Aby uzyskać szczegółowe informacje, zobacz using local syslog logs (Używanie lokalnych dzienników syslogu).
telemetry.logs.local.localsyslog.facility	nie dotyczy	Określa lokalny kod obiektu syslog. Przykład: `7`
telemetry.logs.local.rfc5424.endpoint	nie dotyczy	Określa punkt końcowy rfc5424.
telemetry.logs.local.rfc5424.facility	nie dotyczy	Określa kod obiektu na rfc5424. Przykład: `7`
telemetry.logs.local.journal.endpoint	nie dotyczy	Określa punkt końcowy dziennika.
telemetry.logs.local.json.endpoint	127.0.0.1:8888	Określa punkt końcowy UDP, który akceptuje dane JSON: ścieżka pliku, IP:port lub nazwa hosta:port.

Oto przykładowa konfiguracja rejestrowania lokalnego:

    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"

Korzystanie z lokalnych dzienników dziennika systemu

Konfigurowanie bramy w celu przesyłania strumieniowego dzienników

W przypadku używania lokalnego dziennika systemowego jako miejsca docelowego dla dzienników środowisko uruchomieniowe musi zezwalać na przesyłanie strumieniowe dzienników do miejsca docelowego. W przypadku platformy Kubernetes wolumin musi być zainstalowany, który jest zgodny z miejscem docelowym.

Biorąc pod uwagę następującą konfigurację:

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

Dzienniki przesyłania strumieniowego można łatwo uruchomić do lokalnego punktu końcowego dziennika systemu:

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

Korzystanie z lokalnych dzienników dziennika systemu w usłudze Azure Kubernetes Service (AKS)

Podczas konfigurowania używania lokalnego dziennika systemowego w usłudze Azure Kubernetes Service można wybrać dwa sposoby eksplorowania dzienników:

Używanie kolekcji Syslog z Szczegółowe informacje kontenera
Połączenie i eksplorowanie dzienników w węzłach procesu roboczego

Korzystanie z dzienników z węzłów procesu roboczego

Możesz je łatwo używać, uzyskując dostęp do węzłów procesu roboczego:

Tworzenie połączenia SSH z węzłem (docs)
Dzienniki można znaleźć w obszarze host/var/log/syslog

Można na przykład filtrować wszystkie dzienniki syslog do tylko tych z własnej bramy:

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