kerryb
Sorry if this is a daft question, but I can’t seem to find any documentation that answers my question …
We’re in the process of migrating a Phoenix application from a single node to an OTP cluster. Almost everything is working nicely, apart from some custom metrics we’re using to track usage of various parts of the application.
We have a simple prom_ex plugin added to our prom_ex plug, which handles telemetry events that we send when certain actions happen,. Here’s a slightly simplified version:
defmodule MyApp.PromEx.StatsMetrics do
use PromEx.Plugin
@impl true
def event_metrics(_opts) do
Event.build(
:my_app_stats_event_metrics,
[
sum(
[:my_app, :stats, :page_visits],
tags: [:tool, :role],
description: "The count of a tool being visited by someone in a role"
)
]
)
end
end
… with events are emitted at appropriate points:
:telemetry.execute([:my_app, :stats], %{page_visits: 1}, %{
tool: :some_tool,
role: user.role.name
})
The problem is that we now have one instance of the plugin running on each node in the cluster, so stats are recorded separately for each node, and when Prometheus scrapes the numbers it sees the counts varying wildly as the load balancer routes it to a random node each time.
What we’d like to end up with is either a single instance of prom_ex (or just this plugin?) on the cluster (eg using highlander), or to somehow guarantee that the events are broadcast (using Phoenix pubsub, maybe?) so that all instances of prom_ex show the same values (but then what happens when a node is temporarily taken out of the cluster for an application upgrade?)
It feels like there’s probably a simple way of achieving this and I’m missing something obvious – any ideas?
Thanks!
Trending in Questions
Other Trending Topics
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
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex










Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
hauleth
That is bad idea. What if the node storing all metrics will go down? You will lose everything you have.
In Supavisor we had encountered similar problem and our solution was pretty different:
Code:
https://github.com/supabase/supavisor/blob/c38a7bd98528185ad4142666094873ba4f5e2d50/lib/supavisor/monitoring/prom_ex.ex#L126
This requires
Peepas a storage backend (which is much more performant from my experience).kerryb
Thanks – I’ll give this approach some thought.
kerryb
As our use case was fairly simple, I ended up removing PromEx altogether, storing the counts in the database, and generating the metrics page with a simple controller action and Ecto query.
adamcstephens
Can you explain why you did this rather than scraping each node’s individual metrics? What are you getting from merging them in-cluster rather than at the prometheus/dashboard level?
hauleth
We exposé metrics for individual clients as well, so we would need that gathering metrics from all nodes anyway. That way it is also easier to gather metrics as we support self-hosting, which makes the operations much easier. And with current implementation it is quite robust solution.