kconmon-ng 2.0: как мониторинг сетевых пар нод раскрывает скрытые сбои в Kubernetes

Когда после обновления CNI или ядра между двумя конкретными нодами начинает теряться UDP, агрегированные метрики остаются зелёными — и вы узнаёте о проблеме только по жалобам пользователей. Инженер под ником amd-nord рассказал на Хабре, как перестал гадать и написал собственный мониторинг kconmon-ng. Инструмент проверяет связность каждой пары нод по TCP, UDP, ICMP, DNS и HTTP каждые пять секунд, а при сбое автоматически снимает MTR-трейс, пока проблема ещё жива. В версии 2.0.0 появилась веб-консоль с матрицей N×N, ранжированием причин без машинного обучения и алертингом, который генерирует настоящий PrometheusRule.

Что такое kconmon-ng и почему он нужен

kconmon-ng — это open-source инструмент для мониторинга сетевой связности между всеми парами узлов в кластере. Он устанавливает агента на каждую ноду, и агенты обмениваются пробами: TCP-соединения, UDP-пакеты, ICMP-эхо, DNS-запросы и HTTP-запросы. Каждая пара проверяется каждые пять секунд, что позволяет заметить проблему практически мгновенно. Когда проверка падает, агент автоматически запускает MTR-трейс, чтобы зафиксировать путь и потери пакетов, пока инцидент ещё не закончился. Все метрики собираются в Prometheus, который служит хранилищем и основой для алертинга.

Проблема, которую решает kconmon-ng, знакома каждому, кто управляет Kubernetes-кластером или распределённой системой: агрегированные метрики (например, процент успешных проверок) скрывают точечные сбои. Если 98% проверок успешны, дашборд зелёный, но именно оставшиеся 2% могут быть критичными — потеря пакетов между двумя конкретными нодами ломает работу распределённого хранилища или балансировщика. Обычные системы мониторинга (Prometheus, Grafana, Zabbix) не проверяют связность между всеми парами, а полагаются на единичные проверки или агрегаты. kconmon-ng закрывает этот пробел, предоставляя полную матрицу связности.

Версия 2.0: веб-консоль и новый алертинг

Релиз 2.0.0 добавил в проект полноценную веб-консоль, которая превращает набор метрик в удобный инструмент для расследования инцидентов. Главный экран — матрица N×N, где каждая клетка показывает статус пары нод по выбранному протоколу. Зелёные клетки — всё в порядке, красные — есть потери или ошибки. Клик по клетке открывает детали: историю проверок, результаты MTR-трейсов и возможные причины. Консоль позволяет фильтровать по протоколам, временным интервалам и конкретным нодам, что ускоряет поиск проблем.

Вторая ключевая функция — расследование с ранжированием причин. Без использования ML-моделей система анализирует паттерны сбоев: например, если все пары с одной нодой показывают потери, вероятная причина — проблема на самой ноде (сетевой интерфейс, драйвер, CNI). Если сбои наблюдаются только между двумя конкретными нодами, причина может быть в кабеле, коммутаторе или конфигурации маршрутизации. Алгоритм ранжирует вероятные причины на основе статистики и помогает инженеру быстрее локализовать проблему. Это особенно полезно для ночных инцидентов, когда нужно действовать быстро.

Какие функции веб-консоли помогают в расследовании инцидентов?

Веб-консоль kconmon-ng 2.0 — это не просто панель с графиками, а полноценный инструмент для диагностики. Помимо матрицы связности, она предоставляет детализацию по каждой паре: графики задержек, процент потерь, историю MTR-трейсов. Фильтры позволяют выбрать конкретный протокол или временной интервал, что особенно полезно, когда нужно сопоставить сбой с событиями в кластере. Например, если вы обновили Cilium в 02:00, а в 02:05 начались потери между нодами в разных зонах, консоль покажет это наглядно. Это превращает процесс расследования из гадания в методичную работу с данными.

Машина времени для разбора ночных инцидентов

Ночные инциденты — отдельная боль: пока вы спите, проблема возникает и исчезает, а утром остаются только общие графики. kconmon-ng 2.0 включает «машину времени» — функцию, которая позволяет откатиться к любому моменту в прошлом и посмотреть состояние матрицы связности именно тогда. Это работает благодаря тому, что Prometheus хранит все метрики, а веб-консоль умеет запрашивать их за произвольный интервал. Вы можете увидеть, когда именно начались потери, какие пары были затронуты, и сопоставить это с событиями в кластере (обновления, изменения конфигурации). Такой ретроспективный анализ часто выявляет скрытые зависимости и помогает предотвратить будущие сбои.

Алертинг в версии 2.0 стал более гибким: правила можно описывать в декларативном виде и компилировать в настоящий PrometheusRule. Это означает, что вы можете определить условия срабатывания (например, потери UDP более 1% в течение пяти минут для любой пары) и интегрировать алерты с Alertmanager. Таким образом, уведомления приходят в Telegram, Slack или по электронной почте, когда проблема действительно критична. Правила можно настраивать отдельно для разных протоколов и групп нод, что снижает количество ложных срабатываний.

Предыстория и контекст

Проект kconmon-ng возник из личной потребности автора, который столкнулся с трудноуловимой проблемой после обновления CNI. Традиционные инструменты мониторинга не давали ответа, поэтому он решил написать своё решение. На Хабре он поделился опытом, и сообщество оценило подход: инструмент развился от простого скрипта до полноценного продукта с веб-консолью. Сейчас проект размещён на GitHub, распространяется под открытой лицензией, и его можно адаптировать под свои нужды.

Подобные проблемы не уникальны: многие компании сталкиваются с тем, что агрегированные метрики скрывают точечные сбои. Например, в крупных кластерах с сотнями нод вероятность того, что одна пара имеет проблемы, высока. kconmon-ng — не единственный инструмент для проверки связности (существуют, например, cni-benchmark или сетевые диагностические утилиты), но он выделяется тем, что интегрируется с Prometheus и предоставляет удобную веб-консоль. Это делает его привлекательным для DevOps-инженеров, которые уже используют стек Prometheus.

Как работает мониторинг пар нод

Принцип работы kconmon-ng прост: на каждой ноде кластера запускается агент, который периодически отправляет пробы другим агентам. Для TCP это установление соединения, для UDP — отправка пакета и ожидание ответа, для ICMP — обычный ping, для DNS — запрос к DNS-серверу, для HTTP — GET-запрос к эндпоинту. Каждая проба фиксируется в Prometheus как метрика с метками sourcenode, targetnode, protocol. Это позволяет строить матрицу связности и вычислять процент потерь для каждой пары.

При обнаружении сбоя (например, потеря пакетов превысила порог) агент запускает MTR-трейс. MTR объединяет ping и traceroute, показывая потери на каждом хопе. Это бесценно для диагностики: вы видите, где именно теряются пакеты — на локальной ноде, на коммутаторе или на удалённом конце. Трейс сохраняется в Prometheus как набор метрик, и его можно посмотреть в веб-консоли. Если проблема кратковременная, трейс всё равно будет записан, что позволяет анализировать её постфактум.

Кого затронет и как

kconmon-ng будет полезен прежде всего DevOps-инженерам, SRE и администраторам Kubernetes-кластеров, которые отвечают за стабильность сети. Если вы когда-либо ловили себя на мысли, что агрегаты скрывают проблему, этот инструмент может стать вашим спасением. Он особенно ценен в средах, где используются CNI-плагины (Calico, Cilium, Flannel), потому что обновления этих компонентов часто приводят к точечным сетевым аномалиям. Также инструмент пригодится в распределённых системах хранения (Ceph, MinIO), где потеря пакетов между нодами критична.

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

Что будет дальше

Автор планирует продолжать развитие проекта. В ближайших планах — улучшение алгоритма ранжирования причин, добавление поддержки дополнительных протоколов (например, gRPC) и улучшение интеграции с Grafana для визуализации. Также возможно появление готовых Helm-чартов для установки в Kubernetes, что упростит внедрение. Сообщество может ожидать новые релизы с исправлениями и улучшениями, так как проект активно поддерживается.

Итог

kconmon-ng 2.0 — это практичный инструмент для тех, кто устал от слепых зон в мониторинге сети. Он позволяет видеть полную картину связности между всеми парами нод, быстро локализовать проблемы и расследовать инциденты даже задним числом. Если вы управляете кластером Kubernetes и хотите спать спокойно, попробуйте kconmon-ng — возможно, это именно то, чего вам не хватало.