Мониторинг: что нужно знать новичку?

Представьте себе администрирование без мониторинга. Представили количество отпавшего и багнувшего? А как вы всё это пытаетесь привести в порядок представили? Сложно, понимаем.

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

Если раньше падали серверы и горели жёсткие диски, то теперь нужно разбираться во всех уровнях. И на скорость взаимодействия смотреть, и на микросервисы всякие.

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

Было/Стало

Старые добрые времена

В 2000-х мониторить свою систему было проще. В основном, отслеживали процессоры, сети, диски, память, — то есть, показатели системы. А всё почему? Потому что нагрузки были небольшими, вроде одного пхпшного приложения.

Главная проблема такого подхода — эти данные сообщают малоинформативны. Можно было понять, работает ли всё или вовсе отпало. А вот мякотку приложения не увидеть. Поэтому, когда с ним возникали проблемы, то приходилось ждать замечания от пользователей и чинить всё по мере поступления проблем. Мало похоже на сегодня, правда?

Суровая современность

Всё усложнилось. Системы стали динамичными со всеми масштабированиями и микросервисами. Иногда даже неизвестно, откуда и как именно всё работает — настолько всё серьёзно.

Что чаще ломается: песочные часы или механические? Чем сложнее система, тем больше у неё проблем. Так и в нашем случае. Метрики приложений, кол-во событий в очереди, мониторинг масштабирования. Ко всему нужно прикрутить метрики, чтобы поймать в нужный момент проблему.

Что самое интересное — проблемы на всём этом фоне стали не такими заметными, их тяжелее найти. Разделим их на два сегмента: “всё пропало” и “всё работает, но не так”.

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

Не удивляйтесь, если окажется, что бизнесу тоже интересен мониторинг: транзакции, время между ними и всё коммерческое тоже стали частью обязанностей.

Как же мониторить?

Проектировать

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

Разработчики и архитекторы должны осознавать, что есть критичные части в системе. Это слабые места могут мешать развитию проекта и компании вообще, поэтому важно понимать, что есть потребность постоянно проверять их работоспособность.

Кто в первую очередь должен понимать данные мониторинга? Администратор. Поэтому мониторинг нужно сделать удобным и функциональным для администрирования: полученное в нужный момент оповещение и понимание проблемы быстро покажут, что именно отпало.

Настроить метрики и алерты

Оповещения нужно сделать понятными. Очень понятными. Если новый администратор получит оповещение, то он должен понять всё: в чём дело, куда смотреть или звонить, и как решить эту проблему.

Проблема не появляется просто так: важно понять первопричину её возникновения. Если что-то перестало работать, то в алерте нужно увидеть не только сам факт, но и влияние этой проблемы на другие компоненты. Может что-то подтормаживает, а может и вовсе не работает.

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

Что вы сделаете, если увидите оповещение о проблеме? Нужно либо уметь что-то сделать с проблемой, либо знать кто может помочь с этим. Всегда должен быть план действий на такие случаи. Постоянно обновляйте его, чтобы информация была актуальной.

Пользуйтесь системами оркестрирования, чтобы ваш мониторинг всегда был актуальным. Если вы пользуетесь ею, то изменения и мониторинг проходят через неё. Главное — уметь этим пользоваться.

Кидайте мониторинг на все новые проблемы. Если что-то отпало в обход мониторинга, то в этом месте он быть обязан.

Мониторьте мониторинг

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

Чем мониторить?

Zabbix

Отличный выбор, если администрируете большие системы. Вообще подходит и для малых и средних предприятий. Поначалу может быть не очень просто разобраться, но это время окупится. В Zabbix легко добавить свои параметры мониторинга, собирать данные, анализировать действия, создавать графики и триггеры.

Интерфейс Zabbix

Cacti

Приложение для работы с RRDTool. Легко работает с большими и малыми сетями. Создатели поставили задачу сделать простой в использовании интерфейс, и у них это получилось. В Cacti всё строится на графиках, которые можно сортировать по самым разным параметрам и группам. Есть шаблоны графиков, что упрощает настройку. Учитывая кастомизацию, сильный инструмент.

Интерфейс cacti

munin

Вообще топ для небольших сетей. Принцип работы прост: один сервер (условно munin) собирает все данные с munin-node на других серверах, которые мы мониторим. Сервер подключается к нодам и получает от них информацию, которую сохраняет в базы rrdtool. Нам даже не нужна MySQL. Плагины можно написать под всё и сделать это просто. Рекомендуем.

Интерфейс munin

Вывод

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

Интересна эта тема? Скорее переходите на наш курс по системам мониторинга, где мы научим правильно работать со всеми инструментами.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *