Представьте себе администрирование без мониторинга. Представили количество отпавшего и багнувшего? А как вы всё это пытаетесь привести в порядок представили? Сложно, понимаем.
Ещё в 2000-х мониторинг был проще, чем сейчас. Если раньше достаточно было мониторить несколько серверов и это считалось инфраструктурой, то сегодня инфраструктура — это множество уровней, для каждого из которых нужна своя система мониторинга со своими нюансами.
Если раньше падали серверы и горели жёсткие диски, то теперь нужно разбираться во всех уровнях. И на скорость взаимодействия смотреть, и на микросервисы всякие.
Чтобы понять, куда именно нужно смотреть администратору, давайте разбираться в мониторинге.
Было/Стало
Старые добрые времена
В 2000-х мониторить свою систему было проще. В основном, отслеживали процессоры, сети, диски, память, — то есть, показатели системы. А всё почему? Потому что нагрузки были небольшими, вроде одного пхпшного приложения.
Главная проблема такого подхода — эти данные сообщают малоинформативны. Можно было понять, работает ли всё или вовсе отпало. А вот мякотку приложения не увидеть. Поэтому, когда с ним возникали проблемы, то приходилось ждать замечания от пользователей и чинить всё по мере поступления проблем. Мало похоже на сегодня, правда?
Суровая современность
Всё усложнилось. Системы стали динамичными со всеми масштабированиями и микросервисами. Иногда даже неизвестно, откуда и как именно всё работает — настолько всё серьёзно.
Что чаще ломается: песочные часы или механические? Чем сложнее система, тем больше у неё проблем. Так и в нашем случае. Метрики приложений, кол-во событий в очереди, мониторинг масштабирования. Ко всему нужно прикрутить метрики, чтобы поймать в нужный момент проблему.
Что самое интересное — проблемы на всём этом фоне стали не такими заметными, их тяжелее найти. Разделим их на два сегмента: “всё пропало” и “всё работает, но не так”.
Если с первыми вроде бы понятно, то вторые могут привести далеко и надолго. Но, в то же время, из-за многослойности мониторинга их хотя бы можно найти до по-настоящему больших проблем.
Не удивляйтесь, если окажется, что бизнесу тоже интересен мониторинг: транзакции, время между ними и всё коммерческое тоже стали частью обязанностей.
Как же мониторить?
Проектировать
Нужно понимать что именно вы мониторите ещё на стадии разработки архитектуры и приложения. Причём, важнее вся архитектура приложения, а не серверная архитектура.
Разработчики и архитекторы должны осознавать, что есть критичные части в системе. Это слабые места могут мешать развитию проекта и компании вообще, поэтому важно понимать, что есть потребность постоянно проверять их работоспособность.
Кто в первую очередь должен понимать данные мониторинга? Администратор. Поэтому мониторинг нужно сделать удобным и функциональным для администрирования: полученное в нужный момент оповещение и понимание проблемы быстро покажут, что именно отпало.
Настроить метрики и алерты
Оповещения нужно сделать понятными. Очень понятными. Если новый администратор получит оповещение, то он должен понять всё: в чём дело, куда смотреть или звонить, и как решить эту проблему.
Проблема не появляется просто так: важно понять первопричину её возникновения. Если что-то перестало работать, то в алерте нужно увидеть не только сам факт, но и влияние этой проблемы на другие компоненты. Может что-то подтормаживает, а может и вовсе не работает.
Но, чтобы тезис выше был правдивым, нужно понимать нормально или ненормально это для системы. Где-то должна быть история правок и параметров работы системы, чтобы алертами покрыть все аномальные моменты.
Что вы сделаете, если увидите оповещение о проблеме? Нужно либо уметь что-то сделать с проблемой, либо знать кто может помочь с этим. Всегда должен быть план действий на такие случаи. Постоянно обновляйте его, чтобы информация была актуальной.
Пользуйтесь системами оркестрирования, чтобы ваш мониторинг всегда был актуальным. Если вы пользуетесь ею, то изменения и мониторинг проходят через неё. Главное — уметь этим пользоваться.
Кидайте мониторинг на все новые проблемы. Если что-то отпало в обход мониторинга, то в этом месте он быть обязан.
Мониторьте мониторинг
Должен быть внешний скрипт, который мониторит мониторинг. Понимаете, что будет, если мониторинг отпадёт со всем-всем, что он мониторил? Катастрофа.
Чем мониторить?
Zabbix
Отличный выбор, если администрируете большие системы. Вообще подходит и для малых и средних предприятий. Поначалу может быть не очень просто разобраться, но это время окупится. В Zabbix легко добавить свои параметры мониторинга, собирать данные, анализировать действия, создавать графики и триггеры.
Cacti
Приложение для работы с RRDTool. Легко работает с большими и малыми сетями. Создатели поставили задачу сделать простой в использовании интерфейс, и у них это получилось. В Cacti всё строится на графиках, которые можно сортировать по самым разным параметрам и группам. Есть шаблоны графиков, что упрощает настройку. Учитывая кастомизацию, сильный инструмент.
munin
Вообще топ для небольших сетей. Принцип работы прост: один сервер (условно munin) собирает все данные с munin-node на других серверах, которые мы мониторим. Сервер подключается к нодам и получает от них информацию, которую сохраняет в базы rrdtool. Нам даже не нужна MySQL. Плагины можно написать под всё и сделать это просто. Рекомендуем.
Вывод
Современный администратор должен уметь настраивать и пользоваться системами мониторинга. Это сильно упрощает работу и оптимизирует деятельность всей системы, которую он обслуживает.
Интересна эта тема? Скорее переходите на наш курс по системам мониторинга, где мы научим правильно работать со всеми инструментами.