Привет всем! Полное содержание первого сезона можно прочитать тут и тут, а краткое содержание такое: 

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

• Мониторинг был разным (Patrol, Zabbix. NetCool), про Elastic. Про Prometheus, трейсинг и Grafana не слышали

• У всех команд эксплуатации были свои мониторинги, которые "что-то" показывали, но это все было разрознено и никак не связано

Привести все это «богатство» в адекватное рабочее русло, как-то структурировать и реструктуризировать было поручено команде супергероев, которые в перерывах между паниками (страшно было) взялись за дело

ВАЖНО: Тут не будет скриптов развертывания. Не будет рецептов и настроек систем (что-то есть в интернете, к чему-то пришли через пот и слезы). Это взгляд людей, которые развивают системы мониторинга и философию, которой они придерживается. Что еще важно – среди нас до момента развертывания не было людей, которые слышали про эти системы. 

Наш первый сезон мы закончили с таким багажом и знаниями:

• Был развернут кластер OpenDistro для работы с логами

• Был поднят Prometheus для тех, кто понимал, что такое метрики

• Выбрана Grafana как зонтик, для визуализации

• Было решено, что команды эксплуатации прекратят развивать свои мониторинги на чем попало, а пользоваться нашими коммунальными сервисами, которые вначале хромали, но пытались идти вперед

Итак, наступил второй год…

1. Интеграция мониторинга ITSM

Одним из первых решений, которые были приняты: все мониторинги (логи, метрики, трейсы, дашборды) должны быть интегрированы с CMDB. Какие цели преследовали:

• Чтобы объект наблюдения (сервер, приложение, базы данных, сервисы) в мониторинге и системах ITSM соответствовали друг другу (присутствует Конфигурационная единица — КЕ). 

• Чтобы, глядя на объект мониторинга, мы понимали, к какому элементу инфраструктуры относится этот график или алерт

Это давало большие возможности для анализа влияния аварий на конечных потребителей. Сработал алерт на каком-то сервере или БД → с помощью CMDB всегда можно построить связь и сказать: авария на сервере ХХХ повлияет на работу приложения YYY. Да, это будет работать при хорошо и правильно заполненной CMDB, но коллеги, которые отвечают за ITSM, стараются держать ее актуальной

Если говорить про практику, то во всех наших инструментах появилась связка с элементами инфраструктуры.

Как это выглядело в жизни: когда наша платформа наблюдаемости (а именно такое название внутри компании она получила — «Платформа наблюдаемости») запускалась, нам было важно сделать подключение систем к ней прозрачным (быстрым, легким, автоматическим). 

Никому не хотелось руками управлять таргетами, индексами, сразу были API'шки ELK и Prometheus и при оформлении запроса во внутренней система управления заявками – пользователь через несколько минут мог получить логи и метрики. Соответственно, мы ввели правило, что:

• При создании индекса в Elastic команда получает индекс, в котором по внутренним правилам формируется код приложения из CMDB.

• При подключении таргета Prometheus команда получает в лейблах код приложения

• Zabbix — на уровне группы узлов создается группа «Приложения», в котором в дальнейшем из CMDB добавляются все сервера и БД

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

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

Кроме расчета влияния у нас появилась возможность строить обогащенные дашборды (все связано по идентификатору приложения) и предоставлять разную аналитику, например

• Дашборд, на котором автоматически появляется информация по инфраструктуре из zabbix'a, обогащается логами из ELK + метрики приложения из Zabbix'a или Prometheus + аналитика из CMDB.

• Мы стали легко контролировать какие системы к каким инструментам мониторинга подключены, и кто чем пользуются (создали тепловую карту мониторинга).

2. Интеграция мониторинга c системой управления инцидентами

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

В итоге — куча мониторингов, надо бегать по дашбордам, смотреть, чего и где. Долго и неудобно.

Был реализован функционал, который позволял (опять же, по данным CMDB) запросить информацию (из инцидента в мониторинги), а есть ли новые аварии по работе приложения -> бралась ресурсно-сервисная модель приложения из CMDB → и по выявленным связям опрашивался мониторинг (а что в мониторинге по данным КЕ) → это позволяло на лету, не заходя в сотни графиков, получить информацию о состоянии здоровья приложения. 

Причем работало это сверху вниз (Приложение → БД → Сервера) и снизу-вверх (Сервера → БД → Приложение)

Как прокачивались наши системы мониторинга за последний год

3. Zabbix

Zabbix стал помогать инфраструктуре в разной аналитике и сборе информации. На него были возложены разные задачи дискаверинга (все с использованием API zabbix’a и внешними скриптами), причем, разной глубины

• Мы смогли реализовать функцию, которой из коробки в нем нет — сбор утилизации с хостов Unix по процессам, в результате выполнения этой задачи мы смогли собирать со всех наших Unix-хостов (а их больше 10 000), какие процессы запущены и сколько ресурсов они потребляют, а дальше уже можно заняться аналитикой и подумать, почему один и тот же процесс на разных серверах утилизируется по-разному

  

• Zabbix стал инструментом поиска и анализа какое ПО стоит на серверах-unix (например, найти все установленные Jira или Tarantool).

• С помощью Zabbix’a стала наполняться CMDB по части появления новых серверов (именно железных серверов), как только на сети появляется новая «железяка», Zabbix идентифицирует ее и отправляет о ней данные в CMDB.

• Zabbix контролирует локальный вход на сервер (Unix), определяет IP-откуда был вход, под каким логином, все это дальше анализируется с помощью эластика и выводится в Grafana. Это дало возможность отслеживать цепочки проходов по серверам и определять начальную точку откуда было подключение (было много задач по безопасности инфраструктуры после весны 22).

• Ну и сейчас наш Zabbix мониторит не только работу инфраструктуры, но и рабочие места (ПК, Ноуты и VDI).

• И много-много другого.

Да, возможно, не все наши сценарии – профильные для Zabbix’a и есть профильные инструменты, но тут вопрос в том, зачем развивать что-то новое, если можно допиливать текущее. 

Для расширения функционала Zabbix'a используются внешние скрипты, которые запускаются на уровне агентов (или user param) и собирают требуемую информацию.

4. Grafana

Как мы ее называем – лицо мониторинга, а лицо должно быть молодым, красивым и без морщин. 

В прошлом году мы перешли на версию 8.5.10 (с 7.5). Как я сказал ранее — у нас стали появляться дашборды, которые обогащаются информацией не только из мониторинга, но и других систем. 

• Например, мы можем показывать утилизацию по серверам и сразу показывать информацию из CMDB о местоположении оборудования

• Есть дашборды здоровья систем, где информация по приложению, некая аналитика какие ресурсы использует система, тут же графики инфраструктуры по серверам, базам данных, которые связаны с системами.

Это привело к тому, что мы стали зависимы от работы плагинов. Из «коробки» ни одна из восьмеров не завелась. Мы очень много времени потратили на поиск и выбор стабильной версии, которая работала бы со всеми нашими плагинами и в которой работали бы дашборды, которые созданы.

Тестировали все версии, смотрели, как они себя ведут. Были версии, где работают дашборды эластика, но не работает zabbix. Были версии, в которых работает zabbix, но не работает алертинг. Были версии, где работают все плагины, но проблема с алертингом. 

Были версии, где все работает, но рассыпаются дашборды (не работает обогащение).

Был момент отчаяния, потому что стабильных версий не было. В какой-то момент вышли на разработчика плагина для Zabbix’a, которому показали ошибку, и он внес исправление в один из патчей. Да, сейчас в плагине Zabbix’a есть исправления, которые помогли сделать мы ☺

В итоге, пазл сошелся, и мы смогли обновиться на версию 8.5.10.

Еще одна плюшка – для OSS-версии: прикрутили сквозную авторизацию с помощью ADFS и смогли избавиться от необходимости вводить логины\пароли.

Что сейчас представляет наша Grafana — это много дашбордов. Пожалуй, очень много, думаем, как их немного оптимизировать, удалять лишнее, не используемое и т.п. Для оптимизации сократили срок хранения аннотация до 1 месяца и количество версий дашбордов

Если говорить про проблемы — у нас стали очень часто прилетать алерты с «no data» для алертов, которые настроены в Grafana.

Как это исправлять, было непонятно. Дело было не в источниках данных, они были доступны.

Вывели логи Grafana в наш эластик, и на моменте срабатывания лишних алертов обнаружили, что БД Grafana очень часто блокируется. На тот момент у нас использовалась коробочная БД (SQLite). Кроме того, было видно, что расчет алертов (по метрикам Prometheus) занимает очень много времени. Было понятно, что мы уперлись в производительность SQLite. Начали прорабатывать миграцию с SQLite на PostgreSQL

После перехода на PostgreSQL проблемы ушли. Остался неприятный осадок, что надо было сразу делать Grafana на PostgreSQL, но, кто знал

Что дальше в планах

• Высокодоступное решение Grafana с двумя инстансами

• Миграция на 9\10 версии

• Monitoring as code (создание дашбордов из git’а)

5. ElasticSearch

Наше больное место, в тоже время – гордость ☺

Эта система за последний год выросла в 10 раз. Закончили мы 21-й год с 3 data—нодами, единственным сервером Logstash и сервисом, который мог упасть, и мы не знали, что с ним делать и как поднять. 

22-й — с 35 серверами (hot\cold) и семью Logstash.

Ну а теперь, пару слов о скачке, который мы сделали.

Какая самая большая проблема с эластиком у нас была — он работает не так, как написано в книжках (интернете). Если взять любую книжку\статью по эластику — в ней даны рекомендации по ресурсам, по настройкам, по масштабированию. Это все ерунда и все это работает на относительно малых объёмах данных

Везде указано плюс-минус 600 шардов на сервер, такой-то объём оперативный памяти на дата-ноде, такой-то объём оперативной памяти на серверах LS. Столько-то worker’ов на filebeat, столько worker’ов на logstasg.

Не работает. В жизни все иначе.

Мы не всегда успевали подкидывать дрова новые сервера к эластику, это приводило к тому, что он начинал работать медленно или падал (и поднимался по 12 часов).

Да, это звучит наивно, но с нами не было людей, которые знали эластик. Не у кого было спрашивать, что и как делать ☺ Или признать, что проиграли, или учиться-учиться и еще раз учиться

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

Мы начали разрабатывать несколько сценариев потребления данных и стратегий развития, в итоге определили 4 главных:

• Разные JDBC запросы. Да, есть команды, которые используют эластик для хранения результатов выполнения селектов. По факту, это такой расширенный мониторинг с помощью метрик (ну, или мониторинг для бедных, как мы его называем).

• Наиболее критичные системы. Наши сайт, Мобильное приложение, все, с чем работают клиенты.

• Работа с данными через API (отправка напрямую в ELK).

• Просто системы, которые хранят свои логи и отправляют через Logstash.

Другой проблемой было то, как команды работают с данными

• У кого-то настроены дашборды в Grafana (соответственно, постоянное чтение).

• Кто-то проводит нагрузочное тестирование (постоянная запись).

• Кому-то нужна выборка за большой период. 

К этому моменту мы уже внедрили политики Hot\Cold (неделя hot\3 недели cold), но, разные пользователи своим поведением и сценариями работы с данными все равно могли влиять друг на друга. 

В итоге было принято решение разделять кластер Elastic на зоны (в терминах эластика). Мы имели все равно один большой кластер, но были выделены зоны (разные данные хранились на выделенных серверах и не пересекались друг с другом). 

У нас появились 4 независимые друг от друга зоны внутри большого кластера с разными политиками хранения данных и управления ими

• Зона для JDBC (со слабыми серверами).

• Зона для критичных систем.

• Зона для API.

• и общая зона.

Ближе к концу года мы выделили еще одну зону, в которой оказались индексы с нашего кластера k8s. Внутри кластера разрабатывается много продуктов, они все пишут логи, но у них появилась своя специфика, у них было много индексов, но малого размера. 

Для этих систем сделали отдельную зону, где для хранения данных начали использовать недельный паттерн, а не дневной

Как это ни странно звучит – но именно с эластиком мы сами стали потребителями нашего мониторинга. 

И именно эластик показал, что, если просто смотреть за мониторингом инфры – ничего не видно. 

У нас в начале года была картинка – утилизация CPU в норме. Утилизация RAM в норме. Все графики в норме – логов нет или они отстают (для некоторых систем - отставание 5 минут уже проблема). 

Нам нужен был очень глубокий мониторинг именно API самого эластика. API Logstash, чтобы видеть, как ведет себя конкретный pipeline. Сколько документов приходит. Сколько обработано. Сколько в очереди. Сколько с ошибками и не будет обработано. 

Только когда мы смогли вытащить на свои же дашборды в Grafana работу самого кластера – мы смогли побороть и понять, как исправить большую часть проблем. В этом нам помогли экспортеры Prometheus для ELK и Logstash.

Опят же – простой пример. У эластика есть рекомендация: чем больше worker’ов вы настроите на LS и на FB, тем быстрее будут разбираться логи. Смотрите утилизацию CPU, объём выделенной памяти. Это работает на определенном количестве данных, которые проходят через pipeline, и зависит от того, есть фильтр на входе или нет. 

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

И так, вот, копаясь день за днем. разбираясь в проблемах мы перешли от режима «У нас опять все пропало» в режим «А чего с ним еще делать, он работает»)).

Планы

Сейчас у нас в планах перевод на opensearch 2.6. Мы оставляем зоны, но кластеров станет 3

• JDBC. Мы вынесем в отдельный кластер, просто чтобы сократить в "большом" количество шардов. По согласованию, данные по JDBC нужно хранить год, решили построить маленький, но отдельный кластер

• DEV-логи. Из большого кластера будут вынесены все test\dev логи в отдельный. Проблему, которую хотим решить — нагрузочное тестирование. Основная "проблема" эластика в том, что он работает со скоростью самой нагруженной\медленной ноды на текущий момент. Если кто-то проводит нагрузочное тестирование и пишет большой поток, он все равно может влиять на остальных потребителей. В данном случае принято решение вынести эти логи отдельно.

• Основной кластер

6. Prometheus

Prometheus у нас появился в начале прошлого года и его использование увеличивалось с каждым днем. 

У нас был период хранения 2 дня (смешно, да☺?). Мы радовались, что дали людям огонь Prometheus, но пользователи требовали зрелищ большего срока хранения.

Подняли срок до 5 дней и… Prometheus продолжил работать. Работал себе тихо, не требовал внимания, пока в один прекрасный момент мы не стали упираться в память. Сначала ее было 64, 96, 128, 192 gb ram…

В один прекрасный день Prometheus перезагрузился и не захотел подниматься… ему не хватало 192 gb ram, чтобы считать все wal’ы. Быстро добавить еще возможности не было, минуты шли, сервис отсутствовал, было уныние и тоска. Единственный выход, который был – удалить все метрики…. Пришлось это сделать… Нам повезло, что это была пятница вечер, впереди были 3 дня выходных (какие-то праздники были), когда сотрудники вышли на работу, о случившимся никто не знал. Новые данные были, старые, наверное, никто не запрашивал (простите нас), но это был звонок, что Prometheus надо развивать дальше. 

Во-первых, срок 5 дней был маленьким, во-вторых ресурсы с неба тоже не падают. Нужно было решить задачу, как хранить долго, надежно и дешево (без огромного ram’a).

7. VictoriaMetrics

Понимание, что VictoriaMetrics должна появиться в связке уже, было, нужно было только внедрить VM как хранилище, с этих проблем не возникло.

В фоновом режиме мы установили VM (пока single), перекинули таргеты, обновили Datasource в Grafana и пользователи даже не узнали, что вместо Prometheus метрики стали хранится в VM.

Вместе с этим мы подняли срок хранения до 7 дней

Но вместе с переводом на VM мы получили проблему с использованием SWAP. За 3-4 недели SWAP уходил в 0, побороть мы это не смогли, да, рестарт VM занимал несколько минут, не критично, но это было неприятно.

К этому моменту наша Платформа наблюдаемости уже получила известность (в хорошем смысле), и даже если рестарт самой VM для потребителей мог быть незаметен (если не считать алертов), это был наш внутренний удар по нам — не хотелось на это время оставаться без мониторинга. Соответственно, нам нужно было отказоустойчивое решение

Было принято решение переходить на кластерную версию VM. 3 Storag’a, 3 vm select’a, 3 vminsert’a. Техническую составляющую опущу, что и как сделано.

С переходом на кластер у нас ушла проблема с использованием SWAP (помогли настройки реплик, swap стал успевать возвращаться). Итого, у нас появился кластера из трех нод.

Все стало хорошо, но пользователи вошли во вкус и стали требовать все больший и больший срок хранения метрик.

Была неделя, потом две недели. Сделали три недели, но этого все равно было мало. Пришла пора разбираться с аггрегацией и vm agent’ами.

У нас возникли некие технические моменты и сложности при подключении этого решения, но проблемы мы смогли побороть. В итоге получили 2 уровня агрегации и 3 уровня хранения метрик

• Сырые данные – 3 недели

• 10 минутная агрегация – 3 месяца

• Часовая агрегация – 1 год

Сырыми данными и 10-минутными агрегатами пользуются команды для понимания того, как работали их продукты, а часовой интервал хорошо подходит для общей аналитики, показа SLA, SLI и т.п.

Да, сейчас для сбора метрик также используются vm agemt’ы. Как таковой Prometheus уже не используется

Что дальше? Прикручиваем vm alert и git (пока без подробностей).

8. Tracing

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

Мы выделили несколько серверов-коллекторов, к которому подключаются системы.

Для хранилища используем Elastic (сделали отдельный кластер, как раз, чтобы не было аффекта на обычные логи), данные хранятся без реплик, чтобы экономить место

Пока выставлен уровень сеплирования 40% и потихоньку увеличиваем этот параметр. Подключено примерно 250 сервисов.

Резюме

В целом, это все, что мы сделали за прошлый год. С одной стороны – много, с другой мало. Какие уроки мы вынесли:

• Никогда не опускать руки, даже если они опускаются, за темной ночью всегда приходит день © Бэтмен

• Нужно понимать, как конечные пользователи работают с системой 

• Учиться, учиться и еще раз учиться

Какие планы на этот год:

• Завершим переход на OpenSearch

• Monitoring as code (алертинг и дашборды)

• Обновим Grafana до 9 (или 10й версии) и перейдем на PostgreSQL

• Должны обновить Zabbix до 6 версии

Но. Это все технические работы. Какая наша философия: то, что у нас куча систем – удивить кого-то сложно кого-то. Сейчас у всех Zabbix’ы, Elastic’и, Grafan’ы – в этом ценности нет. Ценность в том, когда все связано между собой и работает в одной связке.

Мы построили платформу, которая собирает много данных, и это не только данные для мониторинга. Это аналитика и данные для других процессов. Нужно эти данные начать обрабатывать с другим взглядом. Каким? Расскажем в следующем году.

Если говорить о наших результатах в метриках (как же мониторинг без метрик), то они такие

• Elastic: Через наши logstash’и сейчас проходит до 200 000 транзакций (документов) в секунду

• Prometheus: Порядка 9000 таргетов и 500 000 сэмплов в секунду

• Zabbix: Обрабатывает ХХХ метрикс в секунду с XXX  элементов сети

• Grafana: 2000 активных пользователей (за 30 дней) и 2500 дашбордов 

PS И да. Одной из задач появления нашей платформы было сделать так, чтобы о сбоях в наших системах мы (компания) узнавали раньше наших клиентов. Удалось этого достичь? Да, наши системы позволили видеть проблемы раньше, чем о них узнаете вы ☺