Telemetry influxdb reporter

There is one, but I am not sure if it fulfills your needs.

https://github.com/ludwikbukowski/telemetry_influxdb

Hi,

I work at InfluxData, the company behind InfluxDB.

We’re actively looking at how we can contribute to the BEAM ecosystem, so it’s great to see some people working with this stack use InfuxDB.

I generally advise avoiding pre-aggregated metrics, but obviously there’s a trade off and sometimes it’s the best route forward.

You can do this currently with Telegraf, which can proxy InfuxDB; this would allow you to do aggregation without code.

I’ll put an example together if you think it would be useful

I guess the solution for doing it within the telemetry ecosystem would be have the telemetry reporter do aggregation/sampling. Afaik it’s the place meant to handle conversion between reported metrics and what’s actually send out to elsewhere. This can be as easy as just forwarding data or be quite complex by doing pre-aggregation or sampling. In the end it depends on how many moving parts one likes to have inside and/or outside of telemetry.

Yes, a proper place would be a reporter if one wants to integrate with Telemetry.Metrics, which provides nice abstraction over how events should be aggregated.

The InfluxDB reporter mentioned above takes a different approach where all events are pushed directly to InfluxDB, something that @rawkode suggested. The benefit of doing that instead of pre-aggregating is that we don’t need to know in advance what aggregations we’re going to run in order to analyze the data. As always, there are tradeoffs: pushing every event might be very bandwidth consuming, but aggregating in-process may consume considerable amount of memory.

This is the difference between logs and metrics, more can be read in this article by Grafana

https://grafana.com/blog/2016/01/05/logs-and-metrics-and-graphs-oh-my/

As an author of mentioned library I confirm what the guys say;
InfluxDB reporter simply pushes the events and it’s up to InfluxDB’s user what kind of processing he’d like to apply on top of them. The idea of sampling was actually the next step for library’s improvement.
If you have any questions/suggestions for the implementation, I would be happy to help

Is InfluxData involved at all with https://opentelemetry.io/? The first draft of the metrics specification is being finished up now I believe.

If you are involved in OpenTelemetry or plan to support it then I think the best way for InfluxData to contribute to the BEAM ecosystem is through the Erlang/Elixir libraries, GitHub - open-telemetry/opentelemetry-erlang: OpenTelemetry Erlang SDK · GitHub

We have a SIG as part of the OpenTelemetry project GitHub - open-telemetry/community: OpenTelemetry community content · GitHub

I should also mention for those looking for how to instrument and report their metrics, the idea is you can use OpenTelemetry for recording metrics in your application and reporting them to the OpenCensus Collector, GitHub - open-telemetry/opentelemetry-collector: OpenTelemetry Collector · GitHub, and this will then report to Influx. It should also be able to receive from influx instrumented code so if you have projects in other languages already instrumented with some influx library they can report to the same agent/collector.

Thank you for describing this reporting scheme. It was the first time I’ve heard about OpenTelemetry. The whole infrastructure looks very interesting but maybe a bit far from my today’s needs. But I will keep an eye on it

OpenTelemetry is actually pretty big project that is backed by CNCF (known from also backing k8s, Prometheus, Fluentd, and a lot of other projects) so I would say it is worth trying (soon, as this is still in the progress).