LM Logs multiple capture group parsing
Ok, this is cool. I have some log data that has structured data in it (some text, then a python list of strings). I had started building out a parse statement for each member of the list, then thought I’d try just making multiple capture groups and naming multiple variables after the as fanboy. Turns out it completely works. It parses each capture group into the corresponding column with a single parse statement. I was halfway through writing out a feature request when I figured I’d give it a try only to discover that it completely works. Nice job LM Logs guys.
ConfigSource checks by Value regex quirks?
I made a ConfigSource which applies just to our LogicMonitor Account resource object, and it tracks changes to folders, in case anyone moves things they shouldnt. It runs once an hour. I’ve got it working (with some false error in it too to test the config check) but my Arbitrary Text checks by Value which use Regex just aren’t working, but they work on regex101 and I can see the capture groups work fine. But no matter what, I could never get an error to trigger when my output started with anything other than “OK” so I was forced to just switch to a groovy script check for the presence of “ERROR CHANGE:”. But again, I’m certain my regex is correct, and I verified it on Regex 101. So I’m just wondering if there are any known “quirks” about LogicMonitor’s regex or input stream from the config source that would be “Tricky” in any sense. For example, I already consider it weird that in AppliesTo checks with =~, which supposedly use Regex, are somehow case insensitive by default in LM, but arent in regex generally. Because I cannot for the life of me get the Value option with a capture group being not equal to OK to work in any sense. But my regex groups things fine in regex101. So I almost wonder if maybe ^ and $ dont apply, maybe the whole output is considered one line or something strange under the hood. I’m grasping at straws. ^([^:]+?):.*?$ ^([^:]+):.*$ All my output lines from my ConfigSource either start with OK: or they start with ERROR: …. and I’m throwing an error when the capture group has a value that is not equal to OK. So logically, if my regex value matches at all, it should throw an error now for sure, since I have lines with both in my output (I wont bore anyone with sample output). Anyway, I got my alerts working by using the groovy script check for a hard coded value, just wondering generally if there are any known quirks with Value checks. I know its possible somehow that I’ve just done something dumb too. But more broadly I’m wondering if there are any other known weird things? Thanks!
The Globfather - Making Expressions We Can’t Refuse
A very useful featureof LogicMonitor is the support for glob expressions in fields throughout yourportal. If you’ve spent a good amount of time customizing your alert rules or dashboard widgets, chances are you’re already familiar with the usefulness of character matching. If you aren’t accustomed to using glob or are curious as to what benefits it it can provide, please read on. What is glob? Simply put, glob is the name for a process of pattern matching. Its name is derived from the fact that it’s checking against a global list of object names. If you have a look at your device tree, you’ll see that much like any filesystem you’ve used in the past, every object in your portal belongs to a path. Glob expressions are just a way of matching to the paths and namesof those objects.Any field that supports glob expressions is denoted by an asterisk in the lower right of the field. These are commonly found in Alert Rules, Dashboard widgets, and Reports. We'll Do It Live When you’re first becoming accustomed to glob matching, there may be some doubt as to whether or not your expression is valid and/or working. Luckily, glob-supported fields will display the results of your query in real time, so you can quickly check the results of your input. In the following example, I’m adding a partial group name using a wildcard, then piping in other groups and seeing that the queries are valid since the results populate correctly. Example - Wildcard matching for Corp and Corporations groups Let’s say I want to monitor all the MongoDB datasources for all Corporation groups in my portal. Before creating my alert rule, I can go through and find each group manually, then add them individually on the rule. But this requires an extra step, and I need to be absolutely sure I find them all on my own. After that, I can just add the necessary groups individually on the rule, then add the MongoDB datasource. The problem with this approach is that while I’ve accounted for the corporation groups currently in my portal, I will not be able to monitor future corporation groups without editing the rule and updating it each time there is an addition or loss.This would best be set up by instead using *Corp* as the group name. This matches any parent group folder, and any name that uses “corp” or “corporation.” I will also not need to update this rule if groups matching this are added or removed in the future. Example - 1 Alert rule for 2 datasources while omitting a group Consider the following: I need an alert rule specifically for routing Windows CPU, memory, and network alerts of all hosts in a group. Let’s say that I’d also like to exclude a particular subgroup. Since I’m a lazy guy, to avoid creating three separate rules I can use the power of glob to pipe in these datasources together while excluding the group I don’t want to route in the same rule: In this rule, you can also see how only valid hosts, datasource instances, and datapoints matching this filter are returned as valid results: Example - RTT Custom Graph Widget for 2 separate groups and multiple devices The following example demonstrates using a pipe in the Group field to call 2 groups, so that we can monitor the RTT of all devices’ ping datasource and plot each host individually on a custom graph widget: Further reading:https://www.logicmonitor.com/support/terminology-syntax/syntax/glob-expressions/