В данной статье рассматриваются критерии выбора профессиональных решений для протоколирования.
1. Основные
1.1. Протоколирование простых текстовых сообщений
Таких как отладочная информация или ошибки и связанная с ними информация, такая как время.
1.2. Уровни логов для фильтрации сообщений
Большинство инструментов протоколирования позволяют разработчикам указывать уровень лога, такой как debug, info, warning и error для каждого сообщения и фильтровать сообщения по степени важности. В зависимости от пользователя ему могут быть интересны сообщения определенного уровня. Например, разработчикам необходима более детальная информация в процессе отладки.
1.3. Множественные соединения или цели
Платформы протоколирования часто позволяют разработчикам писать или отсылать отладочную информацию в несколько соединений или целей (БД, email, WindowsEventlog, MSQueue и тд) и поддерживают несколько протоколов, такие как лог файлы или сетевые соединения. Желаемые соединения или цели могут быть изменены в run-time, для это достаточно изменить настройки приложения.
1.4. Категории или сессии лога
Большинство библиотек трассировки или протоколирования поддерживают функцию группировки сходных отладочных сообщений в категории или сессии. Это позволяет разработчикам группировать все вхождения лога для специального модуля приложения или пользовательской сессии и разрешает или запрещает ведение журнала для этой группы сообщений независимо от другого логического кода.
1.5. Чередование лог-файлов
Когда приложение выполняется достаточно долго (например, сервер приложений), часто возникает необходимость разделить лог-файлы на несколько файлов меньшего размера (предопределенный срок). Это позволяет, например, хранить информацию в отдельном лог-файле за каждый день с уникальным именем, которое идентифицируется как дата.
1.6. Загрузка настроек протоколирования из файла конфигурации
Некоторые библиотеки протоколирования позволяют загружать настройки протоколирования из конфигурационного файла. Это позволяет разработчикам и поддерживающему персоналу легко изменять настройки протоколирования во время выполнения программы (run-time) без изменения самих приложений.
1.7. Платность
1.8. Размер
В эпоху огромных накопителей информации этот параметр имеет небольшое значение. Но, я считаю, признаком хорошей платформы протоколирования является меньший размер при большой функциональности.
1.9. Жизнеспособность
Платформа должна быть живой. Чтобы была маленькая вероятность того, что её перестанут сопровождать.
1.10. Интегрируемость с MS Visual Studio
1.11. Документирование
1.12. Легкость освоения
2. Расширенные (дополнительные)
2.1. Высокая пропускная способность или производительность
Протоколирование часто используется в течении production usage и не только в процессе отладки. Производительность является решающим фактором при выборе платформ протоколирования.
2.2. Протоколирование комплексных структур данных
Некоторые инструменты протоколирования также поддерживают протоколирование сложных структур данных, таких как объекты, бинарные данные, стек исключения, скриншоты, результаты базы данных и тд, позволяя разработчикамвидеть больше смысла в данных протоколирования по сравнению с только регистрацией простых текстовых сообщений.
2.3. Потоко-безопасность
Важной особенностью серьезных библиотек протоколирования является потоко-безопасность. Это означает, что можно вызывать и получать доступ к логгеру из нескольких потоков, не вызывая deadlocks, условий гонки или других потокоотносящихся проблем. Кроме того, механизм синхронизации должен быть максимально быстр и максимально ненавязчив, чтобы свести к минимуму блокировок потока.
2.4. Вызов трассировочных методов
Позволяют разработчикам легко понять, какие методы вызываются, в каком порядке они вызываются и сколько им нужно времени для выполнения. Это особенно полезно для оптимизации и тонкой настройки кода, понимание и следование логике ошибки.
2.5. Просмотр и протоколирование значение переменных
Очень часто бывает полезно посмотреть значения переменных отдельно от лог-сообщений для того, чтобы следить за значениями переменных и системной информацией, такой как соединение БД, потоков и памяти.
2.6. Поведение потока протоколирования и процесса
При разработке распределенных и/или многопоточных приложений, часто полезно знать, сколько потоков и процессов запущено, что каждый поток делал и как долго поток или процесс был запущен. Расширенное платформы протоколирования позволяют разработчикам отслеживать поведение потоков и процессов.
2.7. Расширенные протоколы и соединения
Расширенный протоколы, такие как протоколирование в память или протоколирование через именованные каналы важны для настройки протоколирования с особыми требованиями. Расширенный протокол такие настройки, как переподключение, интервалы переподключения и буфферы позволяют выполнять тонкую настройку протоколов и соединений для производственного использования.
2.8. Асинхронное протоколирование и очереди backlog
Чтобы уменьшить блокировку кода приложения в высокопроизводительных и масштабируемых приложениях, асинхронное протоколирование и отставание очередей (backlog) позволяет разработчикам дорабатывать протоколирование в отношении производственной производительности и поведения блокировок.
2.9. Лог сервера приложения
В ситуации, когда необходимо централизованное хранение журнала или когда несколько процессов должны писать в один файл, лог сервера необходим для получения лог-данных из нескольких источников и объединение их в центральном местоположение.
3. GUI
Очень хорошо, если платформы обладают собственным просмоторщиком протоколирования. Какие фичи могут быть полезны.
3.1. Приложение графического просмотра
Графические приложения для просмотра, что позволяет анализировать данные лога и мониторинга приложений в реальном времени, могут существенно сократить время, затрачиваемое время на поиск выполнения вопросов, то после применения логики и исправления ошибок приложения.
3.2. Расширенные возможности фильтрации
Полезно чтобы просмоторщик позволял фильтровать для различных записей в журнале такие атрибуты, как категории / сессия, приложение, идентификатор потока, идентификатор процесса, запись в журнале тип, TIMESTAMP или текстового сообщения. Фильтрация особенно важна при анализе лог-файлов с огромным количеством записей журнала.
3.3. Навигация
Специальные функции, облегчающие навигацию через журналы такие как прыжки между журнальными записями, переход к методам и поиск конкретных сообщений является неотъемлемой функцией для инструментов просмотра логов.
3.4. Стеки вызовов, графики и подробные сообщения
Отдельное окно для просмотра стека вызовов, графиков для значений переменных и подробных сообщений - помощь в понятии смысла из больших файлов журнала и при мониторинге приложений в режиме реального времени.
3.5. Несколько представлений или окон
Это часто бывает полезно для просмотра записей в журнале различных программных модулей, потоков или процессов в отдельных представлениях или окнах. Это позволяет разработчикам легко понять, что каждый поток работает и где возникла ошибки. Передовые приложения просмотра также позволяют автоматически создавать представления по определенным критериям, таким как новые потоки, процессы или модули приложений.
3.6. Мониторинг в реальном времени через сеть или pipes
Одной из наиболее полезных функций просмотра приложений является способность контролировать приложения в режиме реального времени, получая лог-сообщения по сети или по именованным каналам. Это позволяет разработчикам и администраторам осуществлять мониторинг систем производства и место ошибки, когда они возникают.
3.7. Просмотр и проверка данных приложения
Помимо просмотра журнала сообщений и информации, такой как стеки вызовов, некоторые приложения для просмотра также оказывают дополнительное применение данных при записи журналов, таких как изображения (например, скриншоты), базы данных результатов, файлы сценариев, свойства объекта, двоичные данные и многое другое. Это позволяет легко просматривать и проверки данных приложения.
Комментариев нет:
Отправить комментарий