Add support for query functions to custom_query_range #241

Activity

1. chauhankaranraj commented on Jun 30, 2022

   

   chauhankaranraj

   on Jun 30, 2022

   Collaborator

   More actions

   Hi @NoahZielke thanks for bringing this up! I believe you're right, I'm also unable to use query functions in get_metric_range_data like this:

   start_time = parse_datetime("3d")
   end_time = parse_datetime("now")
   chunk_size = parse_timedelta("now", "1d")
   
   query = "rate(scrape_duration_seconds[5m])"
   
   metric_data = pc.get_metric_range_data(
       query,
       start_time=start_time,
       end_time=end_time,
       chunk_size=chunk_size,
   )

   And yes, it's likely because of the way chunk size is implemented.

   Is there another way to use these functions

   I was able to work around this problem by using custom_query_range instead like this:

   start_time = parse_datetime("3d")
   end_time = parse_datetime("now")
   
   query = "rate(scrape_duration_seconds[5m])"
   
   metric_data = pc.custom_query_range(
       query,
       start_time=start_time,
       end_time=end_time,
       step="1d",
   )

   Does this work for your use case too?

   or does this support need to be added? I don't mind trying to add it if it needs it.

   Whether get_metric_range_data should be updated to support this functionality, or users should use custom_query_range for such cases would be up for discussion imo /cc @4n4nd
2. NoahZielke commented on Jul 2, 2022

   

   NoahZielke

   on Jul 2, 2022

   Author

   More actions

   Hi @NoahZielke thanks for bringing this up! I believe you're right, I'm also unable to use query functions in get_metric_range_data like this:

   start_time = parse_datetime("3d")
   end_time = parse_datetime("now")
   chunk_size = parse_timedelta("now", "1d")
   
   query = "rate(scrape_duration_seconds[5m])"
   
   metric_data = pc.get_metric_range_data(
       query,
       start_time=start_time,
       end_time=end_time,
       chunk_size=chunk_size,
   )

   And yes, it's likely because of the way chunk size is implemented.

   Is there another way to use these functions

   I was able to work around this problem by using custom_query_range instead like this:

   start_time = parse_datetime("3d")
   end_time = parse_datetime("now")
   
   query = "rate(scrape_duration_seconds[5m])"
   
   metric_data = pc.custom_query_range(
       query,
       start_time=start_time,
       end_time=end_time,
       step="1d",
   )

   Does this work for your use case too?

   or does this support need to be added? I don't mind trying to add it if it needs it.

   Whether get_metric_range_data should be updated to support this functionality, or users should use custom_query_range for such cases would be up for discussion imo /cc @4n4nd

   Yes, using custom_query_range was the workaround I used also. It isn't as confusing in hindsight, but it was initially, and it's interesting that I wasn't the only one with the issue. Thanks

   👍React with 👍1Reacted by Karanraj Chauhan
3. mahtin commented on Oct 30, 2022

   

   mahtin

   on Oct 30, 2022

   Contributor

   More actions

   Question: If I use metric_data = prom.get_metric_range_data(...) then I can use metric_object_list = MetricsList(metric_data) call. However, If I use metric_data = prom.custom_query_range(...) then the MetricsList() call fails with KeyError: '__name__'. I can fix this by running this loop before calling MetricsList().

       for r in metric_data:
           r['metric']["__name__"] = metric_name
   

   Where metric_name is part of my query string.

   Is this right? Or am I crossing the streams (so to speak).

   Thanks in advance
4. 4n4nd commented on Oct 31, 2022

   

   4n4nd

   on Oct 31, 2022

   Owner

   More actions

   Is this right? Or am I crossing the streams (so to speak).

   This is the "right" way to do it since Prometheus doesn't return a metric name when you use functions. I wasn't sure if the library should add the query string as the name by default. wdyt @chauhankaranraj?
5. bdulive commented on Dec 11, 2022

   

   bdulive

   on Dec 11, 2022

   More actions

   Is this right? Or am I crossing the streams (so to speak).

   This is the "right" way to do it since Prometheus doesn't return a metric name when you use functions. I wasn't sure if the library should add the query string as the name by default. wdyt @chauhankaranraj?

   I encountered same issue with query fuction when using custom_query_range(). Is it possible to add a parameter for custom_query_range() to specify the missing metric name ?
6. chauhankaranraj commented on Mar 31, 2023

   

   chauhankaranraj

   on Mar 31, 2023

   Collaborator

   More actions

   Is this right? Or am I crossing the streams (so to speak).

   This is the "right" way to do it since Prometheus doesn't return a metric name when you use functions. I wasn't sure if the library should add the query string as the name by default. wdyt @chauhankaranraj?

   Hm that's an interesting problem. Do we know if users tend to pass the return value of custom_query_range() to MetricsList()? If yes, and if that is one of the intended use cases of the MetricsList class, then I think we should make the query string as the name by default.