cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to a table tile to a dashboard without displaying the metric field?

ewoelkerling
Contributor

HI Dynatracers, 

I'm trying to find a way to add a table tile to a dashboard, but NOT display the metric field.  Sounds odd, but we're using a metric send to indicate if a plugin is locally disabled - we use a flag-file to allow a user to disable specific plugins under certain circumstances - when disabled, the plugin sends a '1' value in the metric and exits.  

The metric we're also sending has a dimension attached (reason) and I'd really like just a table with the hostname and the dimension so we can create a list of hosts with disabled plugins and the associated reason - but WITHOUT the metric column. 

So far I haven't been able to find a way.. 

Any thoughts/ideas that anyone could share please? 

6 REPLIES 6

Cameron-Leong
Dynatrace Enthusiast
Dynatrace Enthusiast

Could you provide a screenshot and elaborate on what you want the table to display?

ewoelkerling
Contributor

Hi Cameron,  

  Sure -Below is an example tile that I'd like to 'adjust'.  I have a metric coming in that indicates if a plugin (called an agent in this case) is disabled, and if that disabling is via a local mechanism or Dynatrace global configuration.   All I really care about is the fact that it's disabled - not the value of the metric (it's always 1, and isn't sent when the plugin is 'enabled').   I'd like to keep the first two columns, and remove the metric 'value' column from the display (ie. take the dxc.oaexecute.disabled.. out.   Hopefully that makes sense? 

Example TileExample Tile

I see, thank you for clarifying. Unfortunately, this is not possible currently. A potential workaround would be to make the tile smaller on the dashboard, which can mostly hide the rightmost column, although the rest of the text will shrink.

I would love to know more about this use case. May be you can write a Tip about your use case and how to implement it. Very interesting.

The true delight is in the finding out rather than in the knowing.

ewoelkerling
Contributor

Hi Daniel - sure.  Not sure if you meant here or in another feedback forum, but I'll go here for start 😎 

Basic use case: 

  • We required a plugin to be temporarily disabled via configuration both from the Dynatrace GUI and potentially from the host on which it runs.   These disable actions are generally going to be temporary so don't really warrant an uninstall of the plugin, and sometimes the actions being performed are done by people who don't have access/knowledge in the Dynatrace space. 
  • We also need to track 'disabled' plugins as, users being users, there will be cases where they forget to re-enable for whatever reason and we need to detect and remediate that (or at least understand why).  I would like this tracking to be across lots of devices, hence the need for a table (eg. I might have 10 devices currently disabled) 
  • Disabling in this context simply means that the plugin itself will do nothing more than send through a metric 'disabled' and then exit rather than executing it's normal function. 

  For example (and I'm just making this one up) - I might have a plugin doing remote monitoring of a device that is about to undergo upgrades/planned disruption.  We don't want Dynatrace alerting for this (planned action), but the users performing the upgrade don't have sufficient access in Dynatrace to enable/disable plugins (especially if they require a specific host configuration to do so).  

 

Implementation : 

  • At the Dynatrace level we've simply added a 'disable' option to the plugin itself
  • At the host level, we specified a specific file that, if it exists, causes the plugin to disable itself. 
  • The plugin is written so that it detects both conditions and if either is set it considers itself 'disabled'
  • Disabled instances send a 'disabled' metric, with an appropriate dimension detailing the 'reason' (ie. disabled via Dynatrace Configuration, or disabled via flag-file).  When the plugin is 'enabled' no metric is sent (normal state)
  • That metric is what is being shown above is the 'disabled' metric.  It's in a view that shows the 'disabled' metric value for only the last 30 minutes, forming a list of currently disabled devices.  FYI:  The view above is a little 'skewed' - it was accidentally set to 2hrs rather than 30 minutes so actually shows both disabled states - which is not normal. 
  • If desired, I can also use this metric to show how long the device has been disabled, and when the first 'disable' occurred (as well as the history of course), which I can then use for cross-correlation in other contexts etc. 

Ultimately, in this context I don't really care about the value of the metric, just that I'm receiving the metric - but I do need to understand/show the values of the dimensions so that i understand how to reverse each specific 'disable'.  

 

Hopefully that makes sense?   All suggestions welcome! 

 

great, thanks for sharing.

The true delight is in the finding out rather than in the knowing.

Featured Posts