- Создаем собственный журнал событий в Windows
- Журнал событий (Event Logging)
- Win32: централизованное протоколирование событий
- Предисловие
- Теория
- Рекомендации по протоколированию событий
- События в журнале
- Элементы журнала событий
- Журналы
- Источники событий
- Практика
- Файл сообщений
- Категории событий
- Идентификаторы событий
- Строки сообщений
- Регистрация источника событий
- Использование журнала событий
- Послесловие
Создаем собственный журнал событий в Windows
Как вы знаете, большинство «нормальных» приложений записывают свои события в журнал событий Windows (Application Event Log). Это отличное место для централизованного хранения и просмотра событий приложений, однако зачастую при возникновении необходимости журналировать события от определенного приложения в данном журнале, мы можем столкнуться с тем, что из-за большого количества и чрезмерной подробности событий, работать со стандартным журналом приложений Windows становится очень неудобно. В данном случае было бы удобно создать собственный журнал событий для данного приложения, и для него настраивать различные параметры, такие как размер журнала, фильтры и т.д., а стандартный журнал Application можно использовать как обычно, не засоряя его ненужной информацией. В ОС семейства Windows присутствует функция, позволяющая создать собственный журнал событий.
Сначала создадим новый файл журнала. Сделать это можно при помощи реестра. Запустите редактор реестра regedit и перейдите в ветку:
Щелкните правой кнопкой по узлу Eventlog и создайте новый ключ (New > Key)
Имя ключа в этом случае будет являться и именем нового журнала. По умолчанию новый журнал (файл .evt) создается тут:
Его можно переименовать, изменив строковый параметр в реестре по своему усмотрению.
Далее нужно добавить источники (Sources) событий для нового журнала. Создайте новый ключ типа Multi-String с именем “Sources”, в качестве параметров укажите имена всех приложений, который будут использовать данный журнал (каждое приложение с новой строки).
Затем нужно перенести ассоциации ваших приложений из стандартного журнала Application в ваш новый журнал. Разверните ветку “Application”, находящуюся по адресу:
И скопируйте все ветки, которые относятся к интересуемым Вами приложениям в новый ветку реестра нового журналa:
Т.к. команда скопировать/вставить в редакторе реестра не работает, их можно пересоздать вручную (если их немного), или же можно осуществить перенос при помощи процедуры экспорта/импорта веток реестра с ручным редактирование .reg файла. Убедитесь, что после переноса вы удалили ключи реестра ваших приложений из ветки Application, иначе Windows не поймет, что нужно писать события в новый журнал. В том случае, если вы используете новый источник событий для журнала, нужно будет создать параметр типа DWORD с именем CustomSource и значением равным 1:
В моем примере, я создал собственное приложение .NET 2.0, причем я хочу, чтобы оно записывало события в созданный нами журнал. Для этого я создам новый ключ реестра EventMessageFile и укажу в нем путь к библиотеке журналирования.NET 2.0:
Затем нужно перезагрузить Windows, а после загрузки системы вы увидите новый журнал событий в разделе Event Viewer-а. В том случае, если ваше приложение по какой-либо причине не пишет событий в новый журнал, можно протестировать его работу вручную, откройте командую строку и перейдите в каталог:
В том случае, если вы все сделали правильно должно появиться окно, сообщающее о том, что событие было успешно записан в журнал, либо сообщение об ошибки и причины ее появления.
Update:
Небольшое обновление статьи по письмам читателей:
Вышеприведенная инструкция по созданию собственного журнала ориентирована на серверные ОС семейства Microsoft. Более общий способ, который должен работать в большинстве Windows следующий (отличаются пути в реестре и ключи):
Создаем новый раздел в реестре (имя раздела — имя создаваемого журнала), путь к созданному будет таким:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\NewEventLog , в котором нужно создать следующие ключи:
- «AutoBackupLogFiles» — тип DWORD, создавать или нет резервные копии журнала (0 — не создавать)
- «MaxSize» -тип DWORD, максимальны размер журнала в байтах, значение должно быть кратным 64Кб
- «Retention» — тип DWORD, время хранения записей в случае переполнения журнала.
- «File» — тип REG_EXPAND_SZ, строка, в которой содержится путь к логу журнала на жестком диске, например %SystemRoot%\System32\config\NewEventLog.evt)
- «Sources»- тип REG_MULTI_SZ, здесь указан список источников событий, чьи логи должны попадать в этот журнал, каждый источник с новой строки
Журнал событий (Event Logging)
Win32: централизованное протоколирование событий
Автор: Серебряков Алексей (Smooky)
QUIBECK INC.
Источник: RSDN Magazine #3-2007
Опубликовано: 14.11.2007
Исправлено: 10.12.2016
Версия текста: 1.0
Предисловие
Многие из Вас, наверное, принимали участие в крупных и долгосрочных проектах, где разрабатывалось приличное количество модулей, использовались многочисленные библиотеки, сценарии и т.д. Мне тоже приходилось участвовать в таких проектах. Один из них и натолкнул меня на мысль о создании этой статьи. В том проекте участвовало множество программистов, разработчиков и тестеров. Каждый разработчик писал небольшой модуль протоколирования (логирования, от англ. logging, — снимать, записывать показания с прибора) и трассировки своих модулей и наработок. Кто-то писал свои утилиты, которые потом разбирали эти протоколы, кто-то использовал буферизованный вывод, т.е. какого-то чёткого регламента по этой деятельности не было. Результатом всей этой деятельности стало большое количество разбросанных текстовых и бинарных файлов с понятными и непонятными расширениями, непонятного формата и содержания. Понятно, что при такой организации так и должно было случиться. Хуже того, бывает и так, что при выходе финальной версии не удаётся всё это убрать, и всё это оказывается у пользователя и заказчика.
Для решения этой проблемы операционная система Windows предоставляет такой сервис и программный интерфейс, как Eventlog. Этот инструментарий относится к числу базовых сервисов Windows, т.е. поставляется с самой системой и система сама же его использует. Стоит заметить, что эта возможность есть только у систем семейств WinNT/XP, т.к. приложение для протоколирования событий является сервисом. Также стоит заметить, что в Windows Vista и Windows Longhorn этот сервис существенно переработан, новый вариант в этой статье рассматриваться не будет.
Мы не будем также рассматривать этот замечательный инструмент с точки зрения администраторов, сборщиков журналов и прочих персон, которые призваны управлять системой. Итак, приступим.
Теория
Рисунок 1.
Наверное, почти все разработчики используют в своих программах протоколирование событий при выявлении ошибок, отладке и диагностировании приложений. Но даже после успешного сбора и просмотра статистики иной раз бывает сложно проанализировать, что же всё-таки случилось и в каком месте? Так вот, сервис «Журнал событий» является стандартным, централизованным способом сбора статистики и просмотра сообщений о событиях, поступающих от приложений, сервисов операционной системы и аппаратных устройств. Средство для просмотра этих событий является оснасткой Microsoft Management Console. В Windows XP Rus эта оснастка запускается так: Пуск->Настройка->Панель управления->Администрирование->Просмотр Событий (Event Viewer).
| ПРЕДУПРЕЖДЕНИЕ При использовании сервиса протоколирования в журнал следует записывать достаточно важные и нужные сведения о происшедших ошибках, которые действительно потом могут помочь разработчикам разобраться, что же произошло с приложением. Не следует, например, писать в системный журнал с периодичностью 100нс сообщения о том, что пользователь случайно удалил файл readme.txt. Журнал событий – это не средство трассировки. Рекомендации по протоколированию событийПри описании событий в журнале старайтесь придерживаться следующих рекомендаций, это поможет вам сделать журналы событий удобочитаемыми и опрятными. Помните, что журналы — это уже не только ваши собственные файлы трассировки, а разделяемый сервис, и не только вы ими пользуетесь. Сообщение в журнале событий – это, прежде всего, информация, способная помочь вам, администратору и даже пользователю понять, какая проблема возникла в приложении и как её устранить. В частности, это событие может предназначаться специалисту технической поддержки в вашей компании, и даже ему будет тоскливо читать сообщение: «Процесс А не смог прочитать 0x05 байт 0x2-ого сектора дисковода В». Поэтому идеальное сообщение должно помочь пользователю ответить на следующие вопросы:
Могут пригодиться и следующие рекомендации:
Соглашения о стиле содержания сообщения:
Это неполный список рекомендаций, взятый из MSDN. На самом деле в популярных книгах, например, у Саттера, есть более интересные рекомендации. События в журналеВ журнал можно записывать пять типов событий. Все типы событий достаточно понятно классифицированы, определены и могут включать много дополнительной информации. Каждое событий, которое мы посылаем из своего приложения, может иметь только один тип. Определены следующие типы событий:
Поскольку запись в журнал может происходить нечасто, в тексте сообщения следует достаточно полно описывать происшедшее событие. Следует достаточно понятно описывать событие, так как информацию о событии, до того как она попадёт к разработчику, может просмотреть, например, администратор системы и не придав ей особого значения, просто проигнорировать.
|
