При разработке кода на Angular принято записывать диагностическую информацию в консоль. Это полезно при разработке, но вам нужен способ предотвратить отправку подробных данных журнала при развертывании приложения в производственной среде.
В этой статье я объясню, как создать настраиваемое средство ведения журнала, которое упрощает развертывание в отдельных средах с настраиваемыми уровнями ведения журнала.
Вход в систему разработки
При написании кода Angular я неизменно добавляю код регистрации, чтобы отобразить состояние системы, чтобы помочь мне понять, что происходит во время выполнения. Обычно это просто код, который выводит сообщения на консоль.
На следующем изображении показан пример операторов ведения журнала, записываемых в консоль.
Все мои операторы ведения журнала начинаются с имени класса и используют разные уровни ведения журнала, такие как Информация, Предупреждения и Ошибки, чтобы упростить фильтрацию сообщений с помощью инструментов разработки. Такой формат сообщений помогает диагностировать проблемы, когда они возникают.
На следующем изображении показаны сообщения, отфильтрованные для отображения только сообщений информационного уровня от моего средства защиты AuthGuard.
Со временем объем информации, записываемой на консоль, становится огромным, но имеет достаточную ценность для разработки, поэтому нам нужно найти способ управлять ею.
В ходе этой статьи мы будем разрабатывать службу ведения журнала, которая настраивается через внешний источник конфигурации. Операторы ведения журнала затем будут маршрутизироваться через службу ведения журнала, как показано в следующем примере.
Конфигурация аутсорсинга
Первым шагом в предоставлении настраиваемого регистратора является создание внешнего источника конфигурации, который упростит задачу настройки конфигураций, специфичных для среды. Начните с моделирования простой службы для поддержания свойства уровня ведения журнала.
Данные конфигурации будут храниться во внешнем файле конфигурации с именем config.json, который по умолчанию содержит следующее содержимое.
Этот файл можно преобразовать в конвейерах сборки и выпуска, чтобы изменить уровень ведения журнала в зависимости от переменных среды.
Для нашего приложения нам нужно инициализировать уровень ведения журнала, прочитав его из нашего файла конфигурации. К счастью, Angular поставляется с APP_INITIALIZER, который позволяет нам писать функцию, которая запускается при инициализации приложения.
В следующем фрагменте мы используем поставщика APP_INITIALIZER для выполнения настраиваемой функции с именем loadConfig для чтения из нашего файла конфигурации и установки значения свойства loggingLevel в ConfigService.
Это все, что касается нашей службы настройки. Следующая задача - создать службу ведения журнала и внедрить ее с помощью службы конфигурации, чтобы мы могли условно выдавать данные журнала на основе настроенного значения уровня ведения журнала.
Служба регистрации
Создайте новую службу и прочтите уровень ведения журнала из нашей конфигурации, например, так.
В основе службы ведения журнала лежит метод журнала, который принимает сообщения журнала и записывает их в консоль с использованием метода, основанного на желаемом уровне ведения журнала и с учетом нашего настроенного уровня.
Это довольно простой метод. Вначале он вызывает закрытый метод с именем shouldLog, который определяет, должно ли текущее сообщение регистрироваться в соответствии с нашим настроенным уровнем.
В следующем коде показана логика метода shouldLog.
Наконец, несколько вспомогательных методов, которые упростят ее использование потребителями службы ведения журнала.
Заключение и следующие шаги
В этой статье мы рассмотрели, как экспортировать данные конфигурации и использовать конфигурацию среды для условного отображения сообщений журнала.
Я рекомендую вам прочитать мою статью Развертывание в Firebase из Azure DevOps, чтобы увидеть пример того, как преобразовать файл конфигурации из конвейера выпуска.
Отсюда вы можете рассмотреть возможность расширения регистратора для отправки сообщений в централизованное хранилище телеметрии, такого как Application Insights, или интеграции с Angular ErrorHandler.
Надеюсь, вам эта статья показалась интересной, и удачи в ваших будущих приключениях с логированием в Angular!
