Настройка локальных метрик и журналов для локально размещенного шлюза управления API Azure

ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премия

В этой статье содержатся сведения о настройке локальных метрик и журналов для локально размещенного шлюза , развернутого в кластере Kubernetes. Сведения о настройке облачных метрик и журналов см. в этой статье.

Метрики

Локальный шлюз поддерживает StatsD, который является единым протоколом для сбора метрик и агрегирования. В этом разделе описаны действия по развертыванию StatsD в Kubernetes, настройке шлюза для выдачи метрик через StatsD и использования Prometheus для мониторинга метрик.

Развертывание StatsD и Prometheus в кластере

В следующем примере конфигурации YAML развертывается StatsD и Prometheus в кластере Kubernetes, где развернут локальный шлюз. Она также создает службу для каждого. Затем локальный шлюз публикует метрики в службе StatsD. Вы обращаетесь к панели мониторинга Prometheus через его службу.

Замечание

В следующем примере извлекает образы общедоступных контейнеров из Docker Hub. Настройте секрет доступа для аутентификации с использованием учетной записи Docker Hub вместо выполнения анонимного запроса на извлечение. Чтобы повысить надежность при работе с общедоступным содержимым, импортируйте образы и управляйте ими в частном реестре контейнеров Azure. Узнайте больше о работе с общедоступными образами.

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

Сохраните конфигурации в файл с именем metrics.yaml. Используйте следующую команду, чтобы развернуть все в кластере:

kubectl apply -f metrics.yaml

После завершения развертывания выполните следующую команду, чтобы проверить выполнение модулей Pod. Имя модуля pod отличается.

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

Выполните следующую команду, чтобы проверить, работает ли services. Запишите параметры CLUSTER-IP и PORT сервиса StatsD, которые вы используете позже. Панель мониторинга Prometheus можно посетить с помощью его EXTERNAL-IP и 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

Настройка локального шлюза для выдачи метрик

Теперь, когда развернуты StatsD и Prometheus, можно обновить конфигурации локального шлюза, чтобы начать создавать метрики через StatsD. Используйте ключ telemetry.metrics.local в ConfigMap самостоятельного развертывания шлюза, чтобы включить или отключить эту функцию. Можно также задать дополнительные параметры. Имеются следующие варианты:

Поле По умолчанию Описание
telemetry.metrics.local none Включает ведение журнала с помощью StatsD. Возможные значения: none, statsd.
telemetry.metrics.local.statsd.endpoint n/a Указывает конечную точку StatsD.
telemetry.metrics.local.statsd.sampling n/a Задает частоту выборки метрик. Значение может быть от 0 до 1. Пример: 0.5
telemetry.metrics.local.statsd.tag-format n/a Формат тегирования экспортера StatsD. Значение может быть none, , libratodogStatsD, influxDB.

Ниже приведен пример конфигурации:

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"

Обновите YAML-файл локального развертывания шлюза с помощью предыдущих конфигураций и примените изменения с помощью следующей команды:

kubectl apply -f <file-name>.yaml

Чтобы получить последние изменения конфигурации, перезапустите развертывание шлюза с помощью следующей команды:

kubectl rollout restart deployment/<deployment-name>

Просмотр метрик

Теперь, когда вы развернули и настроили все, локальный шлюз сообщает метрики через StatsD. Затем Prometheus выбирает метрики из StatsD. Перейдите на панель мониторинга Prometheus с помощью EXTERNAL-IPPORT службы Prometheus.

Выполните некоторые вызовы API через локальный шлюз. Если все настроено правильно, можно просмотреть следующие метрики:

Единица измерения Описание
requests_total Количество API-запросов за интервал времени
request_duration_seconds Количество миллисекунд с момента поступления запроса в шлюз до момента полной отправки ответа
request_backend_duration_seconds Количество миллисекунд, потраченных на общее количество операций ввода-вывода серверной части (подключение, отправка и получение байтов)
request_client_duration_seconds Количество миллисекунд, потраченных на общее число операций ввода-вывода клиента (подключение, отправка и получение байтов)

Записи

По умолчанию самостоятельно размещённый шлюз выводит журналы в stdout и stderr. Журналы можно легко просмотреть с помощью следующей команды:

kubectl logs <pod-name>

При развертывании самостоятельно размещаемого шлюза в службе Azure Kubernetes Service, вы можете включить Azure Monitor для контейнеров, чтобы собирать и из ваших рабочих нагрузок и просматривать журналы в Log Analytics.

Локальный шлюз также поддерживает множество протоколов, включая localsyslog, rfc5424и journal. В следующей таблице перечислены все поддерживаемые параметры.

Поле По умолчанию Описание
telemetry.logs.std text Включает ведение журнала в стандартных потоках. Значение может быть none, , textjson
telemetry.logs.local auto Включает локальное ведение журнала. Значение может быть none, , autolocalsyslog, rfc5424, journaljson
telemetry.logs.local.localsyslog.endpoint n/a Указывает локальную конечную точку системного журнала. Дополнительные сведения см. в журналах локального системного журнала.
telemetry.logs.local.localsyslog.facility n/a Задает код объекта локального системного журнала. Пример: 7
telemetry.logs.local.rfc5424.endpoint n/a Указывает конечную точку rfc5424.
telemetry.logs.local.rfc5424.facility n/a Указывает код объекта на rfc5424. Пример: 7
telemetry.logs.local.journal.endpoint n/a Указывает конечную точку журнала.
telemetry.logs.local.json.endpoint 127.0.0.1:8888 Указывает конечную точку UDP, которая принимает данные JSON: путь к файлу, IP:port или hostname:port.

Ниже приведен пример конфигурации локального ведения журнала:

    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"

Использование локальной конечной точки JSON

Известные ограничения

  • Функция локальной диагностики поддерживает до 3 072 байт полезной нагрузки запроса и ответа. Если размер полезных данных превышает это ограничение, фрагментирование может нарушить формат JSON.

Использование локальных журналов системного журнала

Настройка шлюза для потоковых журналов

При использовании локального системного журнала в качестве назначения для журналов среда выполнения должна разрешить потоковую передачу журналов в место назначения. Для службы Azure Kubernetes необходимо подключить том, соответствующий назначенному месту.

Учитывая следующую конфигурацию:

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

Журналы потоковой передачи можно легко запустить в эту локальную конечную точку системного журнала:

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

Использование локальных журналов системного журнала в службе Azure Kubernetes (AKS)

При настройке локального системного журнала в службе Azure Kubernetes можно выбрать два способа изучения журналов:

Использование журналов из рабочих узлов

Журналы можно легко использовать, получив доступ к рабочим узлам:

  1. Создайте подключение SSH к узлу (документация).
  2. Найдите журналы в host/var/log/syslogразделе .

Например, можно отфильтровать все системные журналы, чтобы только те из локального шлюза:

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

Замечание

Если вы измените корневой chroot, например chroot /host, то предшествующий путь должен отражать это изменение.