Context
We already have the GET /babamul/stats/nightly endpoint (src/api/routes/babamul/stats/nightly.rs), which returns an aggregated alert count per night. The data is read from MongoDB and cached (with a 1-hour TTL for the current night). This is sufficient for historical reporting, but it is not suitable for real-time monitoring: the granularity is limited to a single value per night, and frequent refreshes would result in repeated database queries.
Goal
Enable real-time visualization of newly ingested alerts for the current night.
Instead of repeatedly querying MongoDB to refresh the chart, this should leverage the existing OpenTelemetry/Prometheus metrics infrastructure. Metrics are better suited for real-time monitoring and time-series visualization, while /stats/nightly should remain dedicated to historical aggregated statistics.
An example of the expected result can be found on the ZTF grafana dashboard. The current babamul frontend can be found here and look like this:
Context
We already have the GET
/babamul/stats/nightlyendpoint (src/api/routes/babamul/stats/nightly.rs), which returns an aggregated alert count per night. The data is read from MongoDB and cached (with a 1-hour TTL for the current night). This is sufficient for historical reporting, but it is not suitable for real-time monitoring: the granularity is limited to a single value per night, and frequent refreshes would result in repeated database queries.Goal
Enable real-time visualization of newly ingested alerts for the current night.
Instead of repeatedly querying MongoDB to refresh the chart, this should leverage the existing OpenTelemetry/Prometheus metrics infrastructure. Metrics are better suited for real-time monitoring and time-series visualization, while
/stats/nightlyshould remain dedicated to historical aggregated statistics.An example of the expected result can be found on the ZTF grafana dashboard. The current babamul frontend can be found here and look like this:
