Шаблоны наблюдаемости
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Так же, как были разработаны шаблоны, помогая в макете кода в приложениях, существуют шаблоны для операционных приложений надежным способом. Появились три полезных шаблона в обслуживании приложений: ведение журнала, мониторинг и оповещения.
Когда следует использовать ведение журнала
Независимо от того, насколько тщательно мы, приложения почти всегда ведут себя непредвиденными способами в рабочей среде. Когда пользователи сообщают о проблемах с приложением, полезно видеть, что происходит с приложением при возникновении проблемы. Одним из самых проверенных и верных способов записи сведений о том, что делает приложение во время его работы, является запись приложения в том, что он делает. Этот процесс называется ведением журнала. В любое время ошибки или проблемы возникают в рабочей среде, необходимо воспроизвести условия, в которых произошли сбои, в нерабокой среде. Наличие хорошего ведения журнала позволяет разработчикам следовать за тем, чтобы дублировать проблемы в среде, с которой можно протестировать и поэкспериментировать.
Проблемы при ведении журнала с помощью облачных приложений
В традиционных приложениях файлы журналов обычно хранятся на локальном компьютере. На самом деле в операционных системах, таких как Unix, существует структура папок, определенная для хранения журналов, как правило, под /var/log.
Рис. 7-1. Ведение журнала в файле в монолитном приложении.
Полезность ведения журнала в неструктурированный файл на одном компьютере значительно уменьшается в облачной среде. Приложения, создающие журналы, могут не иметь доступа к локальному диску или локальному диску может быть очень временным, так как контейнеры перемешиваются на физических компьютерах. Даже простое масштабирование монолитных приложений на нескольких узлах может затруднит поиск соответствующего файла журнала на основе файлов.
Рис. 7-2. Ведение журнала в файлах в масштабируемом монолитном приложении.
Облачные приложения, разработанные с помощью архитектуры микрослужб, также представляют некоторые проблемы для файловых средств ведения журнала. Теперь запросы пользователей могут охватывать несколько служб, выполняемых на разных компьютерах, и могут включать бессерверные функции без доступа к локальной файловой системе. Было бы очень сложно сопоставить журналы от пользователя или сеанса между этими многими службами и компьютерами.
Рис. 7-3. Ведение журнала в локальных файлах в приложении микрослужб.
Наконец, число пользователей в некоторых облачных приложениях является высоким. Представьте, что каждый пользователь создает сотни строк сообщений журнала при входе в приложение. В изоляции это можно управлять, но умножайте, что более 100 000 пользователей и объем журналов становится достаточно большим, чтобы специализированные инструменты нуждались в поддержке эффективного использования журналов.
Ведение журнала в облачных приложениях
Каждый язык программирования имеет средства, которые позволяют писать журналы, и, как правило, затраты на запись этих журналов низки. Многие библиотеки ведения журнала обеспечивают ведение журнала различных типов критических моментов, которые можно настроить во время выполнения. Например, библиотека Serilog — это популярная структурированная библиотека ведения журнала для .NET, которая предоставляет следующие уровни ведения журнала:
- Подробный
- Отладка
- Информация
- Предупреждение
- Ошибка
- Смертельно
Эти различные уровни журнала обеспечивают степень детализации в журнале. Если приложение работает правильно в рабочей среде, оно может быть настроено только для записи важных сообщений. Когда приложение работает неправильно, уровень журнала может быть увеличен таким образом, чтобы подробные журналы были собраны. Это балансирует производительность с легкостью отладки.
Высокая производительность средств ведения журнала и возможность детализации должны поощрять разработчиков часто регистрировать журналы. Многие предпочитают шаблон ведения журнала входа и выхода каждого метода. Такой подход может звучать как overkill, но это редко, что разработчики будут желать меньшего ведения журнала. На самом деле, это не редкость для выполнения развертываний для единственной цели добавления ведения журнала вокруг проблемного метода. Эрр на стороне слишком много ведения журнала и не слишком мало. Некоторые средства можно использовать для автоматического предоставления такого типа ведения журнала.
Из-за проблем, связанных с использованием журналов на основе файлов в облачных приложениях, централизованные журналы предпочтительнее. Журналы собираются приложениями и отправляются в центральное приложение ведения журнала, которое индексирует и сохраняет журналы. Этот класс системы может ежедневно получать десятки гигабайт журналов.
Также полезно следовать некоторым стандартным методикам при создании журналов, охватывающих множество служб. Например, создание идентификатора корреляции в начале длительного взаимодействия, а затем ведение журнала в каждом сообщении, связанном с этим взаимодействием, упрощает поиск всех связанных сообщений. Для поиска всех связанных сообщений необходимо найти только одно сообщение и извлечь идентификатор корреляции. Другой пример заключается в том, чтобы формат журнала был одинаковым для каждой службы, независимо от языка или библиотеки ведения журнала, которую он использует. Эта стандартизация упрощает чтение журналов. На рисунке 7-4 показано, как архитектура микрослужб может использовать централизованное ведение журнала в рамках рабочего процесса.
Рис. 7-4. Журналы из различных источников получаются в централизованное хранилище журналов.
Проблемы с обнаружением и реагированием на потенциальные проблемы работоспособности приложений
Некоторые приложения не являются критически важными. Может быть, они используются только во внутреннем режиме, и когда возникает проблема, пользователь может связаться с группой, ответственной и приложение можно перезапустить. Однако клиенты часто имеют более высокие ожидания для приложений, которые они используют. Вы должны знать, когда возникают проблемы с приложением перед выполнением пользователей или перед уведомлением пользователей. В противном случае первое, что вы знаете о проблеме, может быть, когда вы заметите сердитый сбой в социальных сетях, которые вы высмеив ваше приложение или даже вашу организацию.
Некоторые сценарии, которые могут потребоваться включить:
- Одна служба в приложении продолжает завершаться сбоем и перезапуском, что приводит к периодическим медленным откликам.
- В некоторые периоды дня время отклика приложения медленно.
- После недавнего развертывания загрузка базы данных в три раза больше.
Реализовано правильно, мониторинг может сообщить вам о условиях, которые поведут к проблемам, позволяя решать базовые условия, прежде чем они приводят к любому значительному влиянию пользователя.
Мониторинг облачных приложений
Некоторые централизованные системы ведения журнала принимают на себя дополнительную роль сбора данных телеметрии за пределами чистых журналов. Они могут собирать метрики, такие как время выполнения запроса базы данных, среднее время отклика с веб-сервера, а также даже среднее время загрузки ЦП и давление на память, как сообщает операционная система. В сочетании с журналами эти системы могут обеспечить целостное представление о работоспособности узлов в системе и приложении в целом.
Возможности сбора метрик для средств мониторинга также можно загружать вручную из приложения. Бизнес-потоки, представляющие особый интерес, такие как регистрация новых пользователей или размещение заказов, могут быть инструментированы таким образом, чтобы они добавили счетчик в централизованной системе мониторинга. Этот аспект разблокирует средства мониторинга, чтобы не только отслеживать работоспособность приложения, но и работоспособность бизнеса.
Запросы можно создать в средствах агрегирования журналов для поиска определенных статистических данных или шаблонов, которые затем можно отобразить в графической форме на пользовательских панелях мониторинга. Часто команды будут инвестировать в большие, подключенные к стене экраны, которые поворачиваются через статистику, связанную с приложением. Таким образом, просто увидеть проблемы по мере их возникновения.
Средства мониторинга на основе облака предоставляют данные телеметрии в режиме реального времени и аналитические сведения о приложениях независимо от того, является ли они монолитными приложениями или распределенными архитектурами микрослужб. К ним относятся средства, позволяющие собирать данные из приложения, а также средства для запроса и отображения сведений о работоспособности приложения.
Проблемы с реагированием на критические проблемы в облачных приложениях
Если вам нужно реагировать на проблемы с приложением, вам потребуется какой-то способ оповещения правильного персонала. Это третий шаблон наблюдаемости приложений в облаке и зависит от ведения журнала и мониторинга. Приложение должно иметь ведение журнала, чтобы разрешить диагностику проблем и в некоторых случаях передавать данные в средства мониторинга. Он должен отслеживать статистические метрики приложений и данные о работоспособности в одном месте. После установки этого правила можно создать, которые будут запускать оповещения, когда определенные метрики выходят за пределы допустимых уровней.
Как правило, оповещения сложены на основе мониторинга, чтобы определенные условия активировали соответствующие оповещения, чтобы уведомить членов команды о срочных проблемах. Некоторые сценарии, которые могут требовать оповещений, включают:
- Одна из служб приложения не отвечает через 1 минуту простоя.
- Приложение возвращает неудачные HTTP-ответы более чем на 1% запросов.
- Среднее время отклика приложения для ключевых конечных точек превышает 2000 мс.
Оповещения в облачных приложениях
Вы можете создавать запросы к средствам мониторинга для поиска известных условий сбоя. Например, запросы могут выполнять поиск по входящим журналам для указания кода состояния HTTP 500, который указывает на проблему на веб-сервере. Как только обнаружено одно из них, то может быть отправлено сообщение электронной почты или SMS владельцу исходной службы, которая может начать расследование.
Как правило, хотя одна ошибка 500 недостаточно, чтобы определить, что возникла проблема. Это может означать, что пользователь неправильно ввел пароль или ввел некоторые неправильные данные. Запросы генерации оповещений можно создавать только при обнаружении более 500 ошибок.
Одним из самых разрушительных шаблонов в оповещении является пожар слишком много оповещений для людей, чтобы исследовать. Владельцы служб быстро десенсизируются до ошибок, которые ранее расследовали и обнаружили, что они были доброкачественными. Затем, когда возникают истинные ошибки, они будут потеряны в шуме сотен ложных срабатываний. Примечания мальчика Кто Кричал волк часто говорю детям, чтобы предупредить их об этой самой опасности. Важно убедиться, что оповещения, которые делают пожар, свидетельствуют о реальной проблеме.
