This article describes the standards that apply to event log records. All of the listed recommendations are mandatory unless noted otherwise.
1. The event log is intended for recording events that occur during the user work with the infobase. Administrators often need this data, filtered in some way, to learn what hapened during a specific period or which actions a specific user performed.
2. We recommend that you add event log records using 1C:Enterprise script tools when administrators might need diagnostics data about events that are not automatically registered by the platform. For example, you can record events during the interactive execution of business logic, as well as during the execution of background (scheduled) jobs. To simplify the log analysis, a single record must describe a single event, and each record must have a set of mandatory attributes that can be used for filtering the log.
2.1. String ID of the event type. The list of configuration event types can be quite large, so we recommend that you group the types by functionality: "Event group.Event name". For example, use the names "Assignments. New task notification" and "Assignments.Overdue task notification" instead of "flat" names "New task notification" and "Overdue task notification". Event types must be localized, with the main configuration language specified as the last NStr() parameter.
2.2. Log level. Critical events that require administrator attention, such as business logic errors and software malfunctions, have the "Error" level. Possible problems and nonfatal errors have the "Warning" level. Messages informing about successful operation completions have the "Information" level. You can also use the "Note" level for the least important events.
2.3. Comment. A custom text description of the event. For errors this field must contain information required to identify the cause. Do not describe multiple events in a single comment. For example, the following comment to a single event is incorrect:
[01/01/2014 00:00:01] Starting data exchange initialization with "Data exchange dump" settings, settings line number:1 [01/01/2014 00:00:02] Completing data exchange initialization (success) [01/01/2014 00:00:03] Starting data exchange with "Data exchange dump" settings, settings line number:1 [01/01/2014 00:00:04] Starting writing changes to the exchange file [01/01/2014 00:00:05] Completing writing changes to the exchange file (success) [01/01/2014 00:00:06] Completing data exchange with "Data exchange dump" settings, settings line number:1 [01/01/2014 00:00:07] Completed: data exchange. 1 object(s) processed.
Instead, write an individual record for each of the events.
The comment text must be localized.
To get exception descriptions for writing to the event log, use the following expression:
Example of registering a custom event in the "MyFeature" functional subsystem:
Try WriteLogEvent(NStr("en='MyFeature.Handling possible error'", DefaultLanguageCode), EventLogLevel.Info, , , NStr("en = 'Starting action'")); HandlePossibleError(ObjectToProcess); WriteLogEvent(NStr("en='MyFeature.Handling possible error'", DefaultLanguageCode), EventLogLevel.Info, , , NStr("en = 'Completing action'")); Except WriteLogEvent(NStr("en='MyFeature.Handling possible error'", DefaultLanguageCode), EventLogLevel.Error, , , NStr("en = 'Unknown error.'") + Chars.LF + DetailErrorDescription(ErrorInfo())); EndTry
In this example the DefaultLanguageCode variable stores the default configuration language code. For more information, see Code writing standards for easier localization, paragraph 8.1.
3. Do not use selections from the event log in tasks where the selection performance matters. This is because the selection time gets slower for larger logs.
We recommend that you create a dedicated register for recording events of particular interest, or use specific platform objects (for example, BackgroundJobsManager for getting the background job execution history).
Also keep this recommendation in mind when developing event log reports.