Распределенные приложения сложны и влекут за собой свой собственный караван трудностей с отладкой и исправлением проблем в продакшене. Хотя микросервисная архитектура и дает возможность справляться силами меньшей команды, которая работает автономно и фокусируется на разных областях бизнеса, из-за своего распределенного характера она подкидывает нам новые проблемы. Например, в случае возникновения проблемы во время бизнес-транзакции, запрос необходимо отслеживать от начала и до конца, что может охватывать несколько служб и инфраструктур. Некоторые из трудностей таковы:
Нужно как-то справляться не только с известными, но и неизвестными ошибками.
Ошибки тоже распределенные.
Устаревшие системы мониторинга вам не помогут.
Именно здесь на поле выходят мониторинг и наблюдаемость (monitoring and observability). В рамках мониторинга регистрируется общее состояние приложения, а наблюдаемость помогает глубже копнуть в контекстные данные. В течение всего марта мы были сосредоточены на предоставлении вам самого актуального контента о микросервисах. На выставке .NET мы с Сесилом подробно рассказали о наблюдаемости и мониторинге в облачном приложении.
В приведенном выше видео мы рассмотрели ключевые элементы наблюдаемости и мониторинга, такие как логирование, метрики и трейсинг, и подробно рассмотрели проверки работоспособности (Health checks).
Вот некоторые из основных концепций, обсуждаемых в видео:
Проверки работоспособности (Health checks)
Проверки работоспособности в микросервисах реализуются в основном на HTTP-эндпоинтах, которые могут запрашиваться различными системами мониторинга в реальном времени. Как минимум, эндпоинты проверки работоспособности должны отвечать на следующие вопросы:
Работает ли система?
Может ли она выполнять задачи?
В мире Kubernetes это напрямую перетекает в тесты жизнеспособности и готовности (liveness and readiness probes) соответственно. Они определены в YAML-файле конфигурации развертывания Kubernetes.
Путь liveness является конечной точкой, которую Kubernetes периодически запрашивает, чтобы проверять наличие сбоев. Kubernetes проводит тесты работоспособности для обнаружения сбойных приложений и перезапускает их, если они не возвращают коды успеха.
Путь readiness является конечной точкой, которую Kubernetes периодически запрашивает, чтобы узнать, когда служба готова начать прием трафика. Он возвращает код состояния HTTP 200, когда все зарегистрированные проверки пройдены успешно.
ASP.NET Core предлагает проверки работоспособности, middleware и библиотеки для отчетов о работоспособности в систему мониторинга. Если вы новичок в этом, то начать стоит с Проверок работоспособности в ASP.NET Core.
Логирование
Независимо от того, какие инструменты вы используете для исследования проблем в продакшн среде, в конце концов, именно логи всегда раскрывают вам основную причину проблемы. В распределенных приложениях вам необходимо как следует позаботиться о том, чтобы записи в логах содержали подробную информацию для отладки, и их можно было запросить из центрального места. Каждая запись в логе должна иметь идентификатор корреляции, чтобы их можно было отследить по конкретным транзакциям и получить полную картину.
Структурированное логирование
Используя структурированное логирование, вы можете добавлять в логи сериализованные объекты, которые запрашиваются системами мониторинга логов. Например, вы можете запросить весь лог транзакций на основе customerID или transactionID. В приложениях ASP.NET Core вы можете использовать инструмент Serilog, реализующий структурированное логирование. Для начала почитайте Логирование в .NET Core и ASP.NET Core, а затем можете ознакомиться с Serilog для улучшения понимания структурированного логирования.
Централизованное логирование и идентификатор корреляции
В традиционных приложениях файлы логов хранятся на локальном компьютере. Логирование в неструктурированный файл на одной машине практически бесполезно в распределенной среде. Приложения, генерирующие логи, могут не иметь доступа к локальному диску, или локальный диск может быть временным, поскольку контейнеры перемещаются по виртуальным машинам. Из-за проблем, связанных с использованием файловых логов, в облачных приложениях предпочтительнее использовать централизованные системы логирования. Логи собираются приложениями и отправляются в центральное приложение логирования, которое индексирует и сохраняет их. Системы этого класса могут обрабатывать десятки гигабайт логов каждый день. Serilog предоставляет приемники данных (sinks) для логирования событий в централизованных системах, таких как Azure Application Insights (фичи Azure Monitor). Также полезно следовать некоторым устоявшимся практикам логирования, охватывающего множественные сервисы. Например, генерация идентификатора корреляции (correlation ID) в начале транзакции и последующая его регистрация в каждом сообщении, относящемся к этой транзакции, упрощает поиск в централизованных системах логирования всех взаимосвязанных сообщений.
Распределенная трассировка
Распределенная трассировка (distributed tracing) — это эквивалент стеков вызовов для современных облачных архитектур и архитектур микросервисов, приправленный профилировщиком производительности. Распределенная трассировка или распределенная трассировка запросов помогает отслеживать запрос от начала и до конца его жизненного цикла и позволяет идентифицировать проблему целостно. Трассировка может дать вам подробные ответы на такие вопросы, как «В какое время произошло событие? Как много времени это заняло? Почему это заняло так много времени? Какой микросервис его обрабатывал?» и т.д. В этой сфере широко распространены распределенные системы трассировки с открытым исходным кодом, такие как openzipkin/zipkin.
Реализация распределенной трассировки в вашем приложении может заключаться всего лишь в добавлении SDK соответствующего поставщика распределенной трассировки в каждый микросервис. Например, если пакет SDK Application Insights в вашем приложении уже установлен и настроен, трассировочная информация для популярных фреймворков, библиотек и технологий уже автоматически собирается авто-сборщиками для зависимостей SDK.
При использовании нескольких различных систем и инструментов существует потребность в стандартизации для обеспечения наблюдаемости. OpenTelemetry стандартизирует то, как разные приложения и платформы собирают и передают телеметрию состояний. OpenTelemetry предоставляет платформонезависимую спецификацию, набор API, SDK, а также инструменты и интеграцию для телеметрии (распределенная трассировка, метрики и т. д.). Ознакомьтесь с блогпостом OpenTelemetry .NET версии 1.0, если вас интересует более подробная информация.
Практические модули
Мы создали ряд модулей, которые помогут вам научиться создавать микросервисы .NET и облачные технологии. Ознакомьтесь с приведенными ниже модулями, которые помогут вам дучше понять мониторинг и наблюдаемость.
Для проверки работоспособности ознакомьтесь с разделом Создание и развертывание облачного микросевиса ASP.NET Core.
Для мониторинга и наблюдаемости ознакомьтесь с разделом Инструментация облачных микросервисов ASP.NET Core.
Материал подготовлен в рамках курса «C# ASP.NET Core разработчик».
Всех желающих приглашаем на открытый урок «Развертывание ASP.NET Core приложений в Azure». На вебинаре мы рассмотрим, что из себя представляет облачная платформа Azure, а также проведем демо по развертыванию ASP.NET Core приложения с помощью Azure App Service.
РЕГИСТРАЦИЯ