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

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

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

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

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

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

  3. Наконец, полезно получать оповещения в случае возникновения проблемы. Для этих задач есть инструмент с открытым исходным кодом — Sentry.

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

ЧИТАТЬ   Почему мы выбираем не тех людей и строим плохие отношения - Лайфхакер

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

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

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

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

Анализ журнала

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

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

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

ЧИТАТЬ   Собака нашла в лесу трехмесячного детеныша. Как за ним сейчас ухаживают — трогательное видео

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

Трассовый анализ

В настоящее время в анализе трассировок установлен стандарт OpenTelemetry и распространен инструмент Jaeger с открытым исходным кодом.

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

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

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

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

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

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

ЧИТАТЬ   Наследие ржавой реализации

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


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

Source

От admin