Support relative time calculation expressions

[LiuTianyou]

Hello, community

Backgroud

When we use SQL to query metrics, we can use expressions like NOW() - INTERVAL 1 HOUR to calculate the time one hour ago. However, when querying metrics through other protocols, such as using the HTTP protocol, it is not possible to pass relative time by defining request parameters.

For example, in the OpenAI monitoring, the /dashboard/billing/usage endpoint requires two time parameters, startDate and endDate. Due to the inability to support dynamic time calculation expressions, we have to hardcode the logic in the code to add the corresponding parameters based on the URL.

Suggestion: Add global time calculation expressions.

What problem does it solve:

• Users can customize dynamic time parameters and participate in metric queries.

For example:

• @now gets the current time formatted as yyyy-MM-dd HH:mm:ss
• @date gets the current date formatted as yyyy-MM-dd
• @time gets the current time formatted as HH:mm:ss
• @timestamp gets the current 13-digit timestamp
• @now-1d gets the time at the same point yesterday
• @now-1m gets the time one minute ago
• @now+2w gets the time two weeks later
• ...

How to use:

• Use ^_^expression^_^, for example, ^_^@now-1d^_^

Where can expressions be used:

• Anywhere ^_^XXX^_^ placeholders are supported.

[tomsun28]

Good idea!👍 Now we deal the ^_^ in method org.apache.hertzbeat.collector.util.CollectUtil#replaceSmilingPlaceholder, suggest when deal the time calculation, do not pre put the dynamic time in configmap, because most monitoring probably won't use it， we can calculate time expression when this time expression is used.

[LiuTianyou]

As you said, the time expression should be calculated where it is used, so we first consider supporting time calculation in the request params of the HTTP protocol.Should we consider using other placeholders such as ${}? This would be less likely to be confused with the ones defined in congfigmap.

[zqr10159]

Good idea