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

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ę ujednolicającym protokołem zbierania i agregacji metryk. W tej sekcji przedstawiono kroki wdrażania funkcji StatsD na platformie Kubernetes, konfigurowania bramy w celu emitowania metryk za pośrednictwem funkcji StatsD oraz monitorowania metryk przy użyciu rozwiązania Prometheus .

Wdrażanie statystyk i rozwiązania Prometheus w klastrze

Poniżej przedstawiono przykładową konfigurację YAML do wdrażania funkcji StatsD i Prometheus w klastrze Kubernetes, w którym wdrożono bramę hostowaną samodzielnie. Tworzy również usługę dla każdego z nich. Brama hostowana samodzielnie opublikuje metryki w usłudze StatsD. Uzyskamy dostęp do pulpitu nawigacyjnego Prometheus za pośrednictwem usługi.

Uwaga

Poniższy przykład ściąga publiczne obrazy kontenerów z Docker Hub. Zalecamy skonfigurowanie wpisu tajnego ściągnięcia w celu uwierzytelnienia przy użyciu konta 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 i użyj poniższego polecenia, aby wdrożyć wszystko w klastrze:

kubectl apply -f metrics.yaml

Po zakończeniu wdrażania uruchom poniższe polecenie, aby sprawdzić, czy zasobniki są uruchomione. Pamiętaj, że 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 usługi są uruchomione. Zanotuj CLUSTER-IP element i PORT usługę StatsD. Będziemy potrzebować jej później. Pulpit nawigacyjny Usługi 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 bramy hostowanej samodzielnie 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. Poniżej przedstawiono podział dostępnych opcji:

Pole Domyślny Opis
telemetry.metrics.local none Włącza rejestrowanie za pośrednictwem funkcji StatsD. Wartość może być none, statsd.
telemetry.metrics.local.statsd.endpoint n/d Określa punkt końcowy StatsD.
telemetry.metrics.local.statsd.sampling n/d 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 n/d Format tagowania eksportera StatsD. Wartość może być none, , librato, influxDBdogStatsD.

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 hostowana samodzielnie powinna zgłaszać metryki za pośrednictwem funkcji StatsD. Prometheus podniesie metryki z StatsD. Przejdź do pulpitu nawigacyjnego Prometheus przy użyciu elementu EXTERNAL-IP i PORT usługi Prometheus.

Wykonaj niektóre 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:

Metric Opis
requests_total Liczba żądań interfejsu API w 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 spędzonych na wykonywaniu ogólnych operacji we/wy zaplecza (łączenie, wysyłanie i odbieranie bajtów)
request_client_duration_seconds Liczba milisekund spędzonych na wykonywaniu ogólnych operacji 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 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 być none, , textjson
telemetry.logs.local auto Włącza rejestrowanie lokalne. Wartość może być none, , auto, localsyslog, rfc5424, , journaljson
telemetry.logs.local.localsyslog.endpoint n/d Określa punkt końcowy localsyslog.
telemetry.logs.local.localsyslog.facility n/d Określa kod obiektu localsyslog. Przykład. 7
telemetry.logs.local.rfc5424.endpoint n/d Określa punkt końcowy rfc5424.
telemetry.logs.local.rfc5424.facility n/d Określa kod obiektu na rfc5424. Przykład. 7
telemetry.logs.local.journal.endpoint n/d 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żkę pliku, adres IP:port lub nazwę hosta:port.

Oto przykładowa konfiguracja lokalnego rejestrowania:

    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"

Następne kroki