ContributionsMost RecentMost LikesSolutionsRe: Location / credentials / any custom property updater DataSource (framework) Hi swaf , if you go to exchange (<yourPortal>.logicmonitor.com/santaba/uiv4/modules/toolbox/exchange) you should be able to use the locator code 3C2PMM in the "Find by Locator" search, and install it from there. As per the original post, you'll need to come up with some code to put into the getNewPropertyValue() function to generate the value to be set, of course. I'd also recommend changing line 287 from: http_request.addHeader('X-Version', '2') to: http_request.addHeader('X-Version', '3') ...in order to call v3 of LM's API. Operation should be unaffected. Re: Active Discover Filters with non-existent properties OK, so this is a complete bodge / kludge, but what if you set the "exclude.volumes" (etc) property/properties at a high group level so it exists on all relevant resources by inheritance? (E.g. at "Devices by Type/Windows Servers" or equivalent) The value can either be blank (if that works - TEST FIRST!) or a value that is never going to match a real instance name and therefore never going to exclude anything. You're then free to add subgroup or resource-specific values to the same prop name, where appropriate, to target those specifics you don't want. 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. Re: 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. Re: LM Portal Integration Events - EventSource to alert on Alerting Integration failures Thomas’ LogSource caches the epoch time of each check, and calls the audit logs back to that cached time on the next call, ensuring full coverage without overlap. Re: 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. Re: 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. Re: 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... Re: LM Portal Integration Events - EventSource to alert on Alerting Integration failures Ah yes, sorry Stuart, I was a little previous in posting. Now cleared through security review, should be visible. Re: ConfigSource Checker PropertySource Happy to help!
Top ContributionsDevice and Alert counts per groupLM Portal Integration Events - EventSource to alert on Alerting Integration failuresPaloAlto API key generator / verifier DataSourceConfigSource Checker PropertySourceUniversal 'No Data' monitoringIBM DS4700 and DS3000 monitoringRe: Device and Alert counts per groupRe: Device and Alert counts per groupRunning vs Startup Comparison ConfigSource (PoC)Collector ConfigSource(s)