Brandon

Members
  • Content Count

    79
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by Brandon

  1. ANLX64 This monitors solr JVM stats via the SOLR API without the need to enable jmx. This datasource may not work on older solr versions as this particular API call was only recently introduced. Still, it should be very useful for monitoring the overall health of the JVM application.
  2. @George Bica Here's another for monitoring the status of the SOLR collections (as opposed to the performance stats).
  3. ZLPJP3 This datasource monitors the status of each solr collection without the need to enable JMX. It is done via batchscript and seems to be very efficient. The only alert set up is for cores that are recovering. Other alerts can be set up at your discretion. There are a few graphs included as well.
  4. @George Bica - I cooked this up and have been steadily improving it over time. I figured I might as well share it since it seems to be causing you some pain. This datasource polls SOLR via the API and port. On the device, you'll need to set up these two properties: solr.port (default is 8983) solr.append (default is solr) The scripts I put together are pretty efficient, so discovery and monitoring should only take a minute or two to get going. If it still doesn't work, you might be running into a firewall issue or something. I've got more SOLR datasources I'll be
  5. 3Z32Z4 This datasource monitors a large amount of SOLR performance data for each SOLR collection/core. It is done via batchscript and appears to return data extremely reliably and efficiently. There are no alert thresholds set up as performance expectations may vary depending on usage. I've also set up basic overview and per-instance graphs. There are 65 datapoints here though, so I'm sure more can be added.
  6. R79DJL I'm not sure if this datasource was removed intentionally, but there was a datasource named "Windows_Cluster_Failover" that monitored for cluster failover events. We've been using this datasource, but we noticed that it triggered a false alarm last night which prompted me to go back and rebuild it. This datasource will monitor a Windows cluster for a failover event. If a failover is detected, it will be logged in the LogicMonitor's installation directory (Default is "c:/Program Files (x86)/LogicMonitor/bin/"). The datasource exits if certain calls fail altogether (to prevent fa
  7. This datasource doesn't poll SOLR via the API. It uses JMX which has to be enabled on your SOLR cores (collections) in solrconfig.xml. You can read how to do that here: https://lucene.apache.org/solr/guide/6_6/using-jmx-with-solr.html JMX provides lots of data that might not be exposed via the standard api queries. However, SOLR is actually quite good about making sure all sorts of monitoring data is available without JMX and they don't recommend enabling it in production.
  8. I would really like to see a feature implemented that allows for easy and adjustable graph smoothing. This can be accomplished by adding a switch to the UI in the graph configuration screen. If the switch is turned to "enabled", a drop-down appears prompting for an integer between 1% and 5%. This number would represent the percentage of total datapoints that would be used to calculate the "smoothed" values. A second drop-down prompts for the position of the calculation: past, future, or both (default). For example: A graph containing 500 values - Rolling average is enabled and set to
  9. Well, I had a few use cases come up for this, so I decided to take another crack at it. I think this is going to work out better for us than my first version: hostname=hostProps.get("system.hostname") my_query="Select Name, DisplayName, PathName from Win32_Service" def session = WMI.open(hostname); import com.santaba.agent.groovyapi.win32.WMI def result = session.queryAll("CIMv2", my_query, 15); def exclude = ['ALG', 'AppVClient', 'COMSysApp','diagnosticshub.standardcollector.service', 'FontCache3.0.0.0', 'EFS', 'KeyIso', 'msiserver', 'MSDTC', 'Netlogon', 'NetTcpPortSharing', 'RpcLoca
  10. @Tom Lasswell I noticed it wasn't pulling anything for switch stacks so I modified it a bit to get around that. Of course, this will only show the data for the stack master, but it can definitely still be useful. I know there's a separate datasource that pulls the data for all the units in each stack, but oh well - better to have it twice than not at all! import com.santaba.agent.groovyapi.snmp.Snmp; // set hostname variable. def hostname = hostProps.get("system.hostname") // Wrap code in try/catch in case execution experiences an error. try { // OID which contains the seria
  11. @Tom Lasswell - This is magnificent! I don't know why I never pulled this before, but I'm glad I did. Maybe someone at LM could be convinced to pull this into the official repository? Or even bake it into the core product! Definitely useful for us.
  12. GX2WXT A single Lambda function might have several versions. The default Lambda datasource monitors and alerts on the aggregate performance of each Lambda function. Using the Alias functionality in AWS, this datasource returns CloudWatch metrics specifically for the versions to which you have assigned aliases, allowing you to customize alert thresholds or compare performance across different versions of the same function. This datasource does not automatically discover aliases and begin monitoring them (as this could very quickly translate into several Aliases being monitored and drive
  13. @Sarah Terry - Thanks for the reply! Filtering out the discovery of the events using ILP's would help us prevent alerting, but the event also wouldn't be discovered. So, unless I'm mistaken, if we wanted to have a history of events that have occurred on an instance or environment, LM wouldn't show them. This might be a "pick your poison" scenario where we would need to choose between collecting the data, or alerting on it - but not necessarily both.
  14. When cloning an existing datasource and changing the type from one type to another similar type, all of the datapoints immediately disappear. I am overhauling some of my script and webpage datasources where the output is json or key-value pair into batchscript. As soon as I change the collection type, the datapoints immediately disappear and it's like I'm starting from scratch. The script auto-discovery and collection panes also get wiped out. Unfortunately this has translated into me spending a lot of time recreating datapoints instead of modifying existing ones. I understand why those d
  15. Any chance you guys could implement these changes into the back end of the core product? I only ask because the new datasource doesn't expose the code that's running, so I can't tweak the output myself. I really only need to be alerted on scheduled events that haven't happened yet.
  16. @Andrey Kitsen - Thanks! That was fast!
  17. Haha, thanks @Andrey Kitsen I 'm just getting around to posting the stuff I've been meaning to make available to the community for a while.
  18. This datasource monitors the solr logs via an http call to the web front end and parses the json response to output in a LogicMonitor-friendly format. This appears to work on all of the versions of Solr I have tested on (6.0+). *Note - I have disabled the applies-to on this datasource because it can be quite noisy if your logging hasn't been tuned on the Solr nodes. I did include some useful filters to strip out some of the more common noise - but I still recommend applying this with caution. W9PN3Y
  19. 967XA7 This datasource queries the new Solr metrics API to gather JVM performance data without having to actually enable jmx on the solr node. This will only work on Solr nodes running version 6.6 or higher. Feedback always appreciated.
  20. I'd really appreciate it if the NTP datasource could be updated with better descriptions for datapoints. I'm trying to dissect it, but I don't really understand the raw output or how it's interpreted. Maybe I'm overthinking it.
  21. Thanks @mkerfoot and @Andrey Kitsen. I'll have more good stuff to share soon. I always appreciate feedback!
  22. Two things: 1. I'd greatly appreciate it if you could share that datasource. Is this the one in the official repository? 2. I largely agree with your point that it's not always obvious when a datasource change or update is going to cause data loss - a pain I've experienced a few too many times. Even when updating official datasources, it's a risk due to the custom applies-to functions we might be using. It would be great if there was at least some logic that allowed the import of a datasource, but allowing the administrator to choose to override the applies-to function or not.
  23. MZMPR6 Every 5 minutes, this datasource will query ElasticSearch for a list of the top 20 API callers as identified by the "userIdentity.sessionContext.sessionIssuer.userName" identity. This should return a list of users that are running under automation as opposed to user accounts. This will also return the number of calls that are being throttled by AWS as outlined here: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html Use this datasource to improve any code you have running in AWS that relies on API calls outside of cloudwatch. Suggestions o
  24. Agreed - but I would take it a step further and bake it into the SDT functionality. "Only monitor this datasource(s) from this time to this time." We have a number of dev environments that are shut down over the weekend and at night. No need to waste the resources trying to get monitoring data for something we know will be down half the time.