company_banner

Организация системы мониторинга

    Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.



    За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь "инфраструктура" — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.


    Кроме проблем типа "упал сервер", "надо заменить винт в рейде", теперь надо понимать проблемы уровня приложения и уровня бизнеса: "взаимодействие с микросервисом таким-то замедлилось", "в очереди слишком мало сообщений для текущего времени", "время выполнения запросов к бд в приложении растет, запросы — такие-то".


    У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.


    Как было раньше


    Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.


    Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.


    Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.



    Как сейчас


    Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).


    Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.


    Все это нужно мониторить, потому что все это отражается на работе системы.
    И сами проблемы стали менее очевидными.


    Условно, проблемы можно поделить на две большие группы:
    Проблемы первого рода – не работает основная, “пользовательская функциональность”.
    Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.


    То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.


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


    Правильный мониторинг


    Проектирование и вообще


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


    Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.


    Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.


    Метрики и оповещения (алерты)


    Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.


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


    Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.


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


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


    Бизнес-показатели


    Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.


    Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).


    Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.


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


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


    Основные инструменты


    В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.


    Теперь по порядку.


    Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.



    Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.



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



    New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.



    Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.


    Заключение


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


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

    ITSumma

    53,48

    Собираем безумных людей и вместе спасаем интернет

    Поделиться публикацией
    Комментарии 25
      +14

      Ниачём.

        –7
        бомба!
          +1
          Что-то я думал, что это презентация своей системы. Когда начал читать минусы других систем, подумал ну теперь точно будут пиарить свою систему, а тут бац и заключение: «Хотите что-то нормальное — пишите свое.».
            0
            Это вы так аккуратно подводите к идее зонтичной системы мониторинга?
              –1
              Мне из систем мониторинга очень нравится DataDog. Из минусов — сложно настраивать кастомные метрики. Из плюсов — красивые графика, множество интеграций и агентов, частично бесплатный (для ограниченного кол-ва хостов).
                –1

                Основной минус DataDog — цена. 23$/хост/месяц — дороговато. Понятно, что своя инфраструктура мониторинга тоже стоит денег, но все же на порядок дешевле. Особенно если надо наблюдать за состоянием сотен хостов. Тот же Zabbix + Grafana прекрасно справляются с 1000 хостами\100 000 метриками.
                Ну а настраивать всё надо — нет волшебной системы которая сама определит проблему...

                0
                У нас ранее был на поддержке проект, с круглосуточной поддержкой и критичными для заказчика сервисами. Никакого особенного RocketScience там не было — виндовые службы (и их резервные копии на соседнем сервере), БД Оракл и ее резервная копия, переключалка БД, + не забился ли жесткий диск (логирование же), нет ли проблем с тэйблспейсами — всего 20-25 компонентов на 1 заказчика, заказчиков около 20. Мониторили работоспособность каждого компонента (делали софт сами).
                И честно говоря — без нормального описания процессов все это слабо работало. Дело в том, что тот кто следит за мониторингом — либо получает разумное количество сообщений в единицу времени и обрабатывает их, либо получает больше необходимого и на часть забивает. К тому же, у него есть еще и функциональные задачи + какую то часть времени он за мониторингом не следит (например поехал в отпуск или командировку) и мониторинг бесхозный и бесполезный, начинает присылать тонны сообщений.
                В итоге, так это и похоронили — слишком сложно для понимания, мало полезно.
                Идеальна система мониторинга, которая:
                а) не пишет ненужного, а пишет только по делу;
                б) суперлегко настраивается (типа развернул сервис, ввел параметры, подцепил процессы и забыл, а не обновлял БД и настраивал таблицы руками);
                в) легок в освоении для саппорта (сотрудник отвалился — новый сел, получил письмо и понял что там написано).
                Так же клево, когда менеджмент продумал и внедрил систему реагирования на события. Например в отделе работают Вася и Петя. Вася отвечает за мониторинг все будние дни. Петя отвечает за мониторинг все выходные дни, и дни когда Вася в командировке. Если мониторинг присылает письмо с проблемой, ответственный пишет в ответ «Принято в работу, номер тикета в саппорте 31337» и это рассылается на группу. Далее он работает по тикету в рамках текущего процесса поддержки, а когда инцидент решен — пишет в группу — «Инцидент решен — дело было в засорившемся логами диске С; по результатам создана проблема тикет 31338 — анализ использования места на ЖД для сервера N».
                Конечно, можно дофига к мониторингу прикрутить — нагрузку ЦП в пике, IO на ЖД, загрузку памяти и т.д. и т.п. — но нужна ли вам реально эта информация — на мой взгляд она отладочная, должна либо в лог писаться, либо это должно быть обнаружено на тестировании.
                Мониторить это у заказчика — не знаю, не знаю…
                Но статью плюсану, интересно, спасибо.
                  0
                  На самом деле, еще помимо prometheus есть go-graphite.
                    0
                    Тема мониторинга в современной ИТ среде не освещена, увы…
                    И не надо «изобретать велосипед». Есть BMC TrueSight Operations Management, в котором и Infrastructure & Cloud Monitoring, и APM, и End-User Experience Monitoring (Active & Passive), и Artificial Intelligence для анализа данных из разнородных источников и т.д.
                      0

                      Спасибо за статью. Поддерживаю комментарий выше про graphite. Мой опыт с мониторингом такой. Сначала InfluxData: telegraf, influxdb. И плюсом Grafana для alert-ов и графиков с таблицами. Telegraf потому, что он умеет мониторить всё, плагинов у него куда больше, чем у Prometeus. А InfluxDB развертывается в один клик на любой платформе. Когда производительности InfluxDB перестаёт хватать, а купить коммерческую версию не получается, тогда уже есть Graphite. В Graphite уже есть масштабирование. Или есть Prometeus, который гордится своим партицированием. Неизменными остаются telegraf, который умеет писать данные в Graphite и Prometeus. И Grafana, которая умеет их читать.


                      Чтобы иметь теоретическую возможность переехать, не надо в Grafana писать слишком сложные запросы к Influx (я уже успел написать). Чтобы потом не так долго их переписывать под другой синтаксис. А вообще надо бы сравнить скорость работы движков. Не сравнивал ещё. Но проседания скорости работы Influx ощущаю, на стандартных настройках. Её тоже надо уметь тюнить, и запросы в Grafana к Influx надо тоже писать оптимально.


                      Про информацию о New Relic тоже спасибо. Сейчас доволен работой JavaMelody — APM под Java, свою работу делает, open source. New Relic выглядит интересно — APM под все языки и технологии сразу. Его можно поставить внутри закрытого контура? Или он только как внешний сервис работает?

                        0
                        Спасибо за статью. Интересным и удобным показался PromHouse . С немаловажным нюансом — на настоящий момент он не рекомендуется к серьëзному проду. Но сколько возможностей к аналитике — и есть возможность дописать что-то своë специфичное под профиль подлежащих мониторингу процессов.

                        upd: парсер съел ссылку github.com/Percona-Lab/PromHouse
                          0
                          netdata?
                            0
                            Надеюсь будет продолжение с подробными деталями. Мне кажется, что вопрос мониторинга не в инструменте мониторинга (которые по функционалу все достаточно продвинутые было бы желание этим заниматься), а в четком определении регламентов, метрик, критериев алертов или предиктивного действия — что гораздо сложней. Check_MK закрывает большую часть вопросов любого мониторинга, если рассматривать как программный продукт, внутри её можно делать свои миры на Python. Жни, как-то попроще.
                              0
                              Очень поверхностная статья, почему то ни слова о том, что в prometheus есть alert manager, который умеет сильно больше, чем встроенный алертинг в prometheus.
                              Не говоря уже о том, что если у вас есть grafana с её алертами, у вас может быть любой сторадж под ней от graphite, до opentsdb — события по проблемам настраивать будет проще простого.
                                0
                                Дока Prometheus очень годная с Alerting Manager-ом.
                                Тема освещена достаточно неплохо:
                                shop.oreilly.com/product/0636920025986.do
                                shop.oreilly.com/product/0636920050773.do
                                — Плюс несколько глав из этой книги: shop.oreilly.com/product/0636920041528.do
                                  0
                                  Спасибо — вот эта книга Effective Monitoring and Alerting, действительно интересная.
                                  0
                                  > Prometheus — отличное решение для сборки огромного количества метрик… И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana.

                                  Так потому страшно и неудобно смотреть, потому что Графану юзать нужно. Я думаю, что так разработчики и хотят.
                                    0
                                    У elastic есть APM мониторинг с недавних пор, он ещё молод конечно но на него думаю имеет смысл поглядовать так как в отличие от того же newrelic он будет self hosted.
                                      0
                                      Если нужно self-hosted, можно и в сторону Appdynamics посмотреть
                                        0
                                        Appdynamics вроде как денег хочет. в случае с APM от elastic денег платить не нужно за сам APM (нужно за многое другое, но APM бесплатный).
                                          0
                                          У Appdynamics есть кое-что бесплатное типа мониторинга 1 приложения. А Elastic да, крутое решение особенно в свете развития всяких там *beat расширений
                                      0
                                      Причём здесь значок комедианта?
                                        0

                                        "Who watches the watchmen?"

                                        0
                                        К сожалению не приведено определение мониторинга. К сожалению многие понимают его по разному.
                                          0
                                          В плане описания подхода к мониторингу понравилась книга:
                                          Practical monitoring
                                          Обложка книги Practical monitoring с изображением варана

                                          Прочёл свободно доступную первую главу «Анти-паттерны»: conferences.oreilly.com/velocity/vl-ca/public/content/practical-monitoring, этого мне хватило. Содержимое перекликается с комментариями и дополняет тему статьи.

                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                          Самое читаемое