“С большой силой приходит большая ответственность”
– дядя Бен (к\ф “Человек-паук”)

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

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

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

• Инфраструктура выросла в 10 раз за 3 года;

• Клиентская база увеличилась в 20 раз;

• Появились тысячи интеграций с заказчиками;

• Успешно прошли сертификацию ФСТЭК и ежегодно подтверждаем PCI DSS.

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

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

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

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

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

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

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

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

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

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

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

• Используем 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 для бесплатного использования сервиса и другие полезные штуки.

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

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 – это стенд as a service для тестирования ключевых показателей работы ваших веб-сервисов.

Мы хотим превращать ваши потребности в реальные функции нашего инструмента для оценки веб-ресурсов и отвечать на главный вопрос – «а у нас точно всё хорошо?» для вас и ваших клиентов.

Заходите в наш Telegram-чат — будем рады пообщаться.