Можно ли сделать идеальный дашборд для мониторинга
Специально для телеграм-канала @monitorim_it.
Мне тут же вспомнилась статья в Тинькофф журнале «Как заработать на квартиру в пределах Мкада. Имея зарплату 100–200 тысяч рублей и не имея другого имущества». Почитайте — в самом тексте там одно единственное слово. И ведь почти 800 тысяч просмотров. Можно было б также написать и поставить точку. Тогда бы получился кассовый пост с миллионом миллионских просмотров.
Идеального дашборда, как и серебряной пули или универсальной таблетки не существует. Есть только запросы заказчика, опыт исполнителя и возможности платформы, на которой будет построен дашборд. Кому-то достаточно простых графиков с пингом, CPU и памятью, другие захотят увидеть 99й персентиль задержки между компонентами распределённого приложения, а третьим нужно смотреть на работу шагов бизнес процесса. Внутри самой компании-заказчика тоже есть разные категории потребителей дашборда со своими запросами и пожеланиями. Мне неизвестны вендоры систем мониторинга, которые бы поставляли одновременно инструмент мониторинга и гибкий конструктор для создания дашбордов в этом же интерфейсе. Как-то обычно это разные решения, причём для задач дашбординга, инструмент чаще разрабатывается с нуля и своими силами (в том смысле, что не используется вендорское решение).
Пока писал статью, гуглил в фоновом режиме, наткнулся на как будто бы интересное решение для дашбординга от Edge Technologies. Есть и другие похожие, но у этого 120+ готовых интеграций для разных решений по мониторингу (Appdynamics, Microfocus, Splunk и другими). Посмотрите, вдруг будет интересно.
А веду это всё я вот к этому:
Эта пятиуровневая модель, которая потенциально должна удовлетворить запросы всех имеющихся ролей внутри компании-заказчика. К модели нужно относиться как к шведскому столу: взять только то, что нужно.
1. Верхнеуровневый дашборд (top-level dashboard)
Дашборд с визуализацией здоровья бизнеса, бизнес-процессов, количеством медленных пользовательских транзакций и других верхнеуровневых метрик, интересных для руководства.
2. Событийный дашборд (triage dashboard)
Дашборд с событиями, которые разбиты на категории: события по серверной инфраструктуре, сетевой инфраструктуре, базам данных и т.д. Это был пример, но разбивка может быть и по категориям дежурных администраторов и какая угодно. А ещё можно сделать простой список событий и voila — у вас triage dashboard.
3. Карта сервиса, приложения или бизнес-процесса со связями (dependency-mapping dashboard)
Тут может быть: сервисно-ресурсная модель, карта бизнес-процесса или приложения. Этот дашборд наглядно покажет связи между компонентами наблюдаемых систем.
4. Приложение, инфраструктура или сеть с возможностью перехода на более низкий уровень (Application, Infrastructure or Network Drill-down)
Агрегирующий дашборд с разноцветными (в зависимости от наличия проблем с производительностью) объектами: серверами, сетевыми устройствами, базами данных или компонентами приложения.
5. Сырые данные (Raw data)
Трейсы приложений, события, логи, системные события операционных систем и подобные им данные. Не знаю как вам, а мне сразу представились ELK и Splunk.
Этот пост затевался для того, чтобы уважаемые читатели встали на путь агрегации, уменьшения количества разных интерфейсов и выбирали решения, которые включают в себя 2–3 перечисленных уровня, а в идеале все 5, но идеального дашборда же не бывает, верно?