Serialization and De-Serialization of Metrics, Logs / Events and Traces for Spring Data

[FWinkler79]

Hi @jack-berg,

I am trying to realize a use case in which telemetry data (metrics, logs, potentially also trace spans) is temporarily persisted and buffered before it is exported. The underlying use case is that I want to use metrics and logs to measure some data (e.g. commercial metering data, audit log events, etc.) that must not be lost even if the application crashes. I therefore would like to persist metrics and logs (maybe at some point also trace spans) in a temporary persistent storage. On export, I want to retrieve them from storage, de-serialize them into the in-memory form used by the SDK and send them out via OTLP.
Right now I am using Spring Data for the persistence and a MongoDB to store the metrics objects.

I have a setup that uses a MetricReader to retrieve the metrics from in-memory and stores them into a MongoDB database using Spring Data. I then use a MetricExporter to fetch the data from MongoDB (again using Spring Data) and exporting it via OTLP to some remote endpoint. This makes sure that even if my app goes down, the metrics are not lost.

A similar scenario might be relevant for logs that should not get lost (e.g. audit logs).

Initially the setup did not work, due to some (few) classes in the OTel SDK not playing along nicely with serialization and (especially) de-serialization to/from Spring Data. So, I created a fork of the SDK, fixed the issues and got a version now that works quite well - not tested for all metrics types yet, but working nicely at least for counters.

What's currently missing in the SDK to make this work out of the box is to compile all classes with the -parameters compiler flag (see here and here) a default constructor here and there, and in some few cases turning a final variable into a non-final one. For my setup, I had to change 3 classes so far, and a few build.gradles (see here).

I might be able to provide a PR for that, but I wanted to first ask, if ...

1. that is the right approach to serialize/de-serialize and persist metrics. I could also try to create my own implementations of the SDK's API classes in package io.opentelemetry.sdk.metrics.data to have more control over the structure required by SpringData to properly serialize, de-serialize and persist them. But it seems a bit odd having to do all that and then having to map between the SDK's in-memory versions and the persistable ones.

2. the OpenTelemetry SDK generally aims to support persistence of metrics / logs / trace spans out of the box.

Note: I also found this Q&A discussion, but even though it seems related, my use case is different, as I am not only trying serialize / persist the data, but also to de-serialize it from persistent storage into an in-memory representation the SDK's MetricsExporters can work with.

Any advice is much appreciated.

Thanks!