Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
ОБЛАСТЬ ПРИМЕНЕНИЯ: Разработчик | Премия
В этой статье содержатся сведения о настройке локальных метрик и журналов для локально размещенного шлюза , развернутого в кластере 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, вы можете включить
Локальный шлюз также поддерживает множество протоколов, включая 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 можно выбрать два способа изучения журналов:
- Использование коллекции 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=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, то предшествующий путь должен отражать это изменение.
Связанный контент
- Узнайте о возможностях наблюдаемости шлюзов управления API Azure.
- Узнайте больше о локальном шлюзе управления API Azure.
- Узнайте о настройке и сохранении журналов в облаке.