Using Collector to Run SQL Query....

for DataSources all the Datapoints must eventually result in a number, so that is true. You can write scripts or do some basic processing in LM to convert information into a number. Like converting Severity so that OK=0, Warning=1, etc. Or make a lookup table in code to convert your exception messages to codes. If you make the DataSource into a multi-instance, you will be able to create instances with custom names, descriptions and instance properties to get some of that data over but can be limited depending on what you need to store (and a bit of a hack). Getting that information out of LM into alerts and dashboards this can be hard or not possible. Also instance creation only run at-most every 15 minutes so it adds a lot of delay.You can look at the various "Troubleshooter" DataSources for examples of this trick.

DataSources would normally be used for something that has a state that you can keep querying and determine if it cleared. For example asking for free space on a drive. You can ask for the space left over and over and determine each time if that alert is active. If are looking for something like Exception event logs, they typically just have a one-time event without a start or end time. So asking over and over can't determine if the cause of the exception even cleared or not. For something like that EventSources should be used in those cases. If you do have a case where your SQL table will have no entries if there is no current exceptions (like select top 1 returns 0 rows), then DataSources would work.

You might also want to look at other features in LM (paid or otherwise), like LMConfig and LMLogs to see if those would help.

This is great feedback....thank you both.  Let me take this back to the team and see if we can use any of these ideas.  

Mike: to your comments in your 2nd and 3rd paragraphs: we initially assumed these errors would be in a $log file somwhere, and we could just monitor that.  But as it turns out, this application only logs these exceptions in SQL (from what we have found so far).  These are 1 time events, and the log itself is fairly inactive/only throws events when there are exceptions (failed login, failed ETL job, etc.).  To that point, we had an automated process fail because SMTP was not working upstream.  So the ability to send data blob out through SMTP did not work.  And our secondary stages for this ETL process depend on an automated mailbox task, etc.  So we did not know there was an issue until $business told us...which is not good.  Ideally, when the app throws this exception in SQL logs we are alerted.  We will have to manually check why an exception was thrown and then check further...but it's better than nothing.  In meantime, I am working w/ devs to find out if there's another point in the process we can detect failures.  But it's very tricky to do dead man switches in email....

Airbrake + EventSource/LM Logs + Distributed Tracing

I have been wanting to do this too.   I have no problem with returning numbers but I would like to return some text for the alert message.    Otherwise I am stuck with a message that says “Something happened, run this query to figure out what it is.”