Antony_Hawkins
EmployeeJoined 10 years ago
User Profile
Employee
User Widgets
Contributions
Re: Silent Log Source Detection
Nice. My one comment would be, you should remove this line: // If script gets to this point, collector should consider this device alive keepAlive(hostProps) As the script is wholly interacting with the API, successful execution does not prove the resource is alive, and indeed, if the resource is down, this line will prevent LM from marking it as dead.12Views0likes0CommentsRe: What are some of the most common use cases that our customers might be using to improve their business?
It's all about time, and time is money. Customers I speak to want to have all the tedious, all the mundane, automated out, to free up the time that elsewise a human has to spend to attend to those issues. The alternative - not attending to those issues - brings risk, whether that's lost revenue, lost opportunity, or reputational harm, so without AI our customers put people on the job. AI provides (or will provide) automated resolutions (or at least, automated diagnosis), enabling greater uptime with fewer or no disruptions, meaning greater revenue.3Views0likes0CommentsRe: LM Portal Integration Events - EventSource to alert on Alerting Integration failures
You could create a datasource to query the logs and push them to your SIEM’s API log ingestion endpoint (assuming it has one). You would want to use the script cache to carry forward the timestamp of the last log sent during the previous poll. You can use this as an example. That’s for Audit logs or Collector logs, I presume? There is no API endpoint to extract logs from LM Logs. For the Audit Logs question, there is also a Community LogSource, “LM Audit Logs”, Locator: 43W643, that may be of interest.12Views0likes0CommentsRe: LM Portal Integration Events - EventSource to alert on Alerting Integration failures
Glad to see this formally built out by LogicMonitor at this point, I know quite a few customers have had to implement custom solutions historically. I think having this functionality for both an EventSource and in LM Logs would be great. Now - when are we finally going to get formal support for ingesting Collector logs into LM Logs? I’d love to leverage anomalies with Collector log data. As already mentioned above, this isn’t formally built out by LogicMonitor; it’s a “side project” / POC module authored by me as an individual who coincidentally happens to be on the LM payroll. It hasn’t gone through any “gold standard” reviewing (other than security review, of course), so, no guarantees for efficiency, no official support, etc. Coincidentally also, I’ve been thinking about collector logs to LM Logs; it’s simple enough technically (just a mix of my Collector ConfigSources and any other API logs ingest) but as an unofficial build they’d absolutely count towards your consumed, billable, ingest. It’s kind of on my side list of “things to put together”, I just haven’t found the time yet. I also don’t disagree with Stuart’s comments on default ingest of such things; feel free (if you haven’t already) to submit this as a feature request.10Views0likes0CommentsRe: LM Portal Integration Events - EventSource to alert on Alerting Integration failures
It did also occur overnight that pushing these integration events into LM Logs is an easy extension from this point, by a relatively simple combination of parts of this script and parts of other, existing, modules. Hold my beer...15Views4likes0CommentsLM Portal Integration Events - EventSource to alert on Alerting Integration failures
What: It’s an EventSource that calls recent Alert Integration events from the LM API (endpoint: /setting/integrations/auditlogs) , and alerts on any non-2xx responses. Why: Mostly because these failures aren’t glaringly obvious within the LM Envision UI; you have to actively go and look for them. This EventSource will let you alert on them within LM, both in the UI itself and also as an alert that can be escalated out. Obvious caveat: If you want to escalate alerts from this EventSource out of the platform, use an Alert Rule and an Escalation Chain to target the alerts and route them out via email/SMS/Voice call, not via an Alerting Integration. 😉 You will need: A LogicMonitor Portal Resource, that all the core LogicMonitor_Portal_* LogicModules also apply to. API credentials such as you’d already have set on this resource, as per our documentation: https://www.logicmonitor.com/support/logicmonitor-portal-monitoring The user that these credentials relate to must have read access to LM Audit Logs. The EventSource will automatically apply to your Portal Resource and “just start working”. If the API credentials don’t give sufficient rights to the Audit Logs, the EventSource will start alerting on that also (unfortunately, on each poll - you may want to watch it on implementation just to make sure it’s OK!) Script uses Collector Script Cache to remember the most recent event seen on each poll, then look back only that far, to ensure full coverage with no overlap. EventSource name: LogicMonitor_Portal_IntegrationEvents Version 1.4 published with lmLocator: J3WPAR204Views28likes13Comments