Настройка локальных метрик и журналов для локального шлюза службы управления 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 развертывания локального шлюза с дополнительными параметрами. Ниже приведены доступные варианты.
| Поле | По умолчанию. | Description |
|---|---|---|
| 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 через локальный шлюз. Если все настроено правильно, можно будет просматривать приведенные ниже метрики.
| Метрическая | Description |
|---|---|
| requests_total | Количество API-запросов за интервал времени |
| request_duration_seconds | Количество миллисекунд с момента поступления запроса в шлюз до момента полной отправки ответа |
| request_backend_duration_seconds | Время в миллисекундах, затраченное на все операции ввода-вывода серверной части (подключение, отправка и получение байтов) |
| request_client_duration_seconds | Количество миллисекунд, потраченных на общее число операций ввода-вывода клиента (подключение, отправка и получение байтов) |
Журналы
По умолчанию локальный шлюз выводит журналы в stdout и по stderr. Журналы можно легко просмотреть с помощью следующей команды:
kubectl logs <pod-name>
Если локальный шлюз развернут в службе Azure Kubernetes, можно включить Azure Monitor для контейнеров для сбора stdout и stderr из рабочих нагрузок, а также просматривать журналы в Log Analytics.
Локальный шлюз также поддерживает множество протоколов, включая localsyslog, rfc5424и journal. В следующей таблице перечислены все поддерживаемые параметры.
| Поле | По умолчанию. | Description |
|---|---|---|
| telemetry.logs.std | text |
Включает ведение журнала для стандартных потоков. Возможные значения: none, text, json |
| telemetry.logs.local | auto |
Включает локальное ведение журнала. Возможные значения: none, auto, localsyslog, rfc5424, journal, json. |
| telemetry.logs.local.localsyslog.endpoint | Н/Д | Указывает локальную конечную точку системного журнала. Дополнительные сведения см . в журналах локального системного журнала. |
| telemetry.logs.local.localsyslog.facility | Н/Д | Задает код объекта локального системного журнала. Пример: 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"
Использование локальной конечной точки JSON
Известные ограничения
- Мы поддерживаем только до 3072 байт полезных данных запроса и ответа для локальных диагностика. Все, что выше, может нарушить формат JSON из-за фрагментирования.
Использование локальных журналов системного журнала
Настройка шлюза для потоковых журналов
При использовании локального системного журнала в качестве назначения для журналов среда выполнения должна разрешить потоковую передачу журналов в место назначения. Для 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 можно выбрать два способа изучения журналов:
- Использование коллекции Syslog с Container Insights
- Подключение и изучение журналов на рабочих узлах
Использование журналов из рабочих узлов
Их можно легко использовать, получив доступ к рабочим узлам:
- Создание подключения SSH к узлу (документация)
- Журналы можно найти в разделе
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=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"
Примечание.
Если вы изменили корневой каталог, chrootнапример chroot /host, приведенный выше путь должен отражать это изменение.
Следующие шаги
- Узнайте о возможностях наблюдаемости шлюзов Azure Управление API.
- Узнайте больше о локальном шлюзе Azure Управление API.
- Узнайте о настройке и сохранении журналов в облаке.