Мы делаем облако Amvera Cloud для хостинга IT-приложений.  Для нас мониторинг работы сервиса - дело первостепенной важности. Согласитесь, мало кто захочет хостить свои проекты в облаке, которое работает нестабильно. Мониторинг же позволяет сразу заметить сбой и принять меры. А если у вас сложный проект, состоящий из множества микросервисов, без сбоев не обойтись. 

К тому, что описано в статье, мы пришли через череду даунтаймов и багов, которые приходилось править “на горячую”. Происходили сбои во время бета-теста, но все равно тема обеспечения стабильной работы для нас болезненная. За знания пришлось заплатить дорогую цену - неудобства пользователей. Мы сами еще только на полпути к построению той системы обеспечения стабильной работы, какой нам бы хотелось ее видеть. Но надеюсь, наш опыт поможет кому-то не повторять наших ошибок и сразу все сделать правильно. 

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

Начнем с того, в каких случаях и какой мониторинг обычно используется.

1. Когда происходят инциденты, нужно найти причину и оперативно ее устранить. Соответственно нужны инструменты для расследования инцидентов. Обычно тут на помощь приходит анализ логов и трассировок.

2. Иногда полезно проактивно наблюдать за поведением метрик работы инфраструктуры и приложений. Для этого есть Grafana, визуализирующая метрики из Prometheus.

3. И наконец, полезно получать алерты, если что-то идет не так. Для этих задач есть Open Source инструмент - Sentry.

Так как коммерческие решения на нашем рынке либо совсем недоступны, либо их использование ненадежно, нами был выбран путь внедрения Open Source инструментов.

Мониторинг метрик

Проще всего было выбрать решение для мониторинга метрик. Есть отличная связка Grafana + база данных временных рядов от той же компании - Prometheus.

Решение написано на языке GO и работает очень быстро, устанавливается просто. Можно сказать, это было единственное, что не принесло проблем установки и эксплуатации. 

На самом деле, у Prometheus есть такое свойство: он может уходить в перезапуск, если ему не хватает оперативной памяти, и вы можете оказаться без мониторинга в самый ответственный момент. Говорят, чтобы побороть эту проблему можно использовать базу VictoriaMetrics. Сами с этой проблемой мы не сталкивались и решать ее не пробовали. 

Анализ логов

С анализом логов все оказалось сложнее. Классическое решение - использование ELK (Elastic) стека или его аналога Open Search с более открытой лицензией. Для своих задач мы пробовали использовать EFK (вариант ELK c Fluentd вместо Logstash), но столкнулись с рядом проблем. И если проблемы эксплуатации решаемы, то проблема нехватки нужного нам функционала уже была более серьезной. Классическим недостатком ELK является требовательность к выделяемым ресурсам. Кроме того, его нужно “уметь готовить”, чтобы он работал без сбоев и обеспечивал нужный уровень безопасности (известны случаи, когда из-за дыр в ELK были утечки информации и взломы). 

ELK (EFK) не решил все наши задачи. Нам нужно было не только анализировать логи самим, но и стримить их нашим клиентам в разрезе их проектов. К сожалению, с ELK реализовать эту задачу не получилось.

Мы написали свой сборщик логов, отправляющий их в MongoDB, откуда они транслируются клиентам. Откровенно говоря, это не лучшее решение, и работает оно не очень быстро, но на текущем этапе свои задачи решает.

Стоит сразу упомянуть, что если вам не нужно разделять логи по клиентам и их стримить, то можно использовать отличное Open Source решение — Grafana Loki. Оно еще немного «сырое» и из‑за архитектурных особенностей позволяет сохранять и обрабатывать логи только на коротком временном отрезке. Но если вы хотите, чтобы все просто работало и не требовало огромного кластера серверов (как ELK), то мы бы рекомендовали рассмотреть его как вариант.

Анализ трейсов

На текущий момент в анализе трассировок установился стандарт OpenTelemetry и распространен Open Source инструмент Jaeger.

Если вы не знаете, что такое трассировки, - приведем простой пример.

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

Это как герою в сказке нужно пройти ряд испытаний, прежде чем получить награду. На каждом испытании что-то может пойти не так, и каждое испытание занимает некоторое время. Вот наблюдение за этой “цепочкой испытаний”, только теперь в виде работы микросервисов, и называется анализом трассировок.

Уведомления об ошибках

Для уведомлений об ошибках мы выбрали Sentry со стримингом в телеграмм. Единственное, когда случается крупный сбой - это похоже на DDOS ошибками. Их становится очень много в канале и нужно следить, чтобы не упал сам Sentry.

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

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

P.S. Приглашаю поучаствовать в бета-тесте нашего контейнерного облака Amvera Cloud. В нем вы можете арендовать отдельные контейнеры и, как в Heroku, делать обновления через push в GIT (это удобно для небольших проектов, где не настроен полноценный CI/CD). На время бета-теста сервис полностью бесплатен. Потом мы зачислим всем 1000 руб. на баланс для продолжения использования облака, чего, в большинстве случаев, хватает на несколько месяцев. Буду благодарен за использование облака и обратную связь.