Книга: Руководство по DevOps

Создайте телеметрию логирования приложений, полезную на этапе эксплуатации

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

Скотт Праф, главный архитектор и вице-президент отдела разработки компании CSG, отметил: «Каждый раз, когда NASA запускает ракету, тысячи автоматизированных сенсоров в ней отчитываются о состоянии каждого компонента этого ценнейшего объекта. А мы же часто не принимаем таких же мер предосторожности с нашими программами. Мы обнаружили, что создание телеметрии на уровнях приложения и инфраструктуры — одна из самых выгодных инвестиций, что мы когда-либо делали. В 2014 г. мы фиксировали более миллиарда событий в день, причем данные поступали из более чем сотни тысяч мест в коде».

В создаваемых и используемых нами приложениях каждый элемент функциональности должен находиться под наблюдением: если он был достаточно важен, чтобы его реализовать, значит, он достаточно важен, чтобы собирать о нем данные. Так мы сможем контролировать, что он работает именно так, как и предполагалось, и что итог работы такой, какого мы и хотели добиться[109].

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

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

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

• Информационный уровень. На этом уровне данные состоят из специфических для конкретной системы действий или же действий, совершаемых пользователем (например, «начало транзакции с использованием кредитной карты»).

• Уровень предупреждений. Здесь телеметрия сообщает нам о состояниях, потенциально порождающих проблемы (например, обращение к базе данных занимает больше времени, чем заранее запланировано). Эти условия, вероятно, выдадут оповещение и потребуют выявить и устранить неполадку, тогда как другие сообщения логов помогут нам лучше понять, какие действия привели к такому состоянию.

• Уровень ошибок. На этом уровне собирается информация об ошибках (например, падение при API-вызове или внутренняя ошибка).

• Критический уровень. Данные на этом уровне сообщают нам, когда мы должны прервать работу (например, сетевой агент (так называемый демон) не может подключиться к сетевому соединителю («сокету»)).

Выбор правильного уровня логирования важен. Дэн Норт, бывший консультант компании ThoughtWorks, принимавший участие в нескольких проектах, где были сформированы основные принципы непрерывной поставки ПО, замечает: «Когда вы решаете, должно ли сообщение звучать как ОШИБКА или ПРЕДУПРЕЖДЕНИЕ, представьте, что вас разбудили в четыре утра. Закончился тонер в принтере — это не ОШИБКА».

Чтобы убедиться, что у нас есть вся относящаяся к устойчивой и надежной работе приложения информация, нужно удостовериться, что все потенциально значимые события генерируют логи. Обязательно нужно учесть группы событий, собранные в списке Антона Чувакина, вице-президента по исследованиям, работающего в группе безопасности и риск-менеджмента подразделения GTP (Gartner for Technical Professionals) компании Gartner:

• решения о подтверждении прав доступа/авторизации (включая выход из системы);

• доступ в систему и доступ к данным;

• изменения системы и приложения (особенно изменения, связанные с правами доступа);

• изменения данных, такие как добавление, правка и удаление данных;

• некорректный ввод (возможный ввод вредоносных данных, угрозы и так далее);

• ресурсы (RAM, диск, процессор, пропускная способность соединения и любые другие ресурсы, имеющие жесткие или мягкие ограничения);

• работоспособность и доступность;

• загрузка и завершение работы;

• сбои и ошибки;

• срабатывание автоматического выключателя;

• задержки;

• успешное или неудачное резервное копирование[110].

Чтобы все эти логи было проще интерпретировать и понимать, стоит создать иерархические категории, такие как нефункциональные характеристики (например, качество работы, безопасность) и характеристики, связанные с функциональностью программы (например, поиск, ранжирование).

Оглавление книги