Мониторинг – это большая тема, которую можно разбить на подтемы, – чаще всего происходящие события и аналитика. При выполнении мониторинга применяются методы сбора информации, такие как метрики и логи. Процесс мониторинга включает сбор основных показателей системного уровня. Собираются сведения о времени работы или простоя сервера, объеме используемой памяти, использовании времени центрального процессора и величине свободного места на дисках. Также осуществляется мониторинг приложений на более высоком уровне, который варьируется от количества пользовательских запросов, обрабатываемых сервером, числа элементов в очереди системы массового обслуживания, времени загрузки веб-страницы до накопления в базе данных наиболее длительных запросов. Когда-то мониторинг являлся зоной ответственности системных и сетевых администраторов. По мере роста сложности программного обеспечения и все более тесного сотрудничества между командами люди начинают понимать, что благодаря мониторингу можно своевременно выявлять состояние программного продукта.
В общем случае мониторинг – это процесс отслеживания текущего состояния систем и окружающей среды. Обычно цель этой проверки заключается в выяснении соответствия некоторым заранее определенным условиям, которые описывают желаемое состояние. Зачастую мониторинг, оповещение и тестирование неразрывно связаны между собой. Это может привести к путанице относительно того, что мы собираемся построить или достичь. Как упоминалось ранее, мониторинг обычно выполняется в соответствии с заранее разработанным графиком, а тесты выполняются в ответ на изменения. Оповещения – это автоматизированные сообщения, которые уведомляют человека о результатах выполнения теста или события.
Метрики
Метрики – это совокупность количественных и качественных результатов измерений. Обычно они сравниваются с неким эталоном или установленным стандартом. Цель подобного сравнения заключается в выполнении аналитических исследований или в пополнении архивов. Зачастую метрики накапливаются в функциональных организациях, что может повлиять на выбор корректного направления разработки продуктов.
Метрики являются ключевыми компонентами мониторинга. Могут собираться и накапливаться данные, относящиеся ко всем компонентам наиболее сложных интернет-приложений. Разные команды могут располагать различными метриками, которые они могут отслеживать и использовать в работе. Часто используемые инструменты StatsD и Graphite обеспечивают отслеживание, хранение и просмотр метрик.
Существует управляемая сообществом инициатива по определению набора системных и прикладных метрик. Эти метрики группируются по протоколам, службам и приложениям в хранилище каталога метрик GitHub, поддерживаемом Джейсоном Диксоном, организатором конференций по мониторингу Monitorama. По сути, это хранилище хороших практик, призванных служить в качестве справочного пособия для людей, желающих создавать или расширять свои собственные хранилища метрик.
Системы логирования
Суть процесса логирования заключается в генерировании, фильтрации, записи и анализе событий, происходящих в системе, как из-за самой операционной системы, так и вследствие появления программных сообщений. При отслеживании источника проблем, связанных с программным обеспечением, в первую очередь просматриваются логи для выявления соответствующих сообщений об ошибках. Логи могут быть просто кладезем полезной информации. И поскольку стоимость хранения информации постоянно снижается, можно легко и просто сохранить любой лог для использования в дальнейшем. Логи могут порождаться разрабатываемыми приложениями, инструментами от независимых поставщиков либо даже самой операционной системой. И поскольку не существует единого программного стандарта систем логирования, категоризация и классификация событий, заносимых в лог, может вызывать затруднения.
Всего лишь одна-единственная система может генерировать сотни или даже тысячи строк логов в день. В современных средах, когда десятки приложений выполняются на сотнях или даже тысячах серверов, объем данных логов переходит всякие границы. Поиск нужных сведений в таком огромном массиве данных может быть весьма затруднительным. Поэтому много сил и средств было потрачено на разработку приложений, предназначенных для работы с хранилищами и поиска нужных сведений в логах. Сложности, связанные с решениями по логированию, выходят за рамки этой главы, но все же не следует их недооценивать.
Оповещения
Мониторинг и оповещения важны не только с точки зрения обеспечения производительности программного обеспечения, но и с точки зрения профилактики. В частности, вы сможете своевременно узнать о потенциальных проблемах, пока они не превратились в реальные проблемы для ваших заказчиков. Например, после запуска в октябре 2013 года сайта US HealthCare.gov отсутствовали средства мониторинга и оповещения, которые позволяли бы определить работоспособность сайта.
Микки Дикерсон, который выполняет функции администратора United States Digital Service, выступал с докладами на многих отраслевых конференциях. Он утверждал, что мониторинг сайтов, выполняемый его командой в течение первых месяцев автоматизации, сводился к просмотру новостных источников, таких как отчеты CNN. Использование открытых источников информации чревато появлением проблем, которых в какой-то степени поможет избежать лишь хорошо продуманная стратегия оповещений.
При рассмотрении системы оповещений нужно учитывать несколько факторов.
Влияние
Далеко не все системы оказывают одинаковое влияние на другие системы или людей. Те из них, которые получили широкое распространение и воздействуют на многие системы или большие группы пользователей, оказывают намного большее влияние, чем те, которые воздействуют на небольшую группу других систем или людей. Некоторые инциденты вообще не задевают интересы клиентов либо воздействуют на системы, которые обладают достаточным запасом прочности. Чтобы избежать усталости, вызванной навязчивыми оповещениями, применяйте их только в случае наиболее значительных инцидентов. Подробнее эта тема будет рассмотрена далее.
Срочность
Как и в случае с влиянием, далеко не все проблемы относятся к категории срочных, требующих безотлагательного решения. Срочная проблема требует быстрого (иногда мгновенного) ответа. Например, «падение» вашего сайта, вызывающее потерю денег или клиентов, относится к категории проблем, требующих безотлагательного решения. Если же недоступен чисто информационный блог, вряд ли эта проблема требует столь срочного решения. Конечно, у каждого представителя заинтересованной стороны имеется собственное мнение по поводу срочности той или иной проблемы, поэтому при настройке мониторинга или системы оповещений учитывайте мнение всех заинтересованных сторон.
Заинтересованная сторона
В первую очередь заинтересованными сторонами инцидента являются те, на кого этот инцидент воздействует. В частности, это могут быть заказчики (или подгруппы заказчиков) или же группы сотрудников (в случае инцидентов, связанных с внутренними службами). В качестве заинтересованных сторон могут также рассматриваться лица, ответственные за реагирование на инцидент. Например, если решение проблем, связанных с базами данных, находится в компетенции администратора баз данных, в случае возникновения этих проблем следует обращаться к нему, а не к эксплуатационной команде, которая в лучшем случае может вызвать администратора.
Ресурсы
Ответьте на вопрос о том, какие ресурсы нужны для реагирования на данный инцидент или оповещение и доступны ли они в данный момент. Достаточно ли у вас человеческих ресурсов, чтобы реагировать на несколько инцидентов, или у вас имеется всего лишь один ответственный сотрудник по вызову, которого никто не может заменить? Имеются ли в вашей организации ресурсы, чтобы успешно
