mnagel

Members
  • Content Count

    342
  • Joined

  • Last visited

  • Days Won

    63

Community Reputation

97 Excellent

4 Followers

About mnagel

  • Rank
    Community All Star
  • Birthday July 17

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. In addition to enum management within modules, the right fix is to replace the simple token single-pass token substitution functionality with an actual templating engine. See https://docs.groovy-lang.org/docs/next/html/documentation/template-engines.html for a list -- LM needs to pick one and provide some sort of library function to enable management of template fragments.
  2. On a test run with some enum properties defined, no joy. Maybe it can be done via an undocumented method, like braces or something, or more likely there is just no support for constructing tokens this way. Help, I see a value of ##AUTO.ENUM.FAKEDS.FAKEDP.##VALUE####! Waaaah! I did create the enum mappings as a property source (could also just be manually defined at the root, but using a PS is a lot faster for many items). This will pollute the property list pretty badly when used extensively unless there is an option to keep them hidden in the UI. Enum support really needs to be added to LogicModules directly.
  3. When we have portal upgrades, our API scripts fail hard with a long stream of 500 errors. I am generally aware and let it go, but I would be happy to check a status endpoint prior toi API activity and bounce out if an upgrade is in progress.
  4. I just thought of a hack that might work. In the AD section, generate a bunch of auto properties that look like auto.enum.DSName.DPName.enumValue = enumName (substituting your DS name, DP name and enum value/name pairs, of course). Then in your alert message you may be able to reference ##AUTO.ENUM.DSNAME.DPNAME.##VALUE####. I have not tested whether nested token references work, but if they do, this could take away some of the pain. It might work as well with or without AD to put the definitions into a propertysource. Complete conjecture at this point, but I will probably whip something up to test as soon as I have some time....
  5. You can reference properties (including automatic properties) as tokens, but there is no facility to send arbitrary text (e.g., enum to text lookup). Unfortunately, since the alert system is simple token substitution and has no programmatic capability, you cannot do any sort of conditional display or substitution. I have railed on this one virtually since we started with the product, but no joy, not even a hint of a plan to fix alerting. Our only option has been to use custom integrations with actual templating (like ERB, Template::Toolkit, etc.), but we have found various bugs (like custom email integrations do not pass ACK or SDT notices), which make it more annoying than it needs to be.
  6. Right, you must use IP. I just thought it might be nice to specify a hostname and have the DS resolve that for submission to the API.
  7. I cannot attach it here, but please copy from the link below (will need to setup keybase, but if you haven't, you should :)). keybase://public/ciscoqid/LogicMonitor/RBLCheckMulti-.xml It is still entirely done, but it is working. I need to add some documentation and tune it a bit. For this, I set applies to on all collectors, then you use the "Add Monitored Instance" on whichever collectors you want. The instances should have the hostname and IP as name and wildvalue, respectively. I did not code support (yet) for using a FQDN as the wildvalue, just IP.
  8. That works, just means you know "yes I am included, or no I am not included" and then you send folks to the URL in the alert. Not the end of the world, but would be nice to know what is wrong directly. May be possible to use this API (sparingly, I assume they would be less happy if you hit it too often so for any given IP) to discover the RBLs as instances, but then you would have to define the IP to check as a device with the DS applied. I suppose the count of hits might have to be enough, then the instances are the target IPs, arbitrarily tied to a device, probably a collector (like Ping Multi). I whipped one up in Groovy (stealing a bit from another DS to get the "get a URL" code -- another great use case for code libraries...). I posted my current code as 37XXA4, but it often takes a long time to get those released.
  9. I am shocked to hear those are included with the custom email integration since none of those work for custom (the reply address is nailed up as "noreply+api.alerter@##COMPANY##.logicmonitor.com". unchangeable unfortunately). I just checked our logs and we are definitely not seeing that from a custom integration -- it sends only what you tell it and nothing else. Are you sure you are sending to the correct contact/integration pair? The menu setup on those is very fragile and strange. Are you sure no other chain target uses normal email? Another issue to be aware of with custom email is they don't send SDT or ACK status messages, which I think is a bug, but I didn't win that one (yet).
  10. I am looking at the DNSLookup- DS as a starting point. The code we used to run for Nagios was basically this Perl fragment, need to rework a bit my $res = Net::DNS::Resolver->new; my $lookupip = $host; $lookupip =~ s/([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})/$4.$3.$2.$1/; for my $bl (@bls) { $socket{$bl} = $res->bgsend("$lookupip.$bl", 'A'); } # watch for results to come in up to $TIMEOUT-2 seconds my $start_time = time; while (keys(%socket) and time - $start_time < ($TIMEOUT-2)) { for my $bl (keys(%socket)) { if ($res->bgisready($socket{$bl})) { my $packet = $res->bgread($socket{$bl}); delete $socket{$bl}; for my $rr ($packet->answer) { if ($rr->type eq "A" && $rr->address) { $listed{$bl}++; } } } } if (keys(%socket)) { sleep(1); } } if (keys(%listed) == 0) { $state = 'OK' } elsif (scalar(keys(%listed)) < $critcount) { $state = 'WARNING' } else { $state = 'CRITICAL' }
  11. Me too, perhaps in sandbox only unless it is not likely to cause any issues in production. Thanks, Mark
  12. Not crazy, but LM has a limited communication channel for problems. Would be best if event sources could do it, but really not well suited due to inability to acknowledge (no correlation across checks). If a DS was used, could program the list as instances and at least then know what triggered. Ideally it would be a preset list, but one that is adjustable. I am not aware of any way to do that (hybrid AD and manual instance definition), so it may require fully manual definition of the list, or AD with an external instance fetch (e.g., JSON source).
  13. I believe I have exhausted ServiceInsight's capabilities -- it just is not designed for this and cluster alerts should handle it. There is no way short of a custom DS for each cluster to convey the idea that per instance, the instance should be OK on at least one cluster member and generate an alert otherwise.
  14. Open source gets this done far better and more elegantly. NFsen, for example, allows you to define a tcpdump-style filter for flow selection. Very powerful and very useful and this should be added to LM ASAP (advanced feature option off by default if needed). Things have improved with NetFlow LM the past few years, but it is still very primitive and lacks even basic alerting tied to searches. The feature seems to be stuck where it is -- would be great if someone at LM could show us a roadmap... FWIW, I have been working on a way to extract NetFlow data via the API to workaround this. It is possible, but not trivial. This should be within the main UI. Also, add IPv6 support -- we get the weirdest results from our SonicWall that sends both IPv4 and IPv6 flows :).
  15. We have a common use case in monitoring where an instance may exist on one or another member of a cluster (e.g., wireless AP on a pair of controllers). The cluster alerts mechanism does not account for this scenario (either counts devices or all instances, not status per instance). The ServiceInsight feature may allow for this, if I can figure out how to make it work as needed, but it is a premium feature whose ecessive cost should not be incurred for dealing with this missing functionality. Please add an option to cluster alerts to group instances across member devices for threshold evaluation.