Recommended logging and auditing practices in InterSystems IRIS

Commonly recommended strategies in InterSystems IRIS are to use built-in auditing for key security and system events, add application-level audit events for business actions, and avoid trying to audit every low-level database operation because of volume and performance impact. InterSystems IRIS supports both system audit events and user-defined audit events, and specifically notes that database inserts, updates, and deletes are not automatically audited because that can generate excessive entries; instead, it is more efficient for the application to create a single meaningful audit entry for events such as patient-record access. This is especially relevant in enterprise and healthcare environments where you want traceable user activity without overwhelming the system. [1]

For tracking user activity and maintaining compliance, the built-in audit facility is the main tool. It can capture events occurring inside InterSystems IRIS and in applications, and documented examples of built-in events include startup, shutdown, logins, security-setting changes, audit-setting changes, and interoperability-related configuration or schema changes. A separate security article also states that auditing can be used to track login attempts, permission changes, and sensitive data access, and that audit events are stored in the dedicated IRISAUDIT database and can be viewed in the Management Portal under System Administration > Security > Auditing > View Audit Database. [1][2]

For troubleshooting issues and monitoring integrations, interoperability-related events can be audited, including changes to a production configuration or schema. In addition, one source recommends using production trace for Web Services, and says API activity can be monitored through the IRIS API Admin Portal, while Web Services and Database activity can be monitored through the Management Portal. [1][3]

For enterprise monitoring and external integrations, InterSystems IRIS supports structured logging as an alternative output for the same audit messages, writing them to a machine-readable file that can be ingested by a monitoring tool. It also supports transmitting audit database events as OTLP/HTTP signals when using a monitoring tool compatible with OpenTelemetry. This makes built-in auditing suitable for integration with external observability platforms. [1]

Built-in monitoring tools specifically mentioned are Diagnostic Report, Log Monitor, and System Monitor. One source also recommends SAM (System Alerting and Monitoring) as an additional tool for alerts and cluster-wide monitoring, and describes it as being based on Grafana, AlertManager, and Prometheus. [3]

If you want to manage audit events programmatically rather than only through the Management Portal, the documented class to use is Security.Events. [1]

Practical recommendations explicitly called out include enabling and reviewing the audit events you need, monitoring LoginFailure events to detect unauthorized access attempts, reviewing audit logs regularly, and setting automated alerts for suspicious activity. [2]

Note: This document describes how to manage audit events with the Management Portal. To manage audit events programmatically, use the Security.Events class. [1]

Sources: