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

Определите, какое состояние компонентов следует считать «нормой». Это поможет определить и проанализировать всплески активности или необычное использование ресурса. Если внезапно уменьшился объем используемой памяти, это может говорить о том, что какой-то процесс умер или что он работает нестабильно – запускается и тут же падает. Обращайте внимание на непонятные отклонения от нормы – рост нагрузки, не связанный с увеличением трафика от пользователей или приходом новых клиентов.

С учетом особенностей вашей системы определите критерии, на основании которых вы будете принимать решение об обновлении или расширении ваших сервисов (добавлении ресурсов для веб-серверов или баз данных) или же, наоборот, об освобождении ресурсов, которые больше не нужны. Эти метрики жизненно важны для обеспечения нормальной работы. Другой уровень мониторинга – это журналы, в которых приложения фиксируют все события во время работы. Каждое приложение генерирует такие журналы, которые могут храниться как в отдельных файлах на диске, так и в службе событий Windows или в Amazon CloudWatch. Источников данных много.

Современный способ обрабатывать все эти данные – перенаправить все журналы в централизованную службу (такую как Elasticsearch) и использовать ее для сравнения, поиска аномалий, мониторинга и оповещения. Так вы сможете не только проводить анализ всех журналов в одном месте, но и легко обнаруживать связи между разными компонентами, потому что проблемы в одном из них могут быть признаком другого, более серьезного сбоя. Классический пример: увеличение количества SQL-ошибок в веб-приложении указывает на проблемы с сервером базы данных, где долго выполняющийся запрос мог заблокировать таблицы. Такие зависимости бывает трудно обнаружить, поэтому для анализа причин проблемы придется проверять различные подсистемы.

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

Заметки с полей

Централизованное время

Для современных ОС это уже обычно не является проблемой, но все же лучше убедиться, что все системы синхронизированы и используют один и тот же часовой пояс, обычно это UTC (всемирное координированное время). Во всех операционных системах есть средства синхронизации времени, которые периодически подстраивают часы. Это очень упрощает ретроспективный анализ журналов, поскольку на единой шкале времени сразу становятся видны причинно-следственные связи.

Создание информационных панелей (дашбордов), отображающих информацию о текущем состоянии ваших систем, потребует времени, проб и ошибок. И они будут развиваться по мере того, как ваше понимание работы систем будет углубляться. Ваша цель здесь проста: выиграть как можно больше времени для корректирующих действий, прежде чем проблемы затронут работу компании. Не допускайте ситуации, в которой единственным средством мониторинга станут звонки ваших клиентов. Это не способствует повышению доверия ни к вам, ни к вашей компании.