Prometheus metrics do not show fuseki_requests_good or fuseki_requests_bad metrics for new datasets created after startup

[tomdw]

Version

4.9.0

What happened?

In the /metrics endpoint for prometheus there should be metrics concerning the requests going to fuseki.

More specifically fuseki_requests_good or fuseki_requests_bad metrics

They are shown for datasets or data endpoints that already exist at startup of Fuseki. However, when a new dataset or data endpoint is created while fuseki is running, then the metrics endpoint does not include these requests metrics.

Cause: the code to register datasets with the MetricsRegistry of micrometer is only executed at startup time of Fuseki. It should be executed again when a new dataset is added.

Relevant output and stacktrace

No response

Are you interested in making a pull request?

None

[rvesse]

@afs This might be another good motivator to translate the current metrics integration into an actual Fuseki Module.

We'd need to extend the FusekiModule interface (maybe in Jena 5.x) to have suitable methods that could be called when a new dataset/endpoint is added (or removed?) to a running server instance so that modules can take appropriate actions when things change. (serverReload() exists but not sure if that is quite the right extension point for this?)

Otherwise even if we fixed this specific issue you could still encounter the same issue with another module in the future. Therefore we might as well make the more general fix at the same time.

WDYT?

[afs]

@tomdw Which form/packging of Fuseki are you using?

Ensuring FusekiModule get triggered for dynamically added datasets will be necessary anyway but maybe the Prometheus code should cope with a changing DataAccessPointRegistry. That also means a fix now is possible whereas changing the FusekiModule interface has to be done very carefully and that means longer timescale.

Logically, the metrics should be generated every time a metrics response is generated.

An optimization is that the Prometheus code caches setup some where around FusekiRequestsMetrics and resets when there is a change in DataAccessPointRegistry.

DataAccessPointRegistry would have a UUID for each setup (the epoch) and it changes the UUID when a change is made. No harm in being safe - e.g. reset the UUID if a change may have been made.

The UUID approach is safer than relying on the names via DataAccessPointRegistry.accessPoints although that is an option.

[tomdw]

@afs we are running fuseki in docker in a kubernetes environment. Or do you mean something different with 'form/packaging'?

[afs]

@tomdw Are you running with the Fuseki UI available?

Fuseki has forms "webapp" (war file or the jar file in apache-jena-fuseki, or jena-fuseki-full.jar) or "main" (jar file jena-fuseki-server).

[namedgraph]

Hi @tomdw , I'm curious about Fuseki in Kubernetes :) Are you using Fuseki with High availability (RDF delta)? https://afs.github.io/rdf-delta/ha-system.html Martynas

…

On Fri, Oct 20, 2023 at 4:06 PM Tom De Wolf ***@***.***> wrote: @afs <https://github.com/afs> we are running fuseki in docker in a kubernetes environment. Or do you mean something different with 'form/packaging'? — Reply to this email directly, view it on GitHub <#2046 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGPM5UKNIV4NLHHQKGMIN3YAKAPHAVCNFSM6AAAAAA6HGUT52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZSHAYDKNZYGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tomdw]

@afs the Fuseki UI is also included yes.