grafana / grafana

The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.
https://grafana.com
GNU Affero General Public License v3.0
64.58k stars 12.09k forks source link

[Feature request] rename series (alias with input from a source/dictionary/list) #6966

Open esseti opened 7 years ago

esseti commented 7 years ago

For me would be great to have a way to rename the series with a meaningful name.

I've a case like the one in the picture. I've a lot of dataseries which have userID (such as 4121..) but I would like to display the userName.

I was thinking if it would be possible to pass an array [{'4121.':'bob'}...] and grafana replace the userID with the userName. (with the alias i can display just the userID, from that I would like to add the replacement)

esseti commented 7 years ago

For time being I create a greasemonkey script that does the replacment. It waits 5 second before renaming the fields (a and td)

// ==UserScript==
// @name        replace ids
// @namespace   me.stefanotranquillini
// @description replace id with username
// @include     https://YOURDOMAIN/*
// @version     1
// @grant       none

// ==/UserScript==
setTimeout(function () {
  l = [{"name": "DISPLAY_VALUE", "id": "TOBEREPLACED"},...];
  jQuery.each(l, function (index, item) {
    $('a:contains("' + item.id + '")').each(function (index) {
      $(this).text(item.name)
    });
    $('td:contains("' + item.id + '")').each(function (index) {
      $(this).text(item.name)
    });
  });
}, 5000);
TryTryAgain commented 4 years ago

@esseti and/or anyone else. Have you come up with anything more robust for a workaround since 2016? The greasemonkey solution is not the greatest, although it has been helpful. Curious if others can offer their workarounds, and how you've been dealing with it with time passed.

ugtar commented 1 year ago

My idea is to add a new transform that can replace names/series using a template variable as the lookup table. That opens a lot of options since a template variable can be populated with text: value mappings from several different data sources (query, hard-coded list, etc).

What isn't clear to me is whether transformations have access to the template variables or not (the ScopedVars? -- I'm not sure if this holds just the "currently selected" value of a template variable, or the whole array of options).

I also can't find any decent documentation related to writing transformations. Stepping through the code of an existing transformation has not been that fruitful since it quickly descends into minified js. Some help from a grafana dev with some experience in this area would be great

bohandley commented 1 year ago

Hi @utgar, the @grafana/observability-metrics squad currently owns transformations and we were given them about 3 months ago. None of us on the squad have written transformations but I can do my best to give you a little start.

Theoretically it should be possible to use template variables in transformations as long as they are created in core grafana. Historically, transformations were written in grafana/data and those written there do not have the capability of using variables, packages/grafana-data/src/transformations. More recently, there have been newer transformations written in core grafana, public/app/features/transformers.

I have found no documentation as well, but through asking previous developers, I have built an understanding which I am happy to share.

A transformation is composed of a transformer, an editor, and a registryItem.

A transformer is an observable that holds the logic that transforms data and through this observable the transformed data is sent to where it needs to go, i.e. panels or dashboard. The transformer contains an id, name and description. Name and Description are shown in the transformations UI. Take a look at public/app/features/transformers/joinByLabels/joinByLabels.ts for an example. https://github.com/grafana/grafana/blob/df34f804bafd9bf8be357015375d8319ed53cb87/public/app/features/transformers/joinByLabels/joinByLabels.ts#L19

The editor is the .tsx file that is used for transformation inputs, options, etc. See public/app/features/transformers/joinByLabels/JoinByLabelsTransformerEditor.tsx for a reference. https://github.com/grafana/grafana/blob/b875ca08c6e8538f1a8d70895c36eec68bd3f72c/public/app/features/transformers/joinByLabels/JoinByLabelsTransformerEditor.tsx#L12

The registryItem is exported from the transformer, see public/app/features/transformers/joinByLabels/JoinByLabelsTransformerEditor.tsx https://github.com/grafana/grafana/blob/b875ca08c6e8538f1a8d70895c36eec68bd3f72c/public/app/features/transformers/joinByLabels/JoinByLabelsTransformerEditor.tsx#L152 The registryItem is imported into public/app/features/transformers/standardTransformers.ts.
https://github.com/grafana/grafana/blob/b875ca08c6e8538f1a8d70895c36eec68bd3f72c/public/app/features/transformers/standardTransformers.ts#L31

I am open to having a meeting next week and talking more about this. Let me know if this helps!

ugtar commented 1 year ago

@bohandley thank you so much for the details. I will start poking around, but I will probably take you up on the offer to meet after I've gotten a bit better acquainted with what you've sent. Thanks!

oscarkilhed commented 1 year ago

https://github.com/grafana/grafana/pull/59726

This pull-request has some interesting discussion on how this could be solved.

ugtar commented 1 year ago

Yes, that PR is my attempt to make this work using the idea I outlined above (https://github.com/grafana/grafana/issues/6966#issuecomment-1322493131) using a template variable as a mapping. It was rejected due to the use of a template variable. It was recommended that rather than a template variable, a different referenced query should be used, though since there is not really any good way to exclude a query from the output data, that doesn't work very well at all (i.e., this is mixing data with metadata). I still think using the template variable makes the most sense for the reasons I outlined in the above comment. We are using the PR above extensively ourselves in our own grafana build.

github-actions[bot] commented 2 weeks ago

This issue has been automatically marked as stale because it has not had activity in the last year. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!