Consider supporting Counter type

[dominikschulz]

We should consider supporting Counter type metrics. In general I'd like to keep the SQL Exporter as simple as possible, but it may make sense to support Counters.

[saifulmuhajir]

I would love to have this feature.

Thank you for this awesome project.

[pasali]

+1 for this feature, we currently have scenario that needs counter type metrics.

[zwopir]

Hi @pasali,

could you elaborate on your scenario, so I can think about it? As Dominik said, we'd like to keep the exporter as simple as possible, but this shouldn't prevent us from implementing important features.

[pasali]

Hi, @zwopir

Let say i have table called 'failed_sms' and i want to fire alerts when count of failed SMSes in last 5 minutes greater than 1.

[zwopir]

I understand. But that's not a prometheus counter. Have a look at https://prometheus.io/docs/concepts/metric_types/#counter. In your use case there are two mismatches to consider the metric a prometheus counter:

• the metric isn't cumulativ
• the metric can go up and down

[pasali]

I can not use type gauge either. Because if query returns zero rows, metric value stays the same.I see you don't change the metric value when query returns zero rows because this can create ambiguity(my opinion). So i think if i can store my metrics as counter and look for the increase then i i can fire alerts. Or do you have any suggestions ?

[zwopir]

I may have misunderstood or made false assumptions about your use case. If you export a SELECT count(*) FROM ... WHERE <...timerange limit...> as a prometheus counter, my above statement is true. If we where to implement a counter that adds the result of a query to the counter, that counter would be a valid prometheus counter. But that would imply that we limit the timerange to the time since the last scrape and here the trouble begins....! So I would suggest to use delta() as promQL function or (if possible) instrument the code to count the number of failures

[pasali]

@zwopir thanks for the suggestion, but i think best way to handle this is usage type gauge and always return rows to make metric value 0.