Counter with LoggingMeterRegistry not showing expected count

I am trying to replace PrometheusMeterRegistry with micormeter's LoggingMeterRegistry in order to export metrics as log events in a specific format. When executing my unittests I have noticed that the Counter meters are not showing the correct counts after retrieving the measurments with Meter#measure(). Here you can find a minimal example reproducing the behaviour described. The test case work5 calls a methode 5 times, withing the method a counter is registered and incremented. The expected counter value is then 5, with the PrometheusMeterRegistry the actual value is also 5, with LoggingMeterRegistry the actual value is 0.

• Is something wrong with my test setup or usage of the LoggingMeterRegistry and thus the expectation is wrong?
• If not, then how to make LoggingMeterRegistry behave correctly?

As I need the counter to reflect the count the same way the prometheus meter registry does for the usecase shown in the sample project and also the fact that the registry pushes the measurments to its sink, I have decided to create a custom logging meter registry CustomLoggingMeterRegistry extending LoggingMeterRegistry where I can control what implementation of Counter is used by overriding the newCounter method.

@Override
protected Counter newCounter(Id id) {
  CountingMode countingMode = getCountingMode();
  switch (countingMode) {
    case CUMULATIVE:
      return new CumulativeCounter(id);
    case STEP:
      return new StepCounter(id, clock, config.step().toMillis());
    default:
      throw new UnsupportedOperationException(String
          .format("Unsupported counting mode '%s'",
              countingMode.name()));
  }

}

StepCounter is only one instance of the issue, it may technically be the case for anything that is a StepMeter and needs to be handled accordingly.

Sample project updated with an impelemntation draft.

EDIT (2023-08-18):

As some issues have arised with the implementation above, because Counters are used for statistics in other Meters, for example Timer, I have abandoned the CustomLoggingMeterRegistry in favour of a SimplePushMeterRegistry which is a PushMeterRegistry that delegates the creation of new Meter instances to the implementation SimpleMeterRegistry. Pursuing CustomLoggingMeterRegistry would have required providing an implementation for all newXxx(...) methods, which by looking at available implementations is not trivial as in the case of Counter.

Sample project updated with an impelemntation draft.

Please, consider read this related SO answer I wrote recently, it is related to InfluxDB and the associated registry but I think the reasoning behind the explanation provided is the same for LoggingMeterRegistry.

As indicated in the answer, I think the behavior you are describing could be explained because LoggingMeterRegistry uses as in the case of InfluxDB a step based approach for performing rate aggregation, in client side. Note that the Prometheus registry provides a full fledged implementation - not step based - and the aggregation is being performed on server side.