Is there something like a traffic metrics adapter?

[jotak]

Hello,

I'm trying to understand how a consumer could use SMI to get metrics names and labels available for a given pod (or list of pods or deployment etc.), in order to later query directly those metrics using PromQL.

If I understand correctly, this is not what the TrafficMetrics kind is about, correct? Because TrafficMetrics is actually filled with queried data, so I understand it performs the prom query. If I want to get more control on how to query prometheus, I would prefer to get just the metrics names/labels mapping and build my own promQL query out of them.

Is it out of scope for SMI?

EDIT: I see this is commented in the tradeoff section. So I change my question a little bit: is there any plan to add this kind of adapter in the future?

[grampelberg]

What extra control are you looking for?

As all the service meshes implement their own labels and series names, that's been out of scope so far. It would be possible to duplicate the labels and series in a more generic way, just needs some use cases :)

[jotak]

To give some context, I'm working on Kiali.

The first thing that comes to my mind is that we often query not just a single rate value aggregated over a time window, but we also display timeseries datapoints as line charts.

Also, we often aggregate (group by) various labels, including when they're available the "app" and "version" labels that come from the k8s labels on pods (istio metrics has that), it's quite useful for a/b testing / canary scenarios monitoring. Grouping by error code labels, too.

There's probably other things, a full review of our queries would be necessary.

PS to clarify: I'm not asking if these things could be done. Just trying to understand what is currently available and what is not, to get a good picture of SMI metrics.

[jshaughn]

+1, is there yet any example or reference impl for the metrics-related SMI API?

[grampelberg]

@jshaughn https://github.com/deislabs/smi-metrics

[jshaughn]

@grampelberg , thanks. From what I can tell this may do something with some linkerd generated metrics. It would be really nice if there were a fully mocked example impl that could just let people play with the API, or a public instance somewhere.

[grampelberg]

@jshaughn that's a cool idea, mind opening an issue on the repo? Having a mocked impl shouldn't be hard to throw together!

[jshaughn]

@grampelberg It would be good, here you go: https://github.com/deislabs/smi-spec/issues/52

[jotak]

For the record here's broadly the kind of thing I could imagine for metrics / graph adapters as a custom resource:

// Adapter title that could be used for display
title: "My graph adapter"
// List all  metrics to fetch, either for graph generation, or edge annotations, or both
metrics: [
  {
    // This name could be used for display
    name: "requests rate"
    // a prometheus query to run (will be transformed based on desired level of aggregation and the "function" to apply)
    query: "requests_counter{some_filter=some_value}"
    // Tells if this metric must be used for graph generation (nodes & edges)
    generates_graph: true
    // Tells if this metric must be used for edges annotations (edge labels)
    edge_labels: true
    // Optional: how to evaluate error rates
    errors: {
      // Evaluate error rates based on label...
      from_label: {
        // Name of the label in prometheus
        name: "error_code"
        // Regex that tells if it's an error
        regex: "[4|5].."
      }
    },
    // (+ eventually a couple of additional settings...)
  },
  // Other metrics (e.g. TCP, ...)
],
// Here are defined different levels of aggregations based on prometheus labels
aggregations: [
  {
    // Name can be used for display
    name: "Application",
    // Which prom label, or combination of labels, is used to identify sources of that type
    source_labels: ["source_app"],
    // Which prom label, or combination of labels, is used to identify destinations of that type
    destination_labels: ["destination_app"],
  },
  {
    name: "Workload",
    source_labels: ["source_workload"],
    destination_labels: ["destination_workload"],
  }
]