Когда все чеки зеленые, а клиентские чаты полыхают — это говорит о том, что где-то команда DevOps свернула не туда. Рассказываем историю о том, как мы устали от лавины алертов и собрали свой инструмент распределенного внешнего мониторинга. В статье делимся «внутрянкой», как все устроено и тем, какие грабли словили при развертывании системы.

Чем больше и распределеннее становится система, тем сложнее её мониторить и проводить аудит. Порой в тонне алертов, несомненно важных, можно забыть о самом главном — для кого и для чего создаётся ИТ-продукт. 

Как мы к этому пришли?

Мы, команда МУЛЬТИФАКТОР, в процессе развития нашего основного SaaS-продукта MULTIFACTOR прошли серьёзный качественный и количественный рост. Клиентская база увеличилась в 20 раз, из-за нее в 10 раз за 3 года выросла инфраструктура, появились тысячи интеграций с заказчиками.

В какой-то момент количество сред Kubernetes перевалило за десяток. Инциденты у 5% пользователей приводили к пожару у всего отдела продаж, вплоть до коммерческого директора. Стало ясно: нужны не только новые процессы, но и прозрачный инструмент распределённого внешнего мониторинга.

UptimeRobot и его аналоги были далеки от наших запросов — требовалось размещение серверов в различных регионах России, соответствие отечественным реалиям. Мы изучили рынок open‑source решений и решили создать собственный сервис. Так появился MULTISTATUS.

Что это такое?

MULTISTATUS — это распределенный облачный сервис анализа работы интернет-ресурсов.

Изначально система создавалась для собственных нужд, но по мере развития стало ясно, что она может быть полезна компаниям, которые хотят иметь полное представление о работе своих веб-сервисов и готовы делиться этой информацией со своими клиентами.

Какие задачи решаем с помощью своего решения?

Используя MULTISTATUS, мы:

1. Определяем доступность наших ресурсов из разных регионов;

2. Отслеживаем коды ответов не из внутренней инфраструктуры, а с внешних точек – как это видят клиенты;

3. Эмулируем действия реальных пользователей по цепочке событий;

4. Проводим регулярную диагностику – сканирование сетевого периметра;

5. Используем API MULTISTATUS в качестве health-check для балансировки трафика.

Что уже доступно?

Сейчас MULTISTATUS работает в режиме публичного тестирования — https://multistatus.ru/terminal

Воркеры (агенты, выполняющие проверки) развёрнуты в пяти точках мира: Москва, Санкт-Петербург, Новосибирск, Алматы, Амстердам.

Доступны базовые проверки:

• HTTP-check. Методы GET, HEAD, POST. Доступна авторизация и кастомные заголовки. Результат проверки – суммарное время загрузки по каждому региону;

• Ping. Простая проверка на доступность. Можно задавать количество запросов для каждого воркера;

• Traceroute. Да-да, старый добрый traceroute покажет путь запроса из каждого региона, в котором находится воркер;

• DNS. Получение информации о резолве из каждого региона. Доступны A, CNAME, MX, TXT, NS.

Остальные чеки выполняются из Москвы:

• Email. Получение информации о корректности настроенного почтового сервера;

• SSL. Цепочка сертификатов, срок действия и прочие показатели жизнеспособности.

В скором времени мы выкатим пробный API для бесплатного использования сервиса и другие полезные штуки.

Будем очень признательны, если протестируете MULTISTATUS и поделитесь обратной связью.

Сейчас мы активно дорабатываем систему, хотим сделать инструмент максимально удобным и полезным, и нам крайне важна обратная связь пользователей. Обсудить впечатления и высказать предложения можно в сообществе MULTISTATUS (мы действительно читаем все комментарии ;).

Что же под капотом?

Kubernetes, а точнее Talos OS. Давайте разберемся, как у нас всё устроено.

Схема сети построена по принципу «звезды» – в Москве расположены Mongo, RabbitMQ, Redis, Clickhouse, API и фронт, а в регионах работают только воркеры, выполняющие чеки.

В качестве CNI пока используем базовый Flannel, а для хранения экспериментируем с Ceph. Вся коммуникация между Москвой и регионами обеспечивается по IPsec-туннелям через Интернет. 

Как работает схема

Когда запускается проверка, API получает список «живых» воркеров (для этого используется Redis). 

Региональные воркеры отлично справляются с некритичными задержками до 100 мс до Москвы. Эта схема точно лучше, чем размазывать RabbitMQ по нескольким площадкам — привет, Network Partition. Что будет при задержках выше 200 мс, мы пока не знаем, но у нас есть запасной план — переход на HTTP.

Далее запрос на выполнение чека принимается API, и соответствующее сообщение кладётся в очередь для нужного типа чека и нужного города:

Воркер выполняет соответствующий чек и записывает результат в MongoDB и ClickHouse. 

Мы не хотим превращаться в DDoS-площадку, поэтому используем MongoDB как кэш. Если чек по конкретному URL уже выполнялся в течение последней минуты, то результат возвращается из базы. По истечении минуты запрос уйдет на воркеры, и мы получим новый результат.

Так мы определяем уникальный чек, повторное выполнение которого в рамках одной минуты будет производиться из кэша:

Вся схема с точки зрения внутреннего взаимодействия выглядит так:

ClickHouse используем как задел под дэшборды: статистика, аналитика. Мы активно работаем в этом направлении.

Как запускаются проверки

HTTP-check, ping, traceroute и другие проверки выполняются воркерами, написанными на dotnet. Всё уже придумано до нас:

private async Task<(string? Ip, long? responseTime, bool success)> ExecutePingCheck(string host)
    {
        using var ping = new Ping();
        
        try
        {
            var reply = await ping.SendPingAsync(host, 4000);
            var ip = reply.Address.ToString();
            var responseTime = reply.RoundtripTime;

            return (ip, responseTime, true);
        }
        catch
        {
            return (null, null, false);
        }
    }

Разумеется, для этого великолепия нужны соответствующие утилиты в контейнерах.

RUN apt-get update && \
    apt-get install -y --no-install-recommends iputils-ping traceroute && \
    rm -rf /var/lib/apt/lists/*

Изначально мы хотели дать возможность посылать «жирные» payload-запросы, но для этого требуется root-доступ, а нам эта история не очень нравится. Так что пусть будет так, благочинно.

Интересные фэйлы и волшебные команды

В ходе запуска и развития MVP у нас возник интересный случай, связанный с особенностями сетевой схемы «звезда». 

После неудачной попытки развернуть Ceph в Kubernetes большинство воркеров потеряли связь с API. В живых осталось только 2 агента — в Москве и Новосибирске. Мы удивились — почему жив воркер в Новосибирске, а не в Питере?

Разобравшись, поняли, что падающие воркеры не могли достучаться до RabbitMQ, а точнее — разрезолвить его адрес. Волшебная команда на ноде Talos (напомним: у нод Talos нет SSH)

kubectl -n kube-system debug node/spb-sel-worker-nodes-1 --image ubuntu --profile sysadmin -it

NAME              TYPE        CLUSTER-IP      PORT(S)                        
moscow-rabbitmq   ClusterIP   10.104.71.14    5672/TCP,15672/TCP,15692/TCP

NAME       TYPE        CLUSTER-IP   PORT(S)                  AGE
kube-dns   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   82d

и не менее волшебная команда проверки сетевой доступности RabbitMQ и DNS расставили все по местам: (0 — есть соединение, 124 — соединения нет). Оказался недоступен DNS.

root@spb-sel-worker_nodes-1:/# timeout 2 bash -c "</dev/tcp/10.104.71.14/5672"; echo $?
0

root@spb-sel-worker_nodes-1:/# timeout 2 bash -c "</dev/tcp/10.96.0.10/53"; echo $?
124

#Нет в Talos утилиты telnet и nc)

Несложно догадаться — проблема была в том, что поды CoreDNS под нагрузкой убежали за пределы МКАД, куда у воркеров нет маршрута. Решение — node affinity по лейблу location=moscow для деплоймента CoreDNS.

Куда движемся дальше?

Сейчас мы активно разрабатываем личный кабинет, где возможно будет:

• поставить свои ресурсы на мониторинг;

• получать базовый алертинг в Telegram;

• настроить звонки дежурному инженеру. Разумеется, вашему, а не нашему :) 

Также мы хотим предоставить возможность интеграции напрямую через наш API, чтобы вы могли создавать собственные активные health-чеки и наблюдать за поведением ресурсов в разных условиях.

А дальше — больше: статус-пейдж для прозрачности, служебные оповещения, сценарии пользователей, интеграции в Prometheus клиентов. 

Ваши потребности — наши функции

В процессе разработки MULTISTATUS мы убедились, что хороший мониторинг это не только метрики и аптайм, а понимание того, что реально видит пользователь.

Мы открыто делимся своим опытом и будем рады обратной связи: какие инструменты вы используете для внешних проверок, и как решаете похожие задачи в своих проектах?

Пишите в комментариях или в нашем сообществе в Telegram — обсудим архитектуру и подходы. Ну и приглашаем протестировать MULTISTATUS в бою тут)