MON$ Monitoring Tables: Transitioning to External Alerting in Firebird 3.0+

Monitoring Runtime State via MON$ Tables

Firebird 3.0 and later versions expose critical runtime metrics through the MON$ monitoring tables, such as MON$DATABASE and MON$TRANSACTIONS. These tables allow external agents to track transaction age and connection counts to prevent performance degradation caused by blocked garbage collection or sweep operations.

Privilege and Scope Constraints

Unlike earlier versions, monitoring table visibility in Firebird 3.0+ is attachment-scoped by default. This means a monitoring account may only see its own rows unless it possesses specific privileges or the RDB$ADMIN role. When designing a poll-based alerting system, the balance between granting sufficient visibility for cross-tenant monitoring and maintaining security boundaries is a primary concern.

Notification Noise and Thresholds

Because Firebird lacks a native push-notification subsystem, alerts must be implemented via external schedulers querying these tables. Frequent polling for thresholds—such as the gap between NextTransaction and OldestActive—can lead to notification noise if the alert triggers on every poll during a long-running transaction.

• How can a monitoring agent distinguish between a transient transaction spike and a persistent block of the sweep process using only MON$ table data?
• What is the recommended privilege configuration for a dedicated monitoring user to ensure full visibility across all attachments without granting full database administrative rights?