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

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

Как было

Раньше наш мониторинг можно было описать так: куча очень умных людей ожесточенно программируют пробники на очень сложных языках, пытаясь замониторить все, что попадает в поле зрения. Несчастный заказчик, заходящий к ним побеседовать, сначала должен был заполнить десятки разных опросников и файлов, а потом долгое время отходить от услышанных слов вида “SNMP-трапы”, “пробы”, “агенты”.

Затем у нас появился E2E-мониторинг, способный эмулировать некоторые клиентские операции, именно так мы тогда и мониторили работу наших сервисов. Но были и печали: чтобы E2E в принципе начал что-то мониторить, нужно было составить ФТ объемом страниц эдак в 50 А4, а потом потратить несколько месяцев на разработку

Хватит это терпеть

Какое-то время, конечно, всё работало, но затем к нам пришли с тремя довольно логичными запросами:

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

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

3. Сделать так, чтобы инциденты решались быстрее.

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

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

Мы начали паниковать

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

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

Другие интеграторы считали, что первые интеграторы пытаются нас нагреть, и предлагали менее красивые графики и кружочки, но уже по $500 тысяч.

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

Как стало

Первый успех

Отвечающие за сервис менеджеры были счастливы: они увидели, кто и как пользуется приложением, какие у кого есть ошибки. И даже нашли ошибки в работе приложения, которые начали исправлять

 — Ура! Мы спасены, — подумали мы, ведь теперь мы можем замониторить вообще любое приложение. Для этого нужны лишь логи такого приложения и смекалистый сотрудник, который сможет с ними работать.

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

Зато появилась первая умная мысль – а что, если мы не должны сами всех замониторить? Что, если мы сделаем платформу, у которой будут умные, современные инструменты, с помощью которых все заинтересованные смогут сами себя ставить на мониторинг? В идеале вообще автоматически. 

Вместе с этим стало понятно, что на одном парсинге логов мы далеко не уедем. Во-первых, это все-таки долго. Во-вторых, далеко не все приложения могут логи предоставить. В-третьих, логи занимают очень много меcта.

Что мы начали делать? Ну, вы уже поняли. Паниковать.

Метрики

Вместе с паникой (продуктивная штука!) появилась вторая умная мысль – нам нужно больше инструментов, с помощью которых умные дяди смогут сами ставить себя на мониторинг, но при этом они должны еще сделать так, чтобы все увидели, как работают процессы внутри систем или продуктов. Так у нас появился еще один инструмент – метрики. Если точнее Prometheus.

И это умная мысль номер три, которую мы начали продвигать - метрики – это то, что должно у вас (в приложениях) быть! Это то, что вы должны заложить в разработку вашей системы или продукта. Потому что метрики – это то, что показывает в онлайн-режиме как работает и живет ваш продукт.

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

Вы можете в онлайне оперировать тысячами и сотнями тысяч метрик, и при этом только вы решаете – какие метрики вам нужны.

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

Отлично, мы научились работать с метриками, с их отправкой и сбором. И перестали паниковать. Потому что встали на правильный путь.

Инфраструктура

У нас есть логи. У нас есть метрики. У нас есть Zabbix. Zabbix! Мы забыли про Zabbix

Zabbix. Это наш мониторинг инфраструктуры, именно он следит за тем, как работают наши сервера, наши БД, наша сеть и многое другое. Это немного напоминало старые пробники, хоть и в более красивой и легкой обертке, что было немного скучно. И мы начали его прокачивать, чтобы стало весело.

Первым делом мы сделали интеграцию с CMDB и начали строить ресурсно-сервисный мониторинг.

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

Какую цель мы этим преследовали? Если раньше на дашбордах в Zabbix или Grafana было куча графиков и панелей – сейчас вы хотим, чтобы были видны «Проблемы». При правильно настроенное ресурсно-сервисной модели и зависимостях – не надо будет смотреть на графики. Нужно смотреть на «проблемы».

Если к разработчикам нужно идти за метриками, то к эксплуатации — за триггерами и зависимостями

Зачем это нужно? Чтобы, когда придет день X и «Шеф, все пропало» не бегать в поисках причины, а открыть один экран и увидеть, что «Все пропало, потому, что в приложении А, очередь из транзакций к приложению Б, потому, что приложение Б не работает. А приложение Б не работает из-за того, что на сервере C приложения Б проблема с местом на диске».

Что у нас получилось на тот момент? У нас были Prometheus, Zabbix и Grafana. И если наложить эти данные на один дашборд – с большой вероятностью можно увидеть причины и следствия в проблемах в работе продуктов или приложений. 

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

Увеличилось количество ошибок или уменьшилось количество транзакций (метрики!) – а вот и ответ в инфраструктуре. Это не всегда работает (ещё есть код приложения, но об этом дальше), но это тоже хороший способ начать коррелировать мониторинг инфраструктуры с мониторингом работы приложений (метрики).

Кто должен делать мониторинг?

К нам часто приходят с вопросами — а как нам замониторить наш продукт или сервис? К сожалению, у нас только один ответ – мы не знаем. Мы можем помочь с инструментами и сказать, как правильно это сделать, но какие параметры вам нужно мониторить и что вывести – не знаем. Кто знает? Владелец продукта или продуктовая команда.

Кто отвечал за мониторинг приложения 10 лет назад? Администратор. Почему? Потому, что это была его зона ответственности

Кто сейчас отвечает за работу мониторинга? Его разработчик! 

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

Именно разработчик в 2021 году отвечает за то, чтобы работал мониторинг. Идите к вашим разработчикам и требуйте, чтобы они думали про мониторинг. А мы будем думать том, чтобы ему было легко отдать разработанное решение в мониторинг

Хороший мониторинг — автоматический мониторинг

Это приводит к следующему вопросу – а кто в итоге должен быть в команде наблюдаемости и какие люди нам нужны?

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

А потом мы подумали и решили – да и не нужны нам тогда гуру мониторинга. Эти гуру есть у нас, в наших продуктовых командах. Сейчас никого не удивишь ни ELK, ни Zabbix, ни Prometheus.

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

Автоматизировать вывод в мониторинг и подключение к инструментам! А это значит, что в команде должны быть DevOps, люди, которые знают, что такое .net. Знают, что такое C# и C++. А если они знают это, то уж с ELK и Prometheus разберутся. И именно таких сотрудников мы стали искать. И нашли.

Никому не нравится писать конфиги для подключения к ELK. И уж совсем скучно рисовать графики в Grafana.

Для этого есть API! API в Elastic, API в Grafana. API в Prometheus. API в систему управления инцидентами

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

Транзакции

Отлично. Мы стали почти крутыми. У нас есть прокачанный Zabbix. У нас есть логи. У нас есть метрики и мы сможем все автоматизировать. Что дальше?

Если посмотреть статистику обращений в HelpDesk, в топе всегда будет “Не работает приложение X. Медленно работает приложение Y. Зависло приложение Z”.

Что дальше? Дальше – «У нас все работает, проблема у пользователя», «У нас проблем нет, проверяйте сеть\проверяйте базу данных\проверяйте сервер\а где скриншот\виновато солнечное затмение», в итоге ответ «Перезагрузите ПК» и чудо — заработало.

К сожалению, ни одни из тех инструментов, которые у нас есть, точно ответить на этот вопрос ответить не сможет. Что делать? Паниковать? 

Впереди нас ждет новый инструмент – трассировка транзакций, а именно стандарт OpenTelemetry

Трассировка транзакций – это как рентген для человека. Мы будем видеть, какая процедура или элемент кода выполняется в приложении в конкретный момент времени. Какой запрос к БД работает, а это значит, что мы будем видеть – сколько времени это занимает, и мы будем знать ответ на вопрос «Почему я нажал на кнопку, а ответ через 10 секунд» — мы увидим, на что именно эти 10 секунд была потрачены.

Планы на будущее

Мы крутые? Да. Но надо стремиться к большему.

1. Логи? Да, мы парсим логи ради мониторинга, чтобы показать метрики тем, кто не научился работать с Prometheus, это значит, что нам нужно научиться метрики из логов хранить как метрики, а логи удалять

2. Метрики? Да, но, если есть Zabbix, Prometheus и логи — это все свои хранилища данных, нам нужно научиться хранить все данные в одном месте. Зачем? Чтобы научиться предугадывать аварии! Да, нас ждет ML.

3. Логи? Да, некоторым администраторам нужны логи как логи, чтобы понимать, почему они падают. Хранить логи в ELK? У нас есть приложения, которые в день пишут 1 ТБ логов. И хранить такие логи нужно месяц. И это еще с репликацией. У нас не хватит столько места, чтобы хранить все логи, да и стоимость хранения и владения такими объёмами будет слишком велика. Это значит, что нам нужно научиться хранить логи в таком формате, в котором нам не потребуется отдельное здание и бюджет какой-нибудь Московской области для инфраструктуры под это.

4. Кто-то должен чинить и решать инциденты, которые будет генерить мониторинг. А чтобы они решались быстро – инциденты надо обогащать информацией. Правильной, о том, что сломало и на что это повлияло. Это значит, что в инциденте должна быть максимально подробная информация, желательно с примерами. И это информация должна собираться автоматически.

5. Мониторинг видит аварии и алармы. Их решают люди. Надо научиться автоматически исправлять типовые аварии, не привлекая к этому людей и давая им возможность спать. Невыспавшийся специалист — опасный специалист.

6. Машинное обучение. Аварии нужно не решать, а предугадывать и предупреждать.

1. И да. Мы крутые. Потому, что ровно год назад мы смотрели на картинки интеграторов с их умными системами и стоимостью под $1 млн и не понимали, как это чудо работает, а сейчас мы докажем любому интегратору с его коробкой, что его решение ничуть не лучше наших OpenSource.

   А теперь, еще раз, все умные мысли за один раз

Какие выводы мы сделали сами для себя

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

2. Метрики! Prometheus, Graphite не важно. Метрики! Метрики! Метрики!

3. Мониторинг инфраструктуры. Если его нет – далеко не уедите, потратьте время на то, чтобы его правильно настроить и пользоваться всеми возможностями. Глупо покупать машину с автоматической коробкой, но в пробках переключать передачи руками. Так и с мониторингом, используйте все его возможности. 

4. Современный мониторинг — это не тот мониторинг, который был 10 лет назад. Сейчас – это программный продукт! Современный программный продукт. С кучей API и доработок. И разработчики должны думать, как взаимодействовать с этим программным продуктом!

5. Хотите видеть, что происходит «внутри» приложения – добро пожаловать в мир мониторинга транзакций

6. Если вы думаете, что поставили на мониторинг авторизацию в приложении – и вы мониторитесь – нет, вы не мониторитесь, вы мониторите авторизацию. Разговоры о том, что смогли авторизоваться, значит приложение работает – оставьте потомкам. Ваше приложение работает не ради авторизации. В нем работают бизнес-процессы. Ставьте на мониторинг эти процессы. Берите лист А4, рисуйте схему работы процессов, точки входов\выходов. И ставьте эти точки на мониторинг

7. Google – найдется все.