blackode

Custom Metrics in Phoenix App using Telemetry

Hi, Wish You All Happy New Year 2020 won = 2021

I wish to use :telemetry in one of my projects. I’m novice in this topic.
After reading docs and some articles, it’s tempting to use it.

The using of this lib giving me the feeling of a pro coder.

Requirement

I need to measure the profile_visits I have an endpoint something like GET /profiles/profile_id When ever the people visits that particular route I have to track down the count of that particular route visits.

Schema

table -> profile_visits 
columns -> id, profile_id, count

My Current Solution

I simply updating the count value by calling Repo.update and increasing the count value by +1 where profile_id == <<profile_id>>

Now, I’m trying to move to telemetry.
To achieve I need to write a lot of lines includes custom_event custom_listener comparing to above solution which I felt simple.

Eventually, The logic of insertion metric and exraction of metric is same.

After this I have couple of questions that is keeps me away from using telemetry in the project.

Is telemetry not for such simple measurements?
Is this recommended approach to use telemetry for this kinda requirements?
Do we have any advantages to use telemetry over my approach current solution?

Glad if some experts helps us so we can grab the more developers to use telemetry

3 comments

/phoenix #metrics #telemetry

0 1429 3

2021-01-02 12:52:18 UTC

First 3 of 3 Posts!

blackode

Any suggestions please?

Post #1

LostKobrakai

It depends. Is the counter really a “metric” or is that tracking part of the service you’re providing? If it’s the first one then telemetry is imo the way to go. If not than your solution seems like the appropriate one.

Telemetry is way more than just means of updating a number in some database. It’s a generalized and structured way of publishing events in your application code, so you can listen to those in places external to your core business logic for (pre)-processing, aggregation and eventual forwarding to things like persistent storages, dashboards and similar tools for inspecting the inner workings of your project.

The pubsub architecture allows for quite lean code needing to be added to your business logic for instrumentation, compared to doing everything mentioned above in place, which can sometimes even make the business logic non-obvious because of all the additional stuff going on. Also what you actually listen on is not scattered across your whole codebase.

The other benefit is that given telemetry becomes more and more the standard in elixir libraries you can use one tool to not only instrument your code, but also to listen to events published by the libraries you’re using.

Another benefit of also letting people create their own listeners: It’s quite flexible to allow for situations like pushing metrics to a not yet natively supported service/db, allow for different sets of metrics to be sent to different endpoints.

All that flexibility comes for the price of a bit more upfront cost in implementation. It’s not just a single line Repo.update.

Post #2