servicemeshinterface / smi-metrics

Expose SMI Metrics

Home Page:https://smi-spec.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Configurable window value on a per query basis

daxmc99 opened this issue · comments

A default value of 30 seconds for all queries may not be desired for every query. This should be made configurable with an optional additional parameter to every endpoint. For example,
/apis/metrics.smi-spec.io/v1alpha1/namespaces/{Namespace}/{Kind}/{ResourceName} should support an optional query parameter ?window=30s. This would allow the window to be set per request.
Additionally, the window size should also be globally configurable in the config map.

Are you looking for a different window size or a time series to be returned?

Different window size. A different time series might require a different query, correct?

Shouldn't (we need to figure it out). I just wanted to make sure we were on the same page =)

Do you happen to have any specific use cases around changing the window size?

A basic use case is to simply compare the number of successful responses over the past 30 seconds vs the past 5 minutes to see if there is a trend of increasing success rates.

Having a fixed window is a big blocker for adapting the SMI metrics API in Flagger. In Flagger's canary analysis spec, users can configure the window size to match their analysis interval.

Here is an example from a prod user:

  canaryAnalysis:
    interval: 10m
    threshold: 1
    iterations: 6
    metrics:
    - name: request-duration
      threshold: 800
      interval: 9m

The above analysis takes one hour while running the metric checks every ten minutes. On every run Flagger validates that the average latency for the last nine minutes was below 800 milliseconds.

Sounds reasonable to me! Anyone have good examples of k8s API patterns with query params?

@stefanprodan are folks really looking for average latency over nine minutes? That seems like a good way to shoot your foot off.

Should we close this? as we got #52 merged, which solves this!

Looks like #52 fixes this, closing