Skip to content

Remove gettime function from new API - #68

Merged
talex5 merged 1 commit into
mirage:masterfrom
talex5:auto-gettime
Aug 7, 2026
Merged

Remove gettime function from new API#68
talex5 merged 1 commit into
mirage:masterfrom
talex5:auto-gettime

Conversation

@talex5

@talex5 talex5 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

As we're deprecating the old API for time functions, this is the ideal time to get rid of the annoying gettime argument. It only exists because we don't want the core prometheus library to depend on Unix (which would prevent it from being used in unikernels, etc).

Instead, the new Prometheus.init function is used to set a global time function.

In the common case (metrics not being collected), the time is always measured as zero, but this doesn't matter.

In the second most common case (metrics being collected using prometheus-app.unix), prometheus-app.unix will initialise it.

In other cases (e.g. a unikernel that collects metrics), it must be initialised manually. The collect function has been renamed to remind users to fix this. However, there is no compile-time warning when using prometheus-app in a unikernel (but trying to read the metrics will raise an exception).

The example has been updated to show how to use Prometheus_lwt to measure the execution time of a Lwt thread.

(this is an alternative to #67)

Instead, the new `Prometheus.init` function is used to set a global time
function.

In the common case (metrics not being collected), the time is always
measured as zero, but this doesn't matter.

In the second most common case (metrics being collected using
prometheus-app.unix), prometheus-app.unix will initialise it.

In other cases (e.g. a unikernel that collects metrics), it must be
initialised manually. The `collect` function has been renamed to remind
users to fix this.

The example has been updated to show how to use `Prometheus_lwt` to
measure the execution time of a Lwt thread.
@avsm

avsm commented Aug 7, 2026

Copy link
Copy Markdown
Member

This looks fine to me; adding the init follows the same pattern as mirage-crypto-rng which needs the global init too. One thing I can't find is any MirageOS unikernel actually using Prometheus right now; are you aware of any?

@talex5

talex5 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

I'm not aware of any unikernels using it.

@talex5
talex5 merged commit 333f06a into mirage:master Aug 7, 2026
1 check passed
@talex5
talex5 deleted the auto-gettime branch August 7, 2026 13:38
@avsm

avsm commented Aug 7, 2026

Copy link
Copy Markdown
Member

Nothing for 'prometheus' in mirage-www or https://git.robur.coop/robur/unikernel-repo either, so this is all fine by me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants