Same Metric for different tables

[hypePG]

Hey,

i totally love this project and it helped me alot. Right now I am working on the problem for which i could not find a good solution but I have the fear that I am a little slow on the uptake:

i have the following metric:

 requests_count:
    type: gauge
    labels: [service]

and the corresponding query:

  requests_count:
    databases: [db1]
    interval: 5m
    metrics: [requests_count]
    sql: |
      select count(*) as requests_count, 'readData' as service from readData

my problem is that i have got multiple tables for services, e.g. readData, readClients, etc. since i cant use parameters to iterate over my table names see #118 i tried to think of another solution... i thought about something like this:

  requests_count:
    databases: [db1]
    interval: 5m
    metrics: [requests_count]
    sql: |
      select count(*) as requests_count, ':name' as service from readData, readClients
    parameters:
       - name: readData
       - name: readClients

But this probably wont work, cause the selected count of both tables will be written in both metrics, am i right? another solution would be to have single statements for every table name and service which isn't to hard but will create alot of code duplication.

am i missing something? i would be more as happy for a suggestion! thank you, max

[anurag-appperfect]

Any solution for this issue, I am also facing similar kind of issue

[albertodonato]

Right now (because of the feature described in #118 is not available), you'd have to make multiple queries, for each table.

One workaround, similar to what you described is something like:

  requests_count_data:
    databases: [db1]
    interval: 5m
    metrics: [requests_count]
    sql: |
      select count(*) as requests_count, 'readData' as service from readData
  requests_count_clients:
    databases: [db1]
    interval: 5m
    metrics: [requests_count]
    sql: |
      select count(*) as requests_count, 'readClients' as service from readClients

[albertodonato]

Marking this as a duplicate of #118