Is your feature request related to a problem? Please describe.
TBMQ exposes various Prometheus metrics, but the dropped messages count is not included. In our use case, dropped messages should never occur, and any drop is an indication of a misconfiguration or issue on our side. Without this metric exposed, we have no way to alert on it proactively.
Describe the solution you'd like
Expose the dropped messages count as a Prometheus metric (e.g. tbmq_dropped_messages_total). Ideally with labels for the drop reason if available, as long as it does not result in high cardinality.
Describe alternatives you've considered
Run a custom service that scrapes the dropped message count from the PostgreSQL database and exposes it as a Prometheus metric, but that adds unnecessary complexity and maintenance burden for something TBMQ already tracks internally.
Additional context
Reasons why exposing this metric makes sense:
- Consistency: other message flow metrics (received, delivered, etc.) are already exposed, so dropped messages is a natural complement.
- Alerting: enables users to set up alerts for non-zero drop rates, catching issues like subscribers disconnecting, QoS mismatches, or full queues before they become user-facing problems.
- Debugging: when investigating message loss, having a time-series of drops with timestamps makes root cause analysis significantly easier compared to checking a UI snapshot.
Is your feature request related to a problem? Please describe.
TBMQ exposes various Prometheus metrics, but the dropped messages count is not included. In our use case, dropped messages should never occur, and any drop is an indication of a misconfiguration or issue on our side. Without this metric exposed, we have no way to alert on it proactively.
Describe the solution you'd like
Expose the dropped messages count as a Prometheus metric (e.g.
tbmq_dropped_messages_total). Ideally with labels for the drop reason if available, as long as it does not result in high cardinality.Describe alternatives you've considered
Run a custom service that scrapes the dropped message count from the PostgreSQL database and exposes it as a Prometheus metric, but that adds unnecessary complexity and maintenance burden for something TBMQ already tracks internally.
Additional context
Reasons why exposing this metric makes sense: