Consider the need to implement "smart" counters

[echerniak]

Current exporter implementation manages counters as simple as possible. Every mq counter is a prometheus counter, which can only increase. There are pros and cons of such implementation: pros:

• exporter only updates counters. There is no additional work required from exporter.

cons:

• query format, which should be used, to display diff between counters (metric - metric offset 10s). Every grafana dashboard will depend on prometheus scrape interval.
• actually, the way we expose counters differs from the way mq exposes them.

The idea is to implement mq counters via prometheus gauges (that's how counters become smart). They will increase between scrapes, but after each scrape all "smart" counters will be reset to 0. This implementation also have pros and cons:

pros:

• grafana dashboard doesn't depend on prometheus scrape interval.
• exporter exposes metrics the way mq exposes them. From my point it is more obvious implementation.

cons:

• need to reset counters after each scrape.

Need to be discussed.

[sberdyshev]

An alternative - make counters provide "average per second" value. Time interval, that is publish with mq statistics, can be taken to calculate the average.

Both oprions have to be considered.

[sberdyshev]

@echerniak Describe here the decision we agreed on

[echerniak]

The final agreed decision about counters is following:

The idea is to implement mq counters via prometheus gauges (that's how counters become smart). They will increase between scrapes, but after each scrape all "smart" counters will be reset to 0. Main disadvantage of this approach is a significant increase in metrics values in case of long unavailability of prometheus. It was decided to solve this problem as follows: In case prometheus does not collect metrics longer than usual, the exporter will reset counters and will give the last value only for each counter on the next prometheus scrape.