[Feature] Support updating the timerange from query/static/expression

[shlomiassaf]

The timerange is currently updatable only through user interaction either directly at the component or through brushing (via global param).

It is not possible to update it by other means, i.e providing from/to or and expression (ago(1h).

This limitation is big, since almost all metric components are encapsulated and only accept timerange from UI or existing variables.
If I bind the metric to a variable I can't control it from the workbook code, only the user can.

In my scenario, we provide insights for a logical process in our domain, for example user uploading a file which triggers a lot of internal domain logic.

I can identify the start time and end time of this process and I would like to update the various metrics to reflect the data for that exact time frame, but I cant.

I could write queries that use the start/end to extract the metrics manually and display charts, but this is way much work and not everything is available in the workspace, some data requires explicitly adding a diagnostic settings to expose it to the log analytics workspace. Even with that, i need to know where the data is, how to query and display it...

A lot of work for something that already exists through metrics, I just need to be able to update the time range

Clearly this is possible at the JS level, since the UI TimeRange component does that.
We just need some syntax that will allow updating specific properties in the time range from kusto response or through some special component in the UI

[gardnerjr]

@shlomiassaf Can you give a specific example of what you need? I think i get what you mean but can you give me a concrete example?

Would you want to be able to use something like criteria parameters to be able to if/then/else and have the result be a time range? and/or a time range can be the result of a query? use some kind of language like math.js?

the odd thing here is that time ranges are sometimes arbitrary (like "last 15 minutes") that are evaluated as lazily as possible, and other times ae concrete specific start and endpoints. Because of that the oddities of doing proper math correctly with them gets real complicated real fast.

internally tracking as Product Backlog Item 12708864: Workbooks: be able to have time range parameters be "output" by criteria/query instead of manually selected

[shlomiassaf]

Hi @gardnerjr

Thanks for helping out!

We're using application insight to measure the performance of a distributed process.

Through correlation we can easily track the start/end period and store it via parameters and then in each query use the params to limit the time range of the queries

We still need a TimeRange parameter to limit the search for a running process of course.

It will be better if we can update the TimeRange directly and use it in all queries instead of importing the range in kusto code, for every query we have.

While it's annoying it not the problem, the problem is mainly when we want to use metrics.
Azure comes with a powerful metric system which stores metric metadata for all kinds of services.
The data is not available via queries (unless we register a diagnostic source) so we need to use metric graphs directly.
Here we face an issue, all metrics accept a TimeRange which we can't control so we end up with metrics that does not reflect the exact timerange in which the process ran.

It's a big limitation for us.

[gardnerjr]

@shlomiassaf, Right but a specific example. how would you update the time range? shifting by a known amount and staying as a relative time? programmatically calculating start and end? you already have 2 numeric values and want to treat them as the start/end of a time range?

having a workbook of the form

1. [parameters step with a, b calculated from queries/something] ?
2. [something turns a+b into a time range parameter.  this step of the workbook would be a text step explaining what is missing] ?
3. [metrics step uses time range parameter] ?

having a concrete example to work from will guarantee that whatever solution we come up with will actually work for what you are doing instead of possibly working based on our interpretation of what we think you want.

[shlomiassaf]

Yep, got confused there, thanks for clarifying and for the extreme patience.

1. Workbook has global time range picker parameter named TimeRange
2. Somewhere in the workbook, a text parameter step named TimeRange runs a query which returns a single row
3. The returned value from (2) should correspond with the time range object model:

requests
  | where timestamp >= {TimeRange}
  | // more business specific logic here...
  | project
     value = "> ago(4)"
  | project pack_all()

OR

requests
  | where timestamp >= {TimeRange}
  | // more business specific logic here...
  | project
     query = 'between(datetime("2021-11-30T20:55:00.000Z")..datetime("2021-12-01T20:55:00.000Z"))',
     grain = 1m
  | project pack_all()

- We can also update other values, i.e. start / end / seconds / startISO etc...
- We can also return a row, or a complete new parameter type... it's just a idea I came up with

4.  **TimeRange** is now updated, cascading updates follow