Closed lassetyr closed 1 week ago
It's definitely possible to add more metadata to the UpdateResult and expose them in the Prometheus endpoint.
Another interesting avenue for root cause analysis is a Grafana/Loki adapter and custom logback appender to log all trip times, error details and data received.
I've played with additional labels (per feed, providers and route) and it scaled ok with Prometheus, but ideally that should be a config option, something like detailsReporting: true
for specific feeds/providers.
This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days
@lassetyr What would be a standards-compliant way of providing information about a source system or original data producer in Siri?
Prometheus-metrics for applied realtime-data is now available through the class
StreamingTripUpdateMetrics
.For metrics on rate of success/failure when matching realtime-data to planned data this is sufficient, however there is no way to identify if there e.g. is a pattern for the updates that fail.
Usecase: Currently we (Entur) receive SIRI ET-data from ~25 different realtime-systems through a realtime-proxy. An identifier for each provider is included in each "trip-update", and it would be very useful to be able to separate the metrics for each realtime-provider.
Suggestion: Would it be a viable solution to add support for passing custom tags to each UpdateResult? This would make it possible to drill down into more detailed metrics.