Forum Discussion

Stuart_Weenig's avatar
6 months ago
Solved

First real attempt at using the new Meraki DataSources

As mentioned before, we probably won’t be using the new Meraki monitoring due to the significant increase in license cost. However, there are several benefits to that increase in cost:

  1. Meraki devices are devices instead of instances, so they’ll be able to do everything regular devices can do. That includes putting them into location specific groups.
  2. There are a few additional metrics provided that weren’t fetched before. Not sure if it wasn’t possible or if it just wasn’t added in.
  3. Local monitoring: since they’ll be devices, existing LogicModules can apply to them. That’s good because things like Ping can be used to distinguish between “device down”, “device not connected to Meraki controller”, and some of the false positives we would get from the Meraki troubleshooter DS.
  4. Not sure, but it looks like the monitoring is all (or mostly) done via the API. I’m still trying to work on why the netscan needs the community string if it’s coming via the API but it’s difficult to tell what the modules are going to do (and how). The module toolbox->exchange has the option of pulling in a package but doesn’t treat it as a package once it’s installed. I’ve not found a way of filtering by package so that I can look at what each of the modules do.

To give these benefits a try, I decided to give it a chance in my sandbox. Here are my findings:

  1. License count is per device instead of network. This changes the way the licensing works making certain networks financially equivalent to the old method from a monitoring perspective. For example, today, if we have a customer that has one network per retail store with one device in it, but has a thousand retail stores, the cost is pretty significant. We are paying for 1000 networks. That simply won’t work. However, if we have a customer with one network with 1000 devices in it, we are paying for one network. With the new model, 1000 networks with 1 device each costs the same as 1 network with 1000 devices. The cost for the retail customer doesn’t change, but all other networks increase in cost.
  2. You can filter by network ID within the NetScan by setting a credential property, not by setting anything in the filter section of the NetScan.
  3. You cannot exclude certain network IDs from the NetScan. You can only include, excluding everything else. For our use case, this is the exact opposite of what we need.
  4. If you want the discovered devices to be monitored by other than the collector running the netscan, you have to upload a CSV file to the collector. 
  5. Why isn’t there a UI for this? Why isn’t there a wizard that lets you manage your Meraki cloud the same way you manage your AWS cloud account? If this were built, you could 1) test credentials, 2) ensure the right networks/devices are included, 3) handle collector mapping in much the same way AWS collector mapping happens, 4) not have to make sure you spell the 18 property names correct, 5) not have to copy and paste 475 lines of code into a NetScan, 6) preview the group structure (or opt out)

I didn’t even get to the point where I tested the netscan. When juggling a couple windows, i accidentally closed the tab where i was building the netscan. I didn’t get a warning using the onbeforeunload event.

For these reasons, I’ll have to wait another 3-6 months to see if LM can come up with any improvements.

  • The idea of the wizard/configuration tool like with AWS is actually awesome. That would make it alot easier to facilitate items like this.

5 Replies

  • The idea of the wizard/configuration tool like with AWS is actually awesome. That would make it alot easier to facilitate items like this.

  • mray's avatar
    mray
    Icon for LM Conqueror rankLM Conqueror

    @Stuart Weenig I appreciate you writing up your thoughts and experience with the new module suite / integration. I also love the idea of building out a proper Meraki Cloud integration/wizard into the portal. I had this same idea when we first rolled out the now legacy module suite as well.

  • The first iteration of something like this will be for the Aruba Central platform integration. After this, perhaps we can apply the workflow to other technologies.

  • FYI: do not upgrade to v35.000 of the collector if you are still doing the traditional Meraki monitoring. It breaks the netscan. It would appear that the com.santaba.agent.util.GroovyScriptShell library is no longer present on the collector (from v34.500 onward it appears), which the traditional netscan requires. Working with support on how to fix this since we can’t move to the new monitoring due to the above mentioned issues.

  • Thanks to @shea.novy we have a solution. If you have this at the start of your netscan script:

    import com.santaba.agent.util.GroovyScriptShell
    import com.logicmonitor.mod.Snippets
    modLoader = GroovyScriptShell.getInstance().getScript("Snippets", Snippets.getLoader()).withBinding(getBinding())

    Replace it with this:

    import com.logicmonitor.common.sse.utils.GroovyScriptHelper as GSH
    import com.logicmonitor.mod.Snippets
    modLoader = GSH.getInstance()._getScript("Snippets", Snippets.getLoader()).withBinding(getBinding())

    This just highlights how Meraki monitoring needs to be done by the LM cloud collectors (same as AWS, GCP, Azure, Zoom, Webex, Slack, Salesforce, O365, and the huge number of “lite” offerings.