netDalek
I’m thinking about rewriting metrics subsystem in my project. I wish to do it in some unified manner so it can be easily copied to other projects. I’m looking at telemetry and inspecting its reporters. We use influxdb, so I have to write a reporter because there isn’t any.
The reporter’s idea is probably the most complex part of telemetry. I compare Statsd and Prometheus reporters. Prometheus one does intermediate aggregation by itself, whereas statsd reporter doesn’t. With influxdb, we even don’t have different data types as we have with statsd. All aggregation in done afterwards. Intermediate aggregation looks very efficient because it is done inside Erlang VM.
So I want to create a summing counter that flushes data to influxdb on a regular basis. What is the right way to do it with telemetry? Should I write a reporter with an aggregation feature or write some external summing counter and flush its values using Telemetry.Poller and then write a telemetry reporter that writes data to influx without aggregation? In the second case, the new reporter should treat all types of telemetry metrics mostly the same. In the first case I need to specify some time interval when starting the reporter.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 18 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
There is EEF Observability WG that is working on monitoring facilities in Erlang (and naturally - Elixir). The current consensus is to use
telemetryas event dispatcher that is backend agnostic. On top of that you can use any metrics gatherer you like, for example mentioned abovetelemetry_influxdb. If you want to have more “holistic” solution for monitoring you applications, then you can check outopentelemetryapplication that will provide you metrics and traces, in future maybe even logs, gathering together with tooling to dispatch that data to various storage and processing engines.Sanjibukai
Does anyone heard of fluxter GitHub - lexmag/fluxter: High-performance and reliable InfluxDB writer for Elixir · GitHub ?
I found that blogpost Gathering metrics in Elixir applications – Forza Football Tech Blog that introduce it (article from 2016).
So I wanted to ask if there is now (in almost 2021) some kind of consensus on how to do some monitoring in Elixir?
juanpabloaj
have you ever tried telemetry_influxdb?
https://github.com/ludwikbukowski/telemetry_influxdb
hauleth
IIRC StatsD exporter for Telemetry supports DataDog-like tags, so with proper configuration the Telegraf will be just translator from one syntax to another.
Antikythera
Wow I wasn’t aware of the templates, thanks! I managed to make it behave now, but still it would be nice to have a native reporter. Then there’s no need to maintain all possible templates and you can use it the way it is without thinking about if it’s going to match the right templating rule in telegraf.
hauleth
You are aware that StatsD input plugin have a lot of configuration options, and allows you to:
Antikythera
Current solution I tried is to use statsd through telegraf . That works, kinda… You end up creating measurements for everything instead of combination of measurements with fields and tags, etc… This reduces the ability to query that data by a big margin.
. Otherwise we need to rethink our metrics storage.
If there is a plan to release the native reporter in the foreseeable future, that would be awesome
Are you guys planning on releasing a official telemetry reporter for InfluxDB?
netDalek
Yes, these tradeoffs are actually a question. Anyway, we shouldn’t send raw events to influxdb directly. Using telegraph we can send them through loopback interface using UDP. This way bandwidth isn’t very important. And then it is up to telegraph to aggregate and resend metrics to influxdb server.
Even with this case collecting metrics with something like
ets:update_counterinside reporter should be more efficient.So we have two variants with their pros and cons.
hauleth
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).
netDalek
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