Skonfiguruj lokalne metryki i dzienniki dla samodzielnie hostowanej bramy usługi Azure API Management

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 StatsD, który jest jednolitym protokołem zbierania i agregacji metryk. W tej sekcji opisano kroki wdrażania StatsD na platformie Kubernetes, konfigurowania bramy w celu emitowania metryk za pośrednictwem StatsD oraz monitorowania metryk przy użyciu Prometheus.

Wdróż StatsD i Prometheus w klastrze

Poniższa przykładowa konfiguracja YAML wdraża StatsD i Prometheus w klastrze Kubernetes, w którym wdrożono bramę samodzielnie hostowaną. Tworzy również usługę dla każdej z nich. Brama hostowana samodzielnie publikuje następnie metryki w usłudze StatsD. Dostęp do pulpitu nawigacyjnego Prometheus można uzyskać przez jego usługę.

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 pody są uruchomione. Nazwa pod jest inna.

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

Uruchom następujące polecenie, aby sprawdzić, czy services są uruchomione. Zanotuj CLUSTER-IP i PORT usługi StatsD, które będziesz używał później. Panel sterowania 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

Skonfiguruj bramę działającą lokalnie, aby emitować metryki

Po wdrożeniu funkcji StatsD i Prometheus można zaktualizować konfiguracje własnej bramy, aby rozpocząć emitowanie metryk za pomocą funkcji StatsD. Użyj klucza telemetry.metrics.local w ConfigMap wdrożenia bramy lokalnej, aby włączyć lub wyłączyć tę funkcję. Można również ustawić dodatkowe opcje. Dostępne są następujące opcje:

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 samodzielnie zarządzanej bramy przy użyciu poprzednich konfiguracji i zastosuj zmiany za pomocą następującego polecenia.

kubectl apply -f <file-name>.yaml

Aby pobrać najnowsze zmiany konfiguracji, uruchom ponownie wdrożenie bramy za pomocą następującego polecenia:

kubectl rollout restart deployment/<deployment-name>

Wyświetlanie metryk

Po wdrożeniu i skonfigurowaniu wszystkich elementów metryki bramy samodzielnie hostowanej są raportowane za pomocą StatsD. Prometheus następnie pobiera metryki z StatsD. Przejdź do pulpitu nawigacyjnego Prometheus, używając EXTERNAL-IP i PORT usługi Prometheus.

Wykonaj wywołania interfejsu API za pomocą samodzielnie hostowanej bramy. Jeśli wszystko jest poprawnie skonfigurowane, możesz wyświetlić następujące metryki:

Dzienniki

Domyślnie brama samodzielnie hostowana generuje dzienniki do stdout i stderr. Dzienniki można łatwo wyświetlić za pomocą następującego polecenia:

kubectl logs <pod-name>

Jeśli wdrożysz własną bramę 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.

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 lokalnego punktu końcowego JSON

Znane ograniczenia

• Funkcja diagnostyki lokalnej obsługuje maksymalnie 3072 bajty ładunku żądania i odpowiedzi. Jeśli rozmiar ładunku przekracza ten limit, fragmentowanie może spowodować przerwanie formatu JSON.

Korzystanie z lokalnych dzienników dziennika systemu

Konfigurowanie bramy do strumieniowego przesyłania dzienników

Jeśli używasz lokalnego dziennika syslog jako miejsca docelowego dla dzienników, środowisko uruchomieniowe musi zezwalać na przesyłanie strumieniowe dzienników do miejsca docelowego. W przypadku usługi Azure Kubernetes Service należy zainstalować wolumin 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

Strumieniowanie dzienników można łatwo rozpocząć do lokalnego punktu końcowego syslogu.

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 lokalnego dziennika systemowego w usłudze Azure Kubernetes Service można wybrać dwa sposoby eksplorowania dzienników:

• Używanie kolekcji Syslog z usługą Container Insights
• Łącz i eksploruj dzienniki na węzłach roboczych

Korzystanie z dzienników z węzłów roboczych

Logi można łatwo przeglądać, uzyskując dostęp do węzłów roboczych.

1. Utwórz połączenie SSH z węzłem (docs).
2. Znajdź dzienniki w sekcji host/var/log/syslog.

Można na przykład filtrować wszystkie dzienniki syslog, aby pokazać tylko te z bramy własnej-hostowanej.

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

Powiązana zawartość

• Dowiedz się więcej o możliwościach obserwacji bram usługi Azure API Management.
• Dowiedz się więcej na temat samodzielnie hostowanej bramy usługi Azure API Management.
• Dowiedz się więcej o konfigurowaniu i utrwalaniu dzienników w chmurze.