Why the Default Log Isn't Enough
You check why an item was written off, but the log is empty. The built-in b_event_log only captures logins and critical system operations. Changes in the catalog, order statuses, infoblock operations — all bypass the logs. One project saw the table grow to 2 million records in six months, making it impossible to find anything. After configuring filters and custom types, search time dropped to one minute. We solve this: we set up the log end-to-end, expand the event list, implement rotation, and teach the system to filter what matters. A configured log outperforms the default 5x in search speed thanks to filtering by business events. Compare: the default interface shows hundreds of thousands of records without context; our configuration groups them by type, module and severity. Now let's dive into how we do it.
How to Extend the Event Log Functionality
Configuration happens in three stages: base configuration, adding custom types, and automating cleanup. Each stage includes specific work: enabling built-in events, writing custom type code, and setting up the cleanup agent. The result is a full audit trail of user actions and system operations.
Base Configuration
Manage built-in events: Settings → Product Settings → Module Settings → Main Module → Event Log tab. Key parameters:
- Write events — enable (may be off by default).
- Record storage time — recommend 90 days for production, 30 for development.
- Event types — check categories critical for your business.
| Event Type | Code | What It Logs |
|---|---|---|
| Login | USER_LOGIN | Successful login |
| Login failure | USER_LOGIN_FAILED | Failed attempts |
| Logout | USER_LOGOUT | Session end |
| User change | USER_EDIT | Profile or rights editing |
| Security policy change | GROUP_POLICY_CHANGED | Group rights change |
| File operation | FILE_DELETE | Deletion via file manager |
This set is sufficient for basic security auditing. But for business logic, custom types are needed.
Adding Custom Events
Built-in events don't cover store or corporate portal specifics — like an order status change or new infoblock element publication. Use CEventLog::Add(). Documentation for CEventLog::Add at dev.1c-bitrix.ru.
CEventLog::Add([ 'SEVERITY' => 'INFO', 'AUDIT_TYPE_ID' => 'CUSTOM_ORDER_STATUS', 'MODULE_ID' => 'sale', 'ITEM_ID' => $orderId, 'DESCRIPTION' => "Status changed: $oldStatus → $newStatus", ]); Custom types with the CUSTOM_ prefix automatically appear in the log filter. To avoid duplicating system types, use unique identifiers.
Example of adding a custom event
In the order component code, add a CEventLog::Add call on each status change. This lets you track who and when changed the status, tied to that order.How to Set Up Auto-Cleanup?
Without rotation, the b_event_log table grows to hundreds of thousands of records, slowing queries. An agent runs daily to delete expired records:
CAgent::AddAgent( "CEventLog::CleanUpAgent();", "main", "N", 86400 ); Before cleanup, export an archive — for example via CEventLog::GetList() to CSV. This preserves history for analysis.
What Does Security Monitoring Give You?
Tracking suspicious activity through the log is the foundation of protection. Practical indicators:
| Indicator | Condition | Action |
|---|---|---|
| Brute force | >5 USER_LOGIN_FAILED from one IP in 10 min | Block IP |
| Privilege escalation | USER_EDIT with change to admin | Notify admin |
| Mass deletion | >10 FILE_DELETE in 5 min | Check integrity |
For automatic alerts, you need a script analyzer (cron) that parses recent records and sends notifications via CEvent::Send().
Our Work Process
- Audit the current event log configuration.
- Design the list of necessary events — built-in and custom.
- Implement custom types and configure agents.
- Test filtering and performance.
- Document and hand over access.
What's Included
- Full configuration of built-in event types.
- Writing custom types for your business logic.
- Auto-cleanup with configurable retention period.
- Test run and debugging.
- Documentation on added events and recommendations.
Timeline and Cost
Estimated timeline: 1 to 3 days depending on customization scope. The cost includes: configuring built-in events, writing custom type code, setting up auto-cleanup, testing and brief documentation. Contact us for an accurate estimate for your project. Get a free consultation to assess the work scope.
Common Mistakes and How to Avoid Them
- Enabling all events indiscriminately — log database growth.
- No auto-cleanup — performance degradation.
- Duplicating system types with custom ones.
- Missing index on the
DESCRIPTIONfield — slow search.
Our team (5+ years experience, 50+ Bitrix projects) guarantees proper configuration. Order event log setup and forget about incident search issues.