Привет, Хабр! Меня зовут Кирилл, я работаю в IT более 13 лет. Сначала инженером по внедрению, потом DevOps, потом SRE, также работал руководителем группы сопровождения. Сейчас SRE в VK Рекламе, поэтому знаю, как важно делать правильные инструменты для анализа проблем.
В любом проекте и компании я иногда сталкивался, а иногда сам создавал проблему: огромное количество дашбордов. Вспомните ситуацию, когда вы в Grafana ищете какой-нибудь дашборд, пишете, например, «Tarantool», и вам выпадает огромный список дашбордов, которые кто-то до вас насоздавал. Это могут быть кастомные дашборды, которые кто-то делал для какого-нибудь инцидента, или просто созданные другими специалистами. Часто бывает, что половина этих дашбордов нерабочие или на них нет чего-то полезного.
Как правило, обилие дашбордов создаёт ряд проблем: информационную перегрузку, потерю фокуса, сложность восприятия, а самое главное, затруднение исследований инцидентов. Попробуйте себе честно ответить на вопрос: глядя на свой дашборд, вы можете понять, работает ваша система или нет? Если нет, то читайте дальше.
Истории из чатов
За всё время работы у вас наверняка накопилось огромное количество интересных сообщений в чате. На самые разные темы, например: «Есть ли проблема с сервисом X?» Или кто-то врывается в чат с предсказанием: «Я думаю, что сервис X работает сегодня медленно». Как мы можем ответить на эти вопросы в моменте? Чаще всего смотрим графики в Grafana, анализируем тренды и пытаемся найти ответ. Но сделаем шаг назад и разберёмся, а как вообще появляются дашборды?
Дашборд
Думаю, стандартный для многих процесс выглядит так: берём в Grafana дашборд — это может быть дашборд сервисов, инфраструктурный дашборд и т. д. — и допиливаем его под себя: удаляем лишние графики, обогащаем своими данными. Он становится огромным. С точки зрения мониторинга какого-то маленького компонента сервисов или инфраструктуры это вполне допустимо, потому что в целом мы покрываем 70-80 % запросов, которые нам нужны от мониторинга.
Но что может быть пойти не так при этом подходе?
На таких дашбордах чаще всего мы видим техническую составляющую, а не пользовательский опыт. Это стандартные request, latency, топики в Kafka, лаги и т. д. Такие дашборды трудно воспринимаются человеком, не погружённым в проект. Тут вы можете меня спросить: «А зачем человеку, не погружённому в проект, смотреть на наши дашборды? » Ответ очень простой. Мы не живём в вакууме, наши сервисы взаимодействуют с другими компонентами и платформами, и мы должны понимать, всё ли корректно работает и у нас, и в сервисе другой команды.
А кто смотрит наши дашборды?
Эксплуатация/L2. Это люди, которые занимаются поддержкой нашего production, бдят 24*7, либо по запросу реагируют на наши проблемы. Они менее погружены в проект, чем команда разработки.
Команды разработки, в том числе текущего проекта и внешние команды, от которых мы так или иначе зависим, или которые зависят от нас.
Менеджеры, которым необходимы графики, чтобы отслеживать проблемы.
Пользователи. Вы можете мне смело возразить: «Какие пользователи, что ты несёшь?!» На самом деле пользователи могут быть не только внешние, но и внутренние, например, пользователи наших API и внутренних сервисов. И вообще, история с внешней наблюдаемостью, когда люди могут посмотреть на то, как наш проект работает, мне кажется очень классной. Пользователи тоже очень важны с этой точки зрения.
Что мы хотим получить от дашбордов?
Мы хотим получить некий единый дашборд здоровья сервисов. Он должен быть не только красивый, но ещё и понятный, причём не только людям, которые делают этот дашборд, но и тем, которые используют каким-то образом наши сервисы и хотят узнать, работает ли вообще наш проект.
Прежде чем перейти к проектированию и исследованию, предлагаю не придумывать велосипед, а посмотреть на другие сферы нашей жизни, которые могут помочь в проектировании и создании такого дашборда.
Однажды я обратил внимание на маленький прибор на панели в самолёте, который называется основной пилотажный дисплей.
Этот небольшой дисплей находится постоянно в поле зрения пилота и показывает огромное количество информации. Пилот, смотря только на один этот прибор, может принять решение о том, как чувствует себя самолет в воздухе, какие у него угол крена и тангажа, высоту, скорость и другие параметры полёта. Возьмём отсюда идею компактности подачи информации.
Понятное дело, что такой основной пилотажный дисплей будет не единственным в нашей системе. Есть ещё огромное количество различных графиков. Как нам получить доступ к какой-то дополнительной информации, к текущим графикам?
Я обратил внимание на процесс, как мы принимаем решение обратиться к врачу. Если мы чувствуем какую-то боль, то обычно идём к терапевту. Он пытается продиагностировать наше состояние, назначает лечение или направляет к узкому специалисту — хирургу, аллергологу, дерматологу и т. д. Это второй уровень исследования нашей проблемы.
Что получится, если сложить идею основного пилотажного дисплея — компактности — и подход к поиску источников боли в организме?
Single Pane of Glass
Мы получаем некий единый дашборд, который верхнеуровнево выглядит так:
Сверху — уровень сервисов, на котором нет ничего, кроме светофора: есть ли проблема с различными сервисами. Если мы понимаем, что она есть проблема (на иллюстрации проблема с сервисом D), то можем провалиться на уровень ниже. Там мы получаем уже более детальные графики нашего сервиса. Это может быть Latency, Four Golden Signals, USE, RED, какие-то кастомные метрики зависимых компонентов этого сервиса, и т. д.. В нашем случае мы используем Four Golden Signals (Latency, Traffic, Error, Saturation).
Если эти графики нам не помогают, мы видим, что по ним у нас всё более-менее ровно, но проблема ещё существует, мы можем обратиться на уровень ниже и посмотреть, что происходит с инфраструктурой: потребление памяти, процессора, сети, диска, а при работе хостов на физических машинах, мы можем посмотреть метрики Cube API, и т. д. То есть мы «проваливаемся» в дашборды для получения более точной диагностической информации.
Преимущества такого подхода:
Централизованный мониторинг. С помощью такой панели мы можем быстро и удобно отслеживать работоспособность, производительность и доступность наших компонентов..
Улучшенная видимость. Мы объединяем огромное количество данных из источников, можем быстро выявлять какие-то закономерности, когда что-то не работает.
Эффективное сотрудничество. IT держится на коммуникациях. Мы должны уметь общаться с другими командами, с другими коллегами, и делать это эффективно. Дашборд нужен как раз для этого. Мы не даём внешним командам кучу непонятных графиков, возможно, красивых, но непонятных. Мы даём им единый дашборд, где они могут посмотреть состояние сервисов на текущий момент.
Оптимизация поиска проблем. Наличие необходимой информации в одном месте позволяет достаточно быстро находить проблему и оптимизирует время устранения инцидентов.
Мы примерно определились с тем, что хотим. Но сказать — не значит сделать, нужен план.
Single Pane
Получилось несколько пунктов:
Определение целей и показателей.
Разработка макета.
Сбор технических показателей.
Пороговые значения.
Управление инцидентами.
Тестирование и обратная связь.
Непрерывное улучшение.
Определение целей и показателей
Но как понять, работает ли сервис? Мы уже говорили о том, что он не существует в вакууме, взаимодействует с другими платформами, передаёт и запрашивает данные. Можно ли, например, считать, что всё хорошо, если открывается главная страница? Конечно, нет. Идея в том, чтобы использовать понятие Критический Пользовательский Путь.
Критический Пользовательский Путь (CUJ)
Это подход, который описывает ключевые взаимодействия между пользователями и продуктом. CUJ — это путь (иногда частичный), который проходит пользователь в нашем продукте. И этот путь создаёт наибольшую ценность: финансовую, репутационную и т. д. Если на каком-то из этапов CUJ есть сбои, то мы должны знать об этой проблеме. Сегодня рассмотрим такой сценарий: критический пользовательский путь для нашего мониторинга.
Что мы должны сделать? Первое — разбить CUJ на технические компоненты, которые так или иначе участвуют в показе статистики.
У нас есть пользователь, который в личном кабинете запрашивает статистику. Запрос уходит в сервис статистики, а от него в кеш-коллектор. Тот обращается в Redis и смотрит, есть ли там нужные данные. Если нет, то идёт в СУБД. А как данные туда попадают? Есть некий сервис producer, который пишет данные в Kafka, откуда их читает сервис consumer и перекладывает в СУБД актуальную статистику.
Получается, что маленькое предложение «Я хочу просматривать статистику по запущенным компаниям» превращается в набор компонентов и сервисов, которые стоят за этим пользовательским путём:
producer;
Kafka;
consumer;
ClickHouse;
Redis;
cache collector;
сервис быстрой статистики.
После того, как мы определили технические компоненты, которые так или иначе участвуют в пользовательском пути, необходимо принять измеримые решения, необходимые для лучшего SLO.
Как правило, для продуктов, которые ориентированы на запрос-ответ, для IP-сервисов используются два известных подхода к измерению:
Availability — количество доступных запросов, которые мы можем обработать.
Latency — задержка до обработки запроса.
На самом деле есть много других типов SLO:
Quality — количество запросов, обработанных без ухудшения качества.
Correctness — количество корректно отображаемых валидных данных.
Freshness — количество обновлённых корректных данных ранее какого-то порога.
Throughput — скорость обработки данных.
Coverage — охват.
Completeness — полнота.
Durability — вероятность потери данных в хранилище.
В нашем случае мы принимаем, что будем измерять SLO в Availability, Latency и Freshness. Дальше посмотрим, почему.
После того, как мы определились с техническими компонентами, которые так или иначе участвуют в нашем процессе, и с теми SLO, которые будем накладывать, переходим к следующему пункту — это заполнение таблички, которая говорит о том, какие компоненты мы измеряем, какие типы SLO накладываем на эти продукты.
Пример:
Это мы принимаем для себя как доступный уровень обслуживания.
Супер, определились с конкретными SLO и конкретными сервисами, что дальше?
Разработка макета
На самом деле проектирование дашборда можно сделать нулевым шагом. Как правильно подойти к этому, какие инструменты мы используем?
Рисуем на бумаге. Для себя я понял, что это как с презентацией. Когда готовишь её, открываешь чистый лист и не понимаешь, что туда разместить. Прежде чем начать проектирование чего-то, например, в Grafana, хорошо бы нарисовать это либо на бумажке, либо в Mirro, поместить все свои желания, а дальше уже собрать что-то актуальное и красивое.
-
Grafana — это уже де-факто стандарт визуализации метрик, многие компании ею пользуются. Мы используем несколько плагинов:
Single Stat
Status Panel
Status Overview
Распределение по критичности CUJ. Важно, что на дашборде мы распределяем CUJ по уровню критичности. Например, в онлайн-магазине у нас есть три пользовательских пути, не все из них mission critical.
Threshold как SLO, чтобы подсвечивать, делать светофор на наших дашбордах.
Как выглядел наш дашборд вначале:
Здесь все идеи, которые мы расписали для себя, а затем начали анализировать их и пытаться переложить в Grafana. После этого пришло время собрать технические метрики и показатели.
Сбор технических показателей
Это долгий, но довольно очевидный технический процесс по внедрению или добавлению новых метрик:
Определяемся с источниками данных.
Дорабатываем сервисы.
Понятное дело, что мы явно заложили не все метрики, которые так или иначе у нас есть на текущий момент. Это тоже важный этап, про который нужно не забыть и проговорить его.
Пороговые значения
Чтобы мы могли понимать, когда есть проблемы, нужно так или иначе подсветить их на дашборде.
Уровни критичности CUJ. Первое, что мы определяем — это уровни критичности нашего пользовательского пути (critical, low, medium, high), всё зависит от сценария. В первом приближении мы закладываем в качестве SLO технические метрики, так как на них мы можем прямо повлиять. Вместе с тем, не стоит забывать о других типах метрик. Даже если мы сами не можем повлиять на них напрямую, крайне важно вовремя обозначить какие-либо проблемы коллегам. Поэтому будьте готовы к тому, чтобы включить бизнес-метрики в критический пользовательский путь.
Правильный выбор канала оповещений. Это тоже очень важно. Понятно, что никто не будет непрерывно смотреть на графики. Есть люди, которым интересно получать оповещения по тем или иным проблемам. Здесь важно выбрать правильный канал оповещения. Коллега рассказывал про alert fatigue — выгорание от оповещений. Например, мы распределяем наши оповещения в зависимости от уровня канала и степени назойливости. Например, если инцидент mission critical, всё горит, нужно срочно решать, то это может быть звонок на телефон. Этот способ вырвет вас из домашней среды, из вашего work-life balance и поместит в среду решения проблемы. Все остальные проблемы (low, medium, high) можно передавать, например, в рабочий чат.
Управление инцидентами
Список открытых инцидентов. Представьте ситуацию, что у вас есть дашборд. К вам приходит пользователь, видит, что какой-то сервис красный, и начинает бить в колокола, кричать, что у меня проблема, ничего не работает. Но по факту ваша команда эксплуатации или вы уже заметили эту проблему, минут 15 назад уже подняли инцидент и начали его решать. Вам не нужно, чтобы кто-то к вам пришёл и пытался нарушить процесс решения инцидента. Поэтому на дашборд важно добавить информацию о текущих инцидентах, чтобы пользователь, который зашел на дашборд, увидел, что да, сервис D красный, пользовательский путь красный, но есть инцидент, открытый командой эксплуатации или вами, и в рамках него вы уже проводите какие-то работы, так что дополнительно оповещать об этом уже не нужно.
Здесь мы просто добавляем список открытых инцидентов в дашборд. Это может выглядеть по-разному. У нас любой инцидент выглядит как оповещение в Grafana, и мы его отрабатываем. Либо это может быть какой-нибудь процесс через внутренние системы, либо ручное добавление. Всё очень сильно зависит от ситуации.
После того, как мы всё это сделали, нельзя просто взять и отдать такие наработки в другие команды, нужно протестировать и дать обратную связь.
Тестирование и обратная связь
Тестируем получаемые данные. Уверен, что 90 % ваших оповещений сначала будут false positive. Поэтому важно в течение одной-двух недель протестировать, когда вы просто проверяете работоспособность вашего дашборда, корректность данных, которые предоставляете, и что у вас нет false positive.
Собираем обратную связь от пользователей. Как разработчики инструмента мы всё понимаем в нём, но вопрос — понятно ли людям, для которых мы этот дашборд делали? Поэтому отдаём его им и собираем обратную связь, понятен ли этот дашборд, выполняет ли он функцию, ради которой его делали.
Продаём идею в другие подразделения, когда команд много. Вы можете сделать что-то в рамках своего подразделения, но надо это ещё показать другим, рассказать им. Здесь совет простой, буду капитаном: мы просто создаём дашборд в одной команде, потом делаем Proof of Concept, после этого приходим в другую команду, показываем, как это работает, зачем это нужно, пытаемся эту идею продать. Плохо, когда мы что-то делаем и никому не рассказываем — опять же это про коммуникации. Мы рассказываем командам, как они могут у себя применить такие дашборды и как мы можем им помочь такие дашборды сделать.
Непрерывное улучшение
Не конечный процесс.
Следим за появлением новых критичных процессов.
В конечном итоге важно помнить, что процесс создания такого дашборда, как в целом мониторинг и observability, — это не конечные процессы. У нас добавляются новые метрики, появляются новые бизнес-процессы. Важно, что мы в каждой точке наших итераций должны следить за актуальностью нашего дашборда, потому что метрики могут выпилить, или добавить новый пользовательский путь, или один пользовательский путь может уйти в разряд некритичных, другой перейти в разряд критичных. За всем этим надо следить, и это тоже достаточно важно для организации правильного мониторинга и общей видимости.
Подводя итоги
Было
Раньше:
Много неактуальных дашбордов. Каждый, кто приходит, пытается что-то создать для себя, потому что ему чего-то недостаточно на дашборде другой команды. Получается огромный беспорядок, как в описанном мной примере: ищешь Tarantool, тебе выпадает список из 10 разных дашбордов, половина из которых уже в принципе не работает, потому что Tarantool уже начал метрики в другом формате отдавать, или дашборд вообще старый и делался под какой-то конкретный инцидент, и т. д.
Долгий процесс поиска проблемы. Это про 10 тысяч вкладок, открытых в Grafana, когда ты пытаешься найти, где у тебя что-то сломалось, что-то не работает.
Стало
Понятно, это не конечный процесс, он дорабатывается всё время. Что мы получили:
Единый дашборд «живости» сервиса и наших пользовательских путей.
Повысили прозрачность работы сервисы. Коллеги могут зайти и посмотреть на наши пользовательские пути, как наши сервисы работают. Мы открыты перед ними, не скрываем проблемы.
Уменьшили время исследования проблем, связанных с пользовательскими путями.
Как это работает сейчас у нас
Скриншот одного из дашбордов (пример, про который я рассказывал — отображение быстрой статистики):
Здесь ничего не понятно, все зелёное. Когда мы понимаем, что проблема с сервисом, мы проваливаемся на один уровень ниже:
Здесь получаем стандартные метрики Four Golden Signals (Latency, Traffic, Error, Saturation). Если и здесь непонятно, что с сервисом не так, то проваливаемся ещё ниже, на дашборд инфраструктуры:
Смотрим метрики по latency, по памяти, перезапуски подов и другие, то есть проваливаемся ещё глубже и пытаемся анализировать проблему.
Что дальше?
На этом процесс не останавливается:
Обогащаем дашборд сценариями. Мы покрыли пока малую часть того, что у нас в целом есть, потому что в нашем продукте огромное количество пользовательских сценариев.
-
Добавляем синтетические транзакции. Классно мониторить тем путём, о котором я рассказал, но, если у вас есть какая-то транзакция, которая пройдёт весь пользовательский путь от начала до конца и выдаст финальный результат в конце — это ещё ценнее. В эту сторону мы двигаемся.