Мониторинг Ingress‑контроллера¶

Ingress‑контроллер Вебмониторэкс предоставляет два набора метрик в формате Prometheus:

Кроме того, состояние нод отображается в Консоли управления Вебмониторэкс → Ноды.

Сбор метрик ноды¶

Создайте Service для метрик ноды:

controller:
  wmx:
    metrics:
      service:
        create: true
        annotations:
          prometheus.io/scrape: "true"
          prometheus.io/path: /wallarm-metrics
          prometheus.io/port: "18080"

Аннотации prometheus.io/* используются Prometheus с обнаружением сервисов по аннотациям. Если используется Prometheus Operator, создайте ServiceMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: wmx-ingress-node
  namespace: <KUBERNETES_NAMESPACE>
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: wmx-ingress
      app.kubernetes.io/instance: <RELEASE_NAME>
  endpoints:
    - port: wmx-metrics
      path: /wallarm-metrics
      interval: 30s

Для метрик Ingress‑контроллера Helm‑чарт может создать Service и ServiceMonitor сам: параметры prometheus.service.create и prometheus.serviceMonitor.create.

Метрики ноды¶

Метрики являются счетчиками с момента запуска NGINX, если не указано иное. Значения относятся к одному pod'у Ingress‑контроллера.

Трафик и блокировки¶

Ошибки и ограничения¶

Правила обнаружения атак¶

Ограничение количества запросов¶

Метрики wallarm_rate_limit_* описывают работу правил ограничения количества запросов: размер разделяемой памяти (shm_zone_size), количество отслеживаемых ключей (entries, buckets_count), задержанные (delayed) и отклоненные (exceeded) запросы, удаленные ключи (expired, removed) и ошибки выделения памяти (no_free_nodes).

Рекомендуемые оповещения¶

Диагностика¶

Команды ниже используют переменные:

NS=<KUBERNETES_NAMESPACE>
CONTROLLER=deploy/wmx-ingress-controller
POSTANALYTICS=deploy/wmx-ingress-wmx-postanalytics

Pod'ы не запускаются¶

kubectl -n $NS get pods
kubectl -n $NS describe pod <POD_NAME>

Pod'ы Ingress‑контроллера и постаналитики при запуске регистрируют ноду (init‑контейнер addnode). Проверьте журнал регистрации:

kubectl -n $NS logs $CONTROLLER -c addnode

Успешная регистрация завершается сообщением Installation finished. Частые причины ошибок: неверный токен, нет доступа к api.webmonitorx.ru, сертификат API не проходит проверку (certificate verify failed) — для API с сертификатом собственного удостоверяющего центра задайте controller.wmx.api.caSecret.

Ошибки синхронизации с Вычислительным кластером¶

Сервисы, которые синхронизируют данные с Вычислительным кластером (sync-ip-lists, sync-ip-lists-source, sync-sessions-lists, sync-antibot-data, syncnode, export-environment, sync-markers), при ошибке записывают ее в журнал и повторяют попытку через 5 минут:

ERROR sync-ip-lists-source exited with 1, next attempt in 300s

Ingress‑контроллер при этом продолжает работать: недоступность Вычислительного кластера или его файлов не останавливает pod'ы. Устраните причину по сообщению перед этой строкой, например:

• Could not download IP lists from mmdb — нода не загрузила базу геолокации IP‑адресов, нужную для блокировки по странам, регионам и дата‑центрам. Адрес загрузки выдает API Вычислительного кластера; проверьте доступ из кластера к этому адресу (для облака — storage.yandexcloud.net). Ошибка incorrect header check (Zlib::DataError) означает, что вместо файла вернулась ошибка (страница прокси, ошибка хранилища): на on‑premise установке проверьте журнал сервиса ipfeeds-s3-proxy.
• certificate verify failed — сертификат API не проходит проверку, см. controller.wmx.api.caSecret.

Остальные сервисы ноды при неустранимом сбое завершают свой контейнер, и Kubernetes перезапускает его: такие сбои видны по счетчику RESTARTS в kubectl get pods.

Атаки не отображаются в Консоли управления¶

1. Проверьте, что для Ingress включен режим фильтрации: в сгенерированной конфигурации NGINX должна быть директива wallarm_mode:

   kubectl -n $NS exec $CONTROLLER -c wmx-ingress -- \
     grep -h wallarm_mode /etc/nginx/conf.d/<INGRESS_NAMESPACE>-<INGRESS_NAME>.conf
   

   Если файла нет, Ingress не принят контроллером: причина указана в событиях Ingress (kubectl describe ingress <INGRESS_NAME>). Проверьте класс Ingress (spec.ingressClassName) и наличие другого Ingress с тем же хостом.

2. Проверьте, что правила загружены и запросы передаются в постаналитику: метрики wallarm_proton_instances{status="success"}, wallarm_tnt_errors, wallarm_requests_lost.

3. Проверьте выгрузку атак из постаналитики:

   kubectl -n $NS logs $POSTANALYTICS -c export-attacks --tail=20
   

   При успешной выгрузке в журнале есть сообщения exported N requests.

Журналы сервисов ноды¶

Каждый сервис ноды работает в отдельном контейнере; журналы выводятся в стандартный вывод контейнера:

kubectl -n $NS logs $CONTROLLER -c syncnode --tail=20

При обращении в техническую поддержку приложите журналы контейнеров addnode, syncnode, wmx-ingress и export-attacks, а также вывод kubectl -n $NS get pods -o wide.

• Список метрик ноды
• Метрики F5 NGINX Ingress Controller