Stuart Weenig

LogicMonitor Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Community Reputation

3 Neutral

About Stuart Weenig

  • Rank
    Community All Star
  • Birthday 02/29/1980

Recent Profile Visitors

68 profile views
  1. Have you had a chat with support? Off the top of my head I would ask about the difference between the network paths between the collector and the switches. Have you tried doing a ping and SNMP GET from the command line (should be built into most Linux distros and there's a third party version you can use in Windows). Should at least verify if the problem is LM or if it's specific to your environment.
  2. I've put the wheels in motion to get this one fast tracked for review and publication. If you haven't heard, the exchange is getting a major overhaul and LogicModules published to the exchange automatically get marked as private. Once the new Exchange features get released (I think they're in beta right now, so should be soon) the author will be able to mark the module as public once it's uploaded. You'll also be able to bundle in a tokenized dashboard and multiple LogicModules all in a single package. Until that time, ping me with any submissions you need released and I'll try to bring it up with the guys who manage the exchange.
  3. That's right @Mike Moniz. What's likely going on here is that the set of user credentials used to run your collector doesn't have permission to do WMI queries on those servers and/or you don't have WMI credentials added as properties on the parent group containing those servers. Either way, what you know is this: LM thinks those servers are windows servers based on the open ports, however, when the collector tries to query via WMI, it's not successful.
  4. You'd have to write a bit of powershell code to fetch the current SDT status from the LM API. Generate an API token and set the ID and key as a properties on the group containing your servers. I recommend calling these properties after your datasource since that is how it will be used. Once you have that setup, you can pull those values into your posh script and call the Devices endpoint: I believe the "isEffective" attribute should do it. You can pull in the system.deviceId property to construct the API call url. I know this is a bit bare bones. Let me know if you want more detail on what the script strategy would be.
  5. Just checking: you've already familiarized yourself with the content here:
  6. It's not the extension that you're limited to, it's the encoding. For example, if it's a plain text file, LM can monitor output.out. I'm not familiar enough with RPT and SQL log files. Are they not plain text?
  7. FYI, i've started a github repo with my personal datasources, including the groovy version of this one: Feel free to grab anything from there.
  8. Hey @netcruiser, welcome to the communities. Level setting a bit: that datasource is configured to pull the value from and use it as the "name" of the interface (aka in LM as the WildAlias). It pulls the value from and uses it as the "description" of the interface. The object in LM is called an "instance". The answer to your question depends on how you want it listed: If you want the name of the instance swapped with the description of the instance, you would simply switch these two OIDs in the datasource configuration. The better way to do this is to clone the OOTB datasource and make your change on the clone. It's recommended to do this so that updates that are made from the LM monitoring engineering team don't clobber your changes if/when you pull down updates. This does however, require you to disable the OOTB DS by adding " && false()" to the AppliesTo on that DS. If you want the current name concatenated with the current description and that whole thing used as the name of the instance, you'd have to rewrite the datasource as a scripted datasource (because concatenating two OID values to use as the name isn't supported with a simple SNMP datasource like the current datasource). This has been done by several people, myself included and doesn't take too much effort to do right if you know what you're doing. Reply here if this is the route you want to take (it's the most difficult). It seems unlikely that this is what you want, but: if you simply want to change how the thing shows up in the alert message, this is an easier change. Once again, it is recommended to clone the OOTB DS, disable it, and on the new clone, make your changes. You'd scroll down to the StatusFlap datapoint and click the gear. Scroll down to the very bottom to the "Description" field. This is where you modify the message that goes into the alarm (and hence the email message). Currently it's set to: Network interface ##INSTANCE## ##DSIDESCRIPTION## on ##HOST## is up, but has flapped multiple times (up => down => up => down => up). Flapping is commonly caused by bad cables and/or duplex mismatch. This started at ##START##, -- or ##DURATION## ago. You'd want to reference this page for tokens that can be inserted into the message: You'll notice that ##DSIDESCRIPTION##, which is the DS Instance Description, is already in the alarm message, but you can rearrange it any way that you want.
  9. Hm, that's not expected. The AD script should exit with a non-zero if there are errors. Meaning to say, the developer should make the script exit with a non-zero if it encounters errors. Only if the script exists with a 0 will the results even be parsed. Looks like that's exactly the correction you made.
  10. Yeah, the groovy version had that problem too. I didn't notice the trailing space, but I did notice a record with a name of " " and one that had a leading space. If you look at the groovy code, you'll see a .trim() method that eliminates that.
  11. Just had a realization. If you aren't interested in all states, you could apply a discovery filter to only include those states where your company has offices.
  12. Also, I added some graphs. Also, I just committed a new version that groups by country.
  13. Alright, try this: Besides converting to groovy, I converted it to batchscript vs. script. This means that instead of making one call per state ever poll cycle, it makes one call and parses out all the data from that one call. Should help if finnhub ever decides to lower the api limit.
  14. Took me a minute to notice that this requires a Windows collector since it's powershell. With your permission, I may rewrite the scripts to groovy so they can run on either Windows or Linux.
  15. @Mike Moniz has it just right. Setting up a discovery filter where "FreeSpace" is "LessEqual" to "8589934592".