On Tue, Nov 19, 2019 at 03:31:28PM +0100, Christopher Faulet wrote: > > * also for `check_status`, there is the case of L7STS and its associated > > values that are present in another field. Most probably it could benefit > > from a better representation in a prometheus output (thanks to labels)? > > We can also export the metrics ST_F_CHECK_CODE. For the use of labels, I > have no idea. For now, the labels are static in the exporter. And I don't > know if it is pertinent to add dynamic info in labels. If so, what is your > idea ? Add a "code" label associated to the check_status metric ?
we need to be very careful here indeed. It's not very clear in my mind how much values we are talking about, but labels trigger the creation of a new metric of each key/value pair. So it can quickly explode your memory on scrapping side. > > * what about getting some backend-level aggregation of server metrics, such > > as the one that was previously mentioned, to avoid retrieving all the > > server metrics but still be able to get some insights? > > I'm thinking about an aggregation of some fields at backend level, which > > was not previously done with the CSV output. > > It is feasible. But only counters may be aggregated. It may be enabled using > a parameter in the query-string. However, it is probably pertinent only when > the server metrics are filtered out. Because otherwise, Prometheus can > handle the aggregation itself. My only fear for this point would be to make the code too complicated and harder to maintain. -- William
