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

Статья
06/09/2022
Чтение занимает 4 мин

В этой статье содержатся сведения о настройке локальных метрик и журналов для локального шлюза, развернутого в кластере 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

Выполните приведенную ниже команду, чтобы проверить, работают ли эти службы. Запишите 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	Недоступно	Задает конечную точку StatsD.
telemetry.metrics.local.statsd.sampling	Недоступно	Задает частоту выборки метрик. Значение может находиться в диапазоне от 0 до 1. Пример: `0.5`
telemetry.metrics.local.statsd.tag-format	Недоступно	Формат тегирования экспортера StatsD. Возможные значения: `none`, `librato`, `dogStatsD`, `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-IP и PORT службы Prometheus.

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

Метрика	Описание
Requests	Количество API-запросов за интервал времени
DurationInMS	Количество миллисекунд с момента поступления запроса в шлюз до момента полной отправки ответа
BackendDurationInMS	Время в миллисекундах, затраченное на все операции ввода-вывода серверной части (подключение, отправка и получение байтов)
ClientDurationInMS	Время в миллисекундах, затраченное на все операции ввода-вывода клиента (подключение, отправка и получение байтов)

Журналы

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

kubectl logs <pod-name>

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

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

Поле	По умолчанию	Описание
telemetry.logs.std	`text`	Включает ведение журнала для стандартных потоков. Возможные значения: `none`, `text`, `json`
telemetry.logs.local	`auto`	Включает локальное ведение журнала. Возможные значения: `none`, `auto`, `localsyslog`, `rfc5424`, `journal`, `json`.
telemetry.logs.local.localsyslog.endpoint	Недоступно	Задает конечную точку localsyslog.
telemetry.logs.local.localsyslog.facility	Недоступно	Задает код устройства localsyslog. Пример: `7`
telemetry.logs.local.rfc5424.endpoint	Недоступно	Задает конечную точку rfc5424.
telemetry.logs.local.rfc5424.facility	Недоступно	Задает код устройства для каждого rfc5424. Пример: `7`
telemetry.logs.local.journal.endpoint	Недоступно	Задает конечную точку журнала.
telemetry.logs.local.json.endpoint	127.0.0.1:8888	Указывает конечную точку UDP, которая принимает данные JSON: путь к файлу, IP-адрес:порт или имя узла:порт.

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

    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"

Дальнейшие действия

Дополнительные сведения о функциях наблюдаемости шлюзов API Azure.
Дополнительные сведения о локальном шлюзе см. в статье Общие сведения о локальном шлюзе управления API Azure.
Сведения о настройке и сохранении журналов в облаке