Add support for relative time specifications in Prometheus queries

[leandregagnonlewis]

Add support for relative time specifications in Prometheus queries

Related issue

#121

Description

This PR adds support for relative time specifications in Prometheus queries by allowing relative times in the StartTime and EndTime fields to the QueryPrometheusParams struct. This enhancement allows users to specify time ranges using human-readable formats like "now" and "now-1h" instead of having to manually format RFC3339 timestamps.

Changes

• Renamed StartRFC3339 and EndRFC3339 fields of QueryPrometheusParams struct to StartTime and EndTime
• Implemented parseRelativeTime helper function to convert relative time expressions to absolute timestamps
• Updated queryPrometheus function to handle both RFC3339 and relative time formats
• Added comprehensive unit tests for the new functionality
• Updated integration tests with better timestamp comparison logic
• Updated documentation to reflect the new functionality

Implementation Details

The implementation supports two formats:

1. now - representing the current time
2. now-<duration> - representing a time in the past relative to now (e.g., "now-1h" for one hour ago)

The duration format follows Go's standard duration format (e.g., "1h", "30m", "1h30m", etc.).

Testing

• Added unit tests for the parseRelativeTime function
• Updated integration tests for both instant and range queries with relative timestamps
• Improved test assertions to handle timestamp comparison with appropriate tolerances

[CLAassistant]

All committers have signed the CLA.

[ioanarm]

Hello @leandregagnonlewis! Thanks so much for adding this, really useful :)
I started playing with it and I got an error, it seems that ParseDuration doesn't support days as relative time 😞

[ioanarm]

Nice, one small comment!

[sd2k]

Hey @leandregagnonlewis, thanks for the PR!

My hunch would be that we should switch to a single of each start and end parameter and accept either RFC3339 or relative times (now etc) in that single param, rather than having multiple. That would match the way Grafana's start/end times work in the UI and should be fairly easy to handle. Do you think that would work, or can you see any downsides to that approach?

[leandregagnonlewis]

Hey @leandregagnonlewis, thanks for the PR!

My hunch would be that we should switch to a single of each start and end parameter and accept either RFC3339 or relative times (now etc) in that single param, rather than having multiple. That would match the way Grafana's start/end times work in the UI and should be fairly easy to handle. Do you think that would work, or can you see any downsides to that approach?

I think you are right. I initially did not want to break the existing tool interface, but I guess it should not matter with an MCP server. I will work on this

[sd2k]

Thanks for adding the tests 👍 added a comment inline on the gtime package though.

[sd2k]

This is great! Thanks so much @leandregagnonlewis 💪

[sd2k]

We should be able to reuse this in other queries (e.g. Loki) but we can cross that bridge later.