Мониторинг и оповещение

Давайте представим себе некую совершенно среднюю компанию с совершенно средним парком ИТ. В каждой подобной компании есть набор критически важных сервисов, некорректная работа или отключение которых может вылиться в большие финансовые потери.
Для предотвращения таких ситуаций и служат службы мониторинга и оповещения, которые я хотел бы осветить в данной статье.


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

Мониторинг подключения к Интернету

Открыть статью я хочу сервисом под названием доступ в Интернет. Наверняка многие подумают: да не такой уж он критичный для моей компании, ну пропадёт на пару часиков - ничего страшного. Да, но дело в том, что все службы оповещения работают только и исключительно через Интернет и, соответственно, если он пропал, никакие оповещения доставлены не будут! А если в этот самый момент случится ещё какая-либо неисправность, тогда что? - Правильно, тогда мы о ней не узнаем. А этого нельзя допустить. По этой самой причине доступ в Интернет считается критически важной службой.

Мониторинг доступа в Интернет необходимо организовывать извне локальной сети организации. Ибо если строить его изнутри, то при пропадании Интернета уведомлений мы не получим.  

Мониторинг лучше всего настраивать таким образом, чтобы при взгляде на него можно было составить первичное представление о том, на чьей стороне проблема: на стороне интеренет-провайдера, или на стороне организации. Т.е. администратор должен получить сообщение типа "Проблема с интернет подключением у компании "ООО "Ромашка", или "Проблема у интернет-провайдера компании "ООО "Ромашка" и действовать сразу сообразно полученной информации, а не гадать, что же там произошло и тратить драгоценное время на звонки и выяснения обстоятельств. 

Сюда же по возможности стоит включить мониторинг средств компании на текущем счету интернет-провайдера. Иногда неполадки случаются не в технической, а в финансовой плоскости: ответственное лицо просто забыло оплатить Интернет. Не лишним будет настроить отправку писем для этого лица с текстом наподобие "Внимание! Баланс лицевого счёта N рублей и приближается к критическому! Пополните счёт!!!"

Мониторинг аппаратного состояния оборудования

Дальше идёт аппаратное состояние оборудования и серверов. Скорости вентиляторов, температуры, состояние дисковых подсистем серверов, батарей ИБП и т.д. Не знаю, есть ли необходимость рассматривать всё это подробно (ибо, по-моему, важность этих параметров ясна), разберу 2 примера из собственной практики:

Допустим, в компании есть хороший дорогой сервер с отказоустойчивым дисковым массивом RAID0. Вовремя не информированный своим ИТ специалистом заказчик находится в полной уверенности, что раз массив отказоустойчивый, то всё у него хорошо. Но вот случается так, что в массиве выходит из строя 1 диск и, так как мониторинг и оповещения не настроены, об этом никто не знает! Сервер продолжает работать на одном диске, внешне у него всё хорошо и никто не подозревает беды, которая приходит через полгода, с выходом из строя второго диска. В результате чего компания теряет все свои данные. И самое обидное в этом то, что всё это можно было бы предотвратить, если бы своевременно была настроена система мониторинга и оповещения.

Пример два: в компании есть несколько серверов, работающих от одного большого бесперебойника APC. В нём уже имеется сетевая карта, дающая широкие возможности для мониторинга, но по причинам, которые мы не будем оглашать, карта не подключена к сети. В ИБП дохнут аккумуляторы и он честно сигнализирует об этом лампочкой на передней панели. Но в серверную никто не ходит (или ходит, но всем пофигу) и лампочка светит впустую. В один далеко не прекрасный день в здании бизнес-центра случается беда: то ли отгорает ноль, то ли ещё что-то, но в розетках оказывается 380В. ИБП пытается перейти на питание от батарей, но батарей нет и ему становится совсем плохо. В таком состоянии его и застают пришедшие утром сотрудники. А ещё они застают свои сервера в полумёртвом состоянии: у кого-то выгорел БП, у кого-то - материнская плата. Итог этой истории был грустный и очень дорогой. И опять же, всего этого удалось бы избежать, если бы вовремя был настроен мониторинг и оповещения.

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

Мониторинг состояния резервного копирования

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

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

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

Чтобы этого не произошло, каждая более-менее приличная система резервного копирования снабжена средствами для отправки диагностической информации в виде, как минимум, результатов создания текущей резервной копии. И это уже хорошо, если эти средства настроены и работают! Но тут есть пара существенных минусов:
    1. Если подвисла служба бэкапа или имеются проблемы с подключением к сети, вы не получите ничего. И есть шанс, что вы не вспомните "а где же моё сообщение от системы бэкапа?!" и не полезете выяснять, почему же вы его не получили. С этого самого момента вы остаётесь без бэкапов;
    2. Сколько однотипных сообщений вы готовы читать и хотя бы бегло, но всё же анализировать? Одно? Два? Лично у меня на пяти уже мылится глаз и я могу пропустить что-то важное.

Чтобы исключить обе эти ситуации письма от систем резервного копирования настраиваются на отдельный почтовый ящик, с которого их забирает и автоматически анализирует система мониторинга. Пока письма об успешном прохождении бэкапа приходят регулярно, система молчит. Как только одно письмо пропущено или содержит ошибку, система шлёт оповещение администратору.


Теперь коротко пройдёмся по специфике мониторинга других сервисов, которые могут опционально присутствовать в ИТ инфраструктуре организации.

Мониторинг служб

Любые службы, которыми пользуются сотрудники компании, должны быть включены в систему мониторинга. Однако излишнего фанатизма, на мой взгляд, проявлять не следует: нет смысла мониторить службы, которыми постоянно все пользуются. К примеру, внутрисетевой DNS. Понятно, что если он ляжет, об этом узнают все и сразу. Пользователи позвонят раньше, чем придёт сообщение от системы мониторинга ;-} Да и диагностируется такая неисправность быстро, поэтому необходимости в мониторинге этой службы, по моему мнению, чаще всего нет.

Из того, что следует мониторить, можно выделить отдельно:
    1. Почтовые службы; 
    2. Веб сервера; 
    3. Службы виртуализации. 

Подробно расписывать не буду, тут много тонкостей. Скажу только, что принцип отбора такой: мы мониторим те сервисы, отсутствие которых не может быть однозначно истолковано. Т.е. здесь цель мониторинга не только оперативное получение информации о неисправности, но и диагностика источника этой неисправности.

Мониторинг состояния оборудования - 2
(загрузка процессора, памяти и т.п.)

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

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

Я не считаю этот мониторинг обязательным т.к. в маленьких сетях возникновение такого рода проблем весьма маловероятно и смысла тратить деньги на внедрение подобного мониторинга я не вижу. Однако в компаниях с кол-вом пользователей 30+ такое внедрение уже может быть полезным и, следовательно, самоокупиться.

Мониторинг свободного места на дисках

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

И, наконец, мониторинг мониторинга!

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

И мониторинга этой подстраховки.

Et cetera, ad infinitum...

Но это уже шутка, да.


© 2020 Пашкиров Олег Викторович

Контакты:

Email: riy@yandex.ru                     
Skype: Варган Шаманов