Configuring the 1C-Bitrix event log

Setting up event journal in 1C-Bitrix

Event journal in Bitrix (b_event_log) — built-in audit mechanism that by default works in minimal configuration. Out of the box it logs logins and critical system operations, but doesn't record business actions: catalog changes, order operations, iblock actions. Journal setup — this is bringing it to state where it's really useful for incident resolution.

Enabling and basic configuration

Journal management: Settings → Product settings → Module settings → Main module → "Event Journal" tab.

Parameters to set:

• Record events — enable (may be disabled by default)
• Record retention time — recommended 90 days for production, 30 days for dev environment
• Event types — mark all necessary categories

Available event types in stock setup:

Viewing and filtering

Journal accessible in Settings → Tools → Event Journal. Interface supports filtering by:

• Event type (AUDIT_TYPE_ID)
• Module (MODULE_ID)
• User (USER_ID)
• Period (TIMESTAMP_X)
• Severity level (SEVERITY: INFO, WARNING, SECURITY)

Stock interface problem — lack of full-text search by DESCRIPTION field. If you need to find specific change, use SQL:

SELECT * FROM b_event_log
WHERE AUDIT_TYPE_ID = 'IBLOCK_ELEMENT_UPDATE'
  AND DESCRIPTION LIKE '%"PRICE"%'
  AND TIMESTAMP_X >= '2024-01-01'
ORDER BY TIMESTAMP_X DESC
LIMIT 100;

Extending event list

Stock event set covers security, but not business logic. To add custom event types use CEventLog::Add():

CEventLog::Add([
    'SEVERITY' => 'INFO',
    'AUDIT_TYPE_ID' => 'CUSTOM_ORDER_STATUS',
    'MODULE_ID' => 'sale',
    'ITEM_ID' => $orderId,
    'DESCRIPTION' => "Status changed: $oldStatus → $newStatus",
]);

Custom types automatically appear in journal filter. Recommended to use prefix (CUSTOM_) to distinguish from stock types.

Auto-cleanup setup

Without rotation, b_event_log table grows to hundreds of thousands of records. Auto-cleanup configured via agent:

CAgent::AddAgent(
    "CEventLog::CleanUpAgent();",
    "main",
    "N",
    86400  // once a day
);

Agent deletes records older than period set in module settings. If you need archive — export data via CEventLog::GetList() to CSV or separate table before cleanup.

Security monitoring via journal

Practical minimum for tracking suspicious activity:

• Brute force — more than 5 USER_LOGIN_FAILED records from one IP in 10 minutes
• Privilege escalation — USER_EDIT event with group change to administrator
• Mass deletion — series of element deletion events in short time span

For automatic notification on these situations you need separate analyzer script, running by cron, which parses fresh records and sends notification via CEvent::Send().

Event journal setup — one working day task. Result: full visibility of critical user actions with rotation and quick incident search.