By now you may have noticed that I focus on parts of Foglight that you can easily customize in order to solve your specific use cases. We'll build on the previous post on User-Defined Collections (UDC's) in Foglight.

In the previous post, our UDC was a direct query against master..syslogins. The use case was to have a dashboard that showed the logins and the server roles assigned to them.

It's also possible when creating a UDC to query a view, execute a stored procedure, or use T-SQL code to return the result set. Some of our customers are using UDC's to query business data, and in those cases, they may not want to expose the underlying tables and columns to Foglight. A view built upon that is perfectly fine for using in a UDC:

The downside is that if you want the same UDC across multiple instances, you will need to make sure the view is created and appropriate privileges are granted to the UDC user in Foglight.

Regardless if the UDC is built with a direct query, T-SQL, querying a view, we still need to define the keys and datatypes that Foglight will use for the results. That leads to this tip when selecting the datatype - if you don't need to graph/plot values over time, you should uncheck the "frequently modified" box. You can also treat data coming into Foglight as string data. If the goal is to put it on a dashboard, using a string will clean up the display of those values.

You'll still want to create a UI Query to return the UDC data. Just get in the habit of doing that!

In the previous post, I set up my UDC with some of the columns having the "frequently changed" option selected and some not. In this example, all of them were set to "off" or unchecked. You can now see when building the table for the custom dashboard, that all of the columns are easily selected from the list, and aren't stored in Foglight as metrics.

Finally, when the dashboard table is rendered, it looks much cleaner than the example above. The "units" aren't shown in each column, for example. This is the impact of defining the Foglight datatype as a string (vs integer, double, etc.).

I've got one more topic around UDC's. Stay tuned for a look at how to use a stored procedure in the UDC definition, and the flexibility that can provide around security and updating the query.

Related Content