Event log

Scope: managed applications, ordinary applications.

1. Event log is the detailed records of user operations on an infobase. Administrators analyze the records, sometimes broken down by dimensions, to see the events created under a user account.

2. When some additional records, besides those added by 1C:Enterprise platform automatically, are required for configuration administration, add them programmatically. The required details might relate to both interactive user actions and background scheduled jobs. For better readability and efficiency, one record is related to one atomic operation and contains a number of required details records can be filtered by.

2.1. String ID of event type. Usually, a configuration contains a large number of event types. For better experience, group event types by their purpose: "Event group name.Event name." For example, you can combine events into the Tasks group:

"Tasks.New task notification"
"Tasks.Pending task notification"

instead of the two event types:

"New task notification"
"Pending task notification"

Event types are used for filtering log records and must not include redundant information such as specific values from an infobase or external systems. Incorrect:

Cannot unpost document <Sales KP00-00002 dated 11/10/2020>
Employee John Smith with bank card 3333 is not found in the infobase

Instead, place metadata in the Metadata parameter and data in the Data parameter of the WriteLogEvent method, and use more generic event types. Correct:

Document posting.Cannot unpost
Employees.Employee not found in the infobase

The event type strings must be localizable.

2.2. Event severity. Critical events, which require greater attention of the administrator, such as business logic errors and application malfunctions, are labeled as "Error." Could-be issues and non-critical errors are registered as "Warning." Successful operation records are labeled as "Information." The lowest possible severity level is "Comment."

2.3. Comment. Contains arbitrary event details. If an error occurs, this field will contain the information required to diagnose the issue. One comment must contain details only about a single event. Incorrect single record:

[01/01/2020 00:00:01] Start of initialization of data exchange by the setting "Data exchange export", line #: 1
[01/01/2020 00:00:02] Data exchange initialization succeeded.
[01/01/2020 00:00:03] Start of data exchange by the setting "Data exchange export", line #: 1.
[01/01/2020 00:00:04] Start of writing changes to the exchange file.
[01/01/2020 00:00:05] Writing changes to the exchange file succeeded.
[01/01/2020 00:00:06] Complete data exchange by the setting "Data exchange export", line #: 1.
[01/01/2020 00:00:07] Completed data export, 1 object processed.

Correct: each event must be added as an individual record.

Comments must not include text data of unknown and potentially large size, such as the contents of files or web service responses. The maximum size should be limited to 10 Kb.

Comment text must be localizable. To record the details about an exception, use the following code:

ErrorProcessing.DetailErrorDescription(ErrorInfo())

Example of recording events in the "My feature" subsystem:

Try
WriteLogEvent(NStr("en = 'My feature.Potentially faulty operation.'", DefaultLanguageCode),
EventLogLevel.Information, , ,
NStr("en = 'Operation started.'"));
ActionWithPotentialError(ActionObject);
WriteLogEvent(NStr("en = 'My feature.Potentially faulty operation.'", DefaultLanguageCode),
EventLogLevel.Information, , ,
NStr("en = 'Operation completed.'"));
Except
WriteLogEvent(NStr("en = 'My feature.Potentially faulty operation.'", DefaultLanguageCode),
EventLogLevel.Error, , ,
NStr("en = 'Unknown error occurred performing the action.'") + Chars.LF +
ErrorProcessing.DetailErrorDescription(ErrorInfo()));
EndTry;
EndProcedure

where DefaultLanguageCode contains the default configuration language code. For more details, see Localization guidelines — Autogenerated data, item 1.

3. In case filtering performance is crucial, it is not recommended that you filter events. The reason it that the filter performance is inversely proportionally to its size.

Instead, create individual registers for the required events or use designated 1C:Enterprise objects, such as BackgroundJobsManager to get background job records.

Consider this aspect when you develop even log reports.

See also:

Localization requirements — Interface strings in modules

<< Prev Next >>