1

I am working on a metric collector which uses Micrometer and we've decided to use it as a serverless function due to the nature of the metrics it is collecting.

We are using Kotlin with Spring Cloud Functions and the AWS Adapter.

We have a very simple function using the the Bean method from the docs. In Micrometer, the metrics are usually sent on a schedule based on a configured step (1m, 30s etc).

However, because this is a serverless function we want to send them as the Lambda is invoked obviously - I've attempted to do this by listening on the ContextClosedEvent from Spring where I manually close the Micrometer registry which sends the metrics to our backend.

When doing this I expected that there would be a new/different context for each lambda invocation but it looks like after the initial cold-start, the warm-start invocations look like they share some context, or that context isn't being re-created/instantiated on the invocations?

Can you offer an insight into if this is the case and expected outcome and perhaps a potential more reliable way to close the micrometer registry as this current pattern can cause metrics to be dropped as the context doesn't always exist and therefore the Micrometer registry is closed.

Thanks!

Riain Condon
  • 21
  • 2

1 Answers1

1

MeterRegistry has a close method that you can implement. Also, depending on which registry you extend, you can find a stop method too (close should call stop).

Jonatan Ivanov
  • 4,895
  • 2
  • 15
  • 30
  • Thanks for the answer! I used the `close` function in the `ContextClosedEvent` which flushes the metrics. The issue is that metrics are dropped from warm-start lambdas, it looks like there's a shared ApplicationContext for several lambda invocations and when that ApplicationContext finally closes and batches the metrics, any warm-start invocations have a chance of being dropped because 1) `MeterRegistry` is closed and 2) a new context doesn't exist with the new instantiation of the `MeterRegistry` – Riain Condon Dec 15 '21 at 09:13