github-actions[bot]
commented
7 months ago Thanks for your contribution!
This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.
If you would like this issue to remain open:
-
Verify that you can still reproduce the issue in the latest version of this project.
-
Comment that the issue is still reproducible and include updated details requested in the issue template.
Is your feature request related to a problem? Please describe. At least one code example, v2/metrics/QueryTimeseriesData.go (I think; it's the one rendered at https://docs.datadoghq.com/api/latest/metrics/#query-timeseries-data-across-multiple-products anyway) uses an absolute timestamp range in the query, thus requiring the copying-and-pasting reader to manually adjust the range unless s/he happens to have meaningful Datadog data in that time range.
Describe the solution you'd like Consider using a relative range like in the equivalent v1 example (https://docs.datadoghq.com/api/latest/metrics/#query-timeseries-points) so that the example code works out of the box (as long as you have at least one reporting host). There might be similar cases in other examples. It's helpful if examples can be compiled as-is.
Also, using a relative measure based on
time.Now().UnixMillis()is instantly understandable. An opaque large integer is not.Describe alternatives you've considered N/A
Additional context I tried the v1 endpoint first before realizing that it didn't support formulas, and I therefore switched to the v2 endpoint. Because the v1 example used a relative time range it didn't occur to me that I'd have to adjust that. I didn't, so the v2 query didn't return any results. I eventually filed Zendesk ticket 1592754 thinking this was a bug in the platform, which it of course wasn't.