Forum Discussion

Antony_Hawkins's avatar
6 years ago

ConfigSource that writes outputs to dashboard

A while back I published some very simple ConfigSources to monitor your collector .conf files:

a href="https://communities.logicmonitor.com/topic/1345-collector-configsources/" rel="">https://communities.logicmonitor.com/topic/1345-collector-configsources/

Here's an adaptation that writes the various collected configs to a dashboard, writing each of the config outputs to a text widget.

Notes:

THIS IS A PROOF OF CONCEPT. No warranty is given or implied (value of your investments may go down as well as up, check with your health professional before taking this medicine, etc). Please test before deploying!

As with all data within LogicMonitor (or any system), be aware of access rights of users - in this case to whatever Dashboard(s) the config data will be presented on. Be sure to configure your Roles and Users such that only users who have legitimate need to see this data can access whatever Dashboard(s) you send it to.

This uses the REST API v1 to verify the target dashboard exists or create it if it doesn't, and also to create / update the text widgets. It will therefore need an API token for an account with management permission for the relevant Dashboard(s), with ID and Key values set as device properties apiaccessid.key and apiaccesskey.key.

All of the API interaction is contained with a groovy checkpoint, rather than within the config collection script, so this could very simply be copied into other ConfigSources. The same logic could be used in other LogicModules, such as to write non-numeric outputs of SQL queries or any data collection methods to dashboards. While this provides no history retention as written, it will show current / most recent values.

Within the script you can define the desired Dashboard path, e.g. 'Collector Configs/Groovy Check' (default as presented here), Dashboard name (hostDisplayName is the default), widget name format (hostDisplayName: wildvalue) and other initial parameters such as widget colour scheme, description, etc.

This is written for REST API v1. One day I may get around to updating it for v2, for greater efficiency, but today is not that day. Tomorrow is not looking likely either.

Dashboard text widgets do have a maximum character limit (65,535 characters). I don't think I've seen a collector config near to or in excess of this, so I have no idea whether a larger config from another device would be truncated or whether the widget creation would fail.

Other widgets on the dashboard are unaffected by this script creating and updating widgets; likewise later manual changes to widget size, colours, etc should be respected; updates should be to the text content of the widgets only, so the target dashboard could contain other data from the device.

For example, it might look a bit like this:

Known issues:

On the first config collection for a multi-instance ConfigSource like this, and where the target dashboard does not already exist, only one widget will be created in the dashboard. This is because all instances collect more or less simultaneously, and each determines the dashboard is not initially present. Each, therefore, attempts to create the dashboard and as soon as the first instance does so, the others will fail as they cannot create a dashboard that (now) already exists. This could be coded around with a simple delay / re-check on failure, but I haven't had time, and the second config collection will create all expected widgets without issue. Additionally, if you create the dashboard first, this issue will not occur.

4 Replies

Replies have been turned off for this discussion
  • Antony i am currently looking for a way to do exactly this with a configsource that returns the values of a SQL query with numeric and alphanumeric data. Can you provide details/code or what you can to assist?

  • Just wanted to point out a possible piece of the answer you are looking for. Anthony provided details on the ConfigSource part and I posted a link to a similar solution but specifically for SQL, with the thought you may be able to take the two pieces and join them in a way to solve your needs.