Уже четвёртый год я занимаюсь тем, что принято называть Observability. Опыт, полученный за это время, я излагаю в тексте, делюсь им с вами в виде размышлений и рекомендаций и представляю публике.
Технических подробностей здесь практически не будет — статья намеренно написана таким образом, чтобы изложенное можно было применить практически к любому стеку технологий.
Дело в том, что инструменты входят в тренды и выходят из них с невероятной скоростью, поэтому выбор за вами.
Давайте обсудим мониторинг.
О мониторинге в контексте метрик
Если вы спросите среднестатистического технического инженера, с чем связан мониторинг, он, скорее всего, ответит вам — «метрики приложения», а это будет подразумевать их сбор и некоторую визуализацию.Причём, как показал мой опыт, многие даже не задумываются об обратной стороне этого процесса — в понимании большинства «он просто показывается в Grafana/Kibana/Zabbix/подставляется на правильный».
Этот ответ, замечу, еще не полный, поскольку одними метриками все не ограничивается.
Точнее: мониторинг — это не только сбор метрик и отображение их на дашборде.
И с этого момента давайте посмотрим поближе.
Из чего состоит мониторинг?
Со временем я пришел к следующим аспектам:- Сбор метрик из различных источников – приложений, показателей хоста, «аппаратной» части сайта; Разницу в моделях pull и push мы пока касаться не будем, об этом позже.
- Запись и дальнейшее хранение их (метрик) в базе данных с учетом особенностей самой базы данных и использования собранных данных.
- Визуализация метрик, которая должна балансировать между возможностями выбранного стека технологий, удобством использования дашборда и «хотелками» тех, кому придется со всем этим работать.
- Мониторинг метрик по заданным правилам и отправка оповещений
- В случае расширенного мониторинга сюда можно добавить еще один пункт — выявление аномалий и проактивное информирование о деградации наблюдаемой системы на основе ML.
О сборе метрик
Итак, вы решили создать систему мониторинга.Первый шаг — подумать о том, какие метрики собирать:
- Показатели хост-системы и окружающего оборудования — загрузка ресурсов ЦП и ОЗУ, нагрузка на диски и сетевые устройства, статистика процессов, информация о состоянии платформы оркестрации и так далее; Всех их объединяет одно — такие метрики относятся к самому низкому уровню доступной вам инфраструктуры, с которой вы работаете.
Например, если вы предоставляете услугу по размещению виртуальных машин, вам потребуется мониторинг серверов виртуализации; и если вы выкатите свой продукт на сайт клиента, то это скорее всего будут виртуальные машины и/или кластер K8s
- Индикаторы поддерживаемых приложений — здесь появляется слой метрик, который можно связать с процессами, в корректности и стабильности которых вы непосредственно заинтересованы; это может быть гипервизор, ваше клиентское программное обеспечение или некоторые системные процессы.
На этом уровне становится возможным (а зачастую и необходимым) установить однозначную связь «инфраструктура-приложение».
В самом простом виде это может выглядеть так — вы отслеживаете состояние процесса «запущен/не запущен», прикрепляете к этой метрике теги с названиями хоста и приложения, по сумме которых можно четко определить, что именно этот показатель относится к
- Показатели бизнес-процессов – сюда входит информация, на основании которой можно сделать выводы о выполнении бизнес-функций.
В качестве примера возьмем операцию списания денег с лицевого счета пользователя - скажем, для успешного завершения операции необходимо, чтобы личный кабинет (веб-сервер), сервис задач очередей, брокер асинхронных сообщений, доступны платежный шлюз и база данных.
Чтобы быть уверенным в том, что операцию можно завершить, вам нужно будет следить за состоянием всей цепочки, хотя бы в самом простом виде — все ли в ней приложения запущены.
- Результаты дымовых испытаний по сути являются продолжением предыдущего уровня; это индикаторы периодически выполняемых фейковых бизнес-транзакций, которые можно использовать для выявления проблемы
Тяни против Толкай
Предмет бурных споров на тематических каналах и форумах с вечным вопросом – что лучше? Модель push — это когда у вас есть классическая база данных, в которую активно пишут агенты.Отличается большим объёмом точек настройки (обычно по количеству агентов мониторинга), но в то же время позволяет базе данных заниматься своей основной задачей — хранением метрик и управлением их жизненным циклом, пассивным ожиданием чего-то.
быть помещенным в него.
Насколько мне известно, модель извлечения — это относительно новый подход, который приобрел популярность с появлением платформ оркестрации контейнеров.
В этом случае сервер мониторинга сам обращается к пассивным экспортерам и снимает с них метрики.
Плюс — единая точка настройки, сам сервер, которому нужно сказать, что и откуда брать.
ИМХО, это и есть главный минус - при выходе из строя сети вы теряете производительность во время ее простоя.
Хорошо работает в эфемерных средах, таких как K8s, где количество объектов, которые необходимо отслеживать, со временем меняется.
Вне них уже не так удобно — для получения метрик с хостов потребуются агенты экспорта.
Выбор модели за вами – исходя из ваших потребностей и целей.
О хранилище
Я буду краток — на данный момент изобретено довольно много TSDB (баз данных временных рядов), специально предназначенных для временных рядов.Вам останется только выбрать то, что кажется наиболее приемлемым с точки зрения «доступный функционал – производительность – удобство и возможности языка запросов».
Мой личный фаворит ВикторияМетрикс , рекомендую посмотреть.
О визуализации
Точно так же, как метрики были разделены по уровням, визуализация разделена аналогичным образом:- Уровень сайта — это высший уровень визуализации, с которого после получения оповещения пользователь мониторинга должен начать работу.
Дашборды здесь представляют собой набор логически разделенных индикаторов «все хорошо/что-то сломано».
Например, на каждой панели отображается состояние группы приложений — Nginx, Apache, Virtualization Services; если есть проблема с каким-либо из объектов группы, панель переходит из состояния «все в порядке» в состояние «что-то сломано», привлекая внимание
- Уровень группы – следующий уровень, на который переходит пользователь; должен быть доступен по ссылке детализации на предыдущей информационной панели.
Если ранее мы выделили, с какой группой возникла проблема, то здесь мы должны ответить на вопрос «с каким групповым объектомЭ» Продолжая начатый выше пример, здесь отображаются все Nginx на вашем сайте, для которых отображаются ключевые показатели — состояния процессов, состояния подключения к базе данных, количество ошибок и так далее.
Здесь нет необходимости вдаваться в подробности; пяти-шести панелей на объект наблюдения будет достаточно
- Уровень объекта в большинстве случаев является конечной точкой движения нашего пользователя.
На этом уровне детально визуализируются метрики конкретного приложения/процесса/иного, подлежащих принудительному мониторингу.
Здесь пользователь должен найти для себя ответ на следующий вопрос: «что именно сломаноЭ» Начиная с этого уровня переходы между дашбордами должны наследовать контекст - если пользователь на уровне группы нажал на панель процессов.
nginx_01 хозяин прокси.
локальный , должны отображаться метрики именно этого приложения на этом хосте
- Уровень фрагмента объекта формально является продолжением предыдущего уровня, но введен он по этой причине: если какая-то часть нашего объекта имеет слишком много метрик и достойна рассмотрения отдельно, для нее создается персональный дашборд. Например, у нашего Nginx есть апстримы со своими метриками; Чтобы не усложнять уровень объекта и не перегружать его, под апстримом создаем персональный дашборд, а на предыдущем оставляем только кликабельные индикаторы с апстримом состояния «онлайн/частично онлайн/оффлайн».
Опять же, переходы должны наследовать контекст, чтобы пользователю было легче ориентироваться.
- Уровень инфраструктуры — это самый низкий уровень визуализации и отправная точка для сбора метрик.
Здесь отображаются индикаторы хост-системы и окружающего оборудования.
Неплохим ходом было бы разделить метрики разных частей на разные дашборды — состояние ЦП, ОЗУ, дисков и т. д., организовав возможность горизонтального перехода между ними.
Переход на этот уровень можно создать из двух предыдущих, опять же с учетом ранее установленного контекста; если пользователь посмотрел метрики приложения на хосте прокси.
локальный , должны отображаться показатели этого хоста
Пользователь мониторинга движется сверху вниз, анализируя инцидент Общие рекомендации:
- Создавайте шаблоны информационных панелей с возможностью задания контекста с помощью переменных.
Идея вполне очевидна, согласен, но, тем не менее, я сталкивался с хардкодом хостов и приложений, генерирующим кучу копий одних и тех же дашбордов, что приводит к неподдерживаемому хаосу.
- Также в переменные стоит помещать различные потенциально изменяемые вещи — имя базы данных с метриками, составленные вручную числовые словари и т. д.
- Добавьте описание ко всем панелям.
Если информация, отображаемая на панели, кажется хоть немного неочевидной, не поленитесь дать ей описание – буквально одно-два предложения значительно облегчат работу пользователей и помогут вам, когда возникнет необходимость вернуться к работе с панель приборов
Об оповещениях
Оповещение, пожалуй, самая важная часть системы мониторинга.На мой взгляд, при идеальном оповещении визуализация метрик вообще не нужна — хорошее, подходящее сообщение передает ровно столько информации, сколько необходимо для начала восстановительных работ. К сожалению или к счастью, в мире нет ничего идеального, но можно попытаться приблизиться к этому.
Итак, хорошее оповещение можно приготовить из следующих ингредиентов:
- Полнота сообщения – тело оповещения должно содержать информацию о Что именно произошло и на какой период время.
Пример: «Средняя загрузка процессора превысила 90% за последние пять минут»; пользователь, получивший такое сообщение, видит информацию, во-первых, о событии, во-вторых, о его продолжительности на момент получения, что позволяет сразу примерно оценить масштаб катастрофы.
Здесь стоит уточнить, что метрика обычно оценивается за определенный период, из которого выводится максимальное/среднее/минимальное/другое значение, а не ее мгновенный показатель - это позволяет сгладить (или выделить - зависит от того, что именно нужно) скачки и задержка доставки метрик в базу данных
- Уточнение метаданных – оповещение должно сопровождаться набором тегов/меток, раскрывающих контекст события; это может быть имя хоста, имя приложения, URI веб-сервера и т. д.
- Временная отметка первой активации - здесь все просто, в оповещении жизненно важна отметка времени, чтобы при получении уведомления вы могли понять, сработало ли у вас новое оповещение или старое все еще включено
- Ссылка на систему управления оповещениями/систему визуализации метрик, на ваш выбор - она нужна получателю, чтобы он мог сразу перейти к мониторингу, а не тратить время судорожно на поиск закладок в браузере
- Избегайте спама от системы управления оповещениями.
Когда вашего получателя забрасывают письмами/СМС/сообщениями от бота, он рано или поздно перестанет придавать им какой-либо смысл и будет пропускать критические уведомления.
Было бы неплохо настроить рассылку таким образом, чтобы для уже «горящих» оповещений через некоторое время приходили повторные уведомления.
- Выбирать ключевые метаданные и группировать по ним оповещения; тогда вместо, например, семи сообщений по одному объекту, ваш пользователь получит одно, в которое будут вложены остальные.
Это также позволяет уменьшить количество уведомлений (помните предыдущий пункт)
- Предоставьте возможность себе и/или пользователю временно отключить некоторые оповещения, например, во время работ по техническому обслуживанию.
- Если ваша система это позволяет, настройте иерархию оповещений с автоматическим подавлением более низких.
Если у вас отвалился сервер от сети, не нужно рассылать дополнительные письма о том, что приложения на нем стали недоступны, это уже очевидно с первого раза
- Разделите оповещения на группы — пусть инженеры получают технические оповещения, а предприятия — бизнес-оповещения.
Обычную коммерческую дирекцию не интересует, что у вас Nginx сломался (для них это ничего не будет значить), для них гораздо важнее знать, что рухнула цепочка выполнения бизнес-функции «закупка товара».
и компания несет потенциальные убытки
Лично для меня он стал той «серебряной пулей», которая сразу решила целый букет проблем.
Включены веб-перехватчики и API для интеграции.
Вместо заключения
Прежде всего выражаю благодарность тем, кто дочитал до конца; Надеюсь, что статья была вам интересна и полезна.Это первый текст из трёх запланированных — далее хотелось бы затронуть тему логирования и его синергии с мониторингом, а потом, возможно, перейти к некоторым техническим деталям (а не просто сухому тексту).
Если вам интересно об этом прочитать, пишите в комментариях.
Попробуем сначала проанализировать и обсудить общий подход к сбору и централизованному хранению логов, их роль в оценке состояния отслеживаемого сайта, а также коснемся вопроса – «можно ли отделить логи от метрикЭ» Теги: #Системное администрирование #DevOps #мониторинг #наблюдаемость
-
Usb3Vision И Genicam. Взгляд Изнутри. Я
19 Oct, 24 -
Мнение: Основной Текст Размером 16 Пикселей.
19 Oct, 24
