Configuration and Discovery

Download this manual as a PDF file

The following sections describe how to configure and discover Cisco Meraki devices for monitoring by SL1 using the "Cisco: Meraki [API]"  PowerPack and the Meraki API.

Cisco Meraki Guided Discovery

If you are using the default SL1 user interface (AP2), youcan use the guided discovery framework process in SL1 to guide you through a variety of existing discovery types. This process, which is also called "guided discovery", lets you choose a discovery type based on the type of devices you want to monitor. The guided discovery workflow includes a button for Cisco Meraki.

You cannot perform a guided discovery in the classic SL1 user interface. Instead, you must create a virtual device representing the Meraki service and then align the discovery Dynamic Application to the virtual device.

To run a guided discovery:

  1. On the Devices page () or the Discovery Sessions page (Devices > Discovery Sessions), click the Add Devices button. The Select page appears.
  2. Select the Cisco Meraki button. Additional information about the requirements for device discovery appears in the General Information pane to the right.
  3. Click Select. The Credential Selection page appears.

During the guided discovery process, you cannot click Next until the required fields are filled on the page, nor can you skip to future steps. However, you can revisit previous steps that you have already completed.

  1. On the Credential Selection page of the guided discovery process, select the Cisco Meraki universal credential that you configured, and then click Next. The Root Device Details page appears.
  2. Complete the following fields:
  • Root Device Name. Type the name of the root device for the Cisco Meraki root device you want to monitor.
  • Select the organization to add discovered devices to. Select the name of the organization to which you want to add the discovered device.
  • Collector Group Name. Select an existing collector group to communicate with the discovered device. This field is required.
  1. Click Next. SL1 creates the Cisco Meraki root device with the appropriate device class assigned to it and aligns the relevant Dynamic Applications. The Final Summary page appears.
  2. Click Close.

The results of a guided discovery do not display on the Discovery Sessions page (Devices > Discovery Sessions).

Creating a Cisco Meraki Virtual Device

Because the Cisco Meraki service does not have a static IP address, you cannot discover a Meraki device using discovery unless you use guided discovery. Instead, you must create a virtual device that represents the Meraki service and then align the discovery Dynamic Application to the virtual device. A virtual device is a user-defined container that represents a device or service that cannot be discovered by SL1. You can use the virtual device to store information gathered by policies or Dynamic Applications.

If you want to discover more than one Meraki account, you must create a virtual device for each API key that you want to use.

You must use this method if you are using the classic SL1 user interface. You can also use this method if you are using the default SL1 user interface (AP2) but prefer to not use guided discovery.

To create a virtual device that represents your Meraki Cloud Controller:

  1. Go to the Device Manager page (Devices > Classic Devices, or Registry > Devices > Device Manager in the classic SL1 user interface).
  2. Click Actions and select Create Virtual Device from the menu. The Virtual Device modal page appears.
  3. Enter values in the following fields:
  • Device Name. Enter a name for the device.
  • Organization. Select the organization for this device. The organization you associate with the device limits the users that will be able to view and edit the device. Typically, only members of the organization will be able to view and edit the device.
  • Device Class. Select Cisco Systems | Meraki Cloud Controller.
  • Collector. Select the collector group that will monitor the device.
  1. Click Add to create the virtual device.
  2. Repeat these steps for each Meraki API key that you want to use.

Manually Aligning the Cisco: Meraki Organization Discovery Dynamic Application

After creating the Cisco Meraki virtual device, you must manually align the "Cisco: Meraki Organization Discovery [API]" Dynamic Application to the Cisco Meraki virtual device.

To manually align the Cisco Meraki Dynamic Application in the SL1 classic user interface:

  1. Go to the Device Manager page (Devices > Classic Devices, or Registry > Devices > Device Manager in the classic SL1 user interface).
  2. Click the wrench icon () for your Cisco Meraki virtual device.
  3. In the Device Administration panel, click the Collections tab. The Dynamic Application Collections page appears.
  4. Click the Actions button and select Add Dynamic Application from the menu.
  5. In the Dynamic Application Alignment window, from the Dynamic Applications field, select the "Cisco: Meraki Organization Discovery [API]" Dynamic Application.
  6. In the Credentials field, select the Cisco Meraki credential you created.
  7. Click Save to align the Dynamic Application with the Cisco Meraki virtual device.

After aligning the "Cisco: Meraki Organization Discovery [API]" Dynamic Application, your Cisco Meraki component devices will be discovered and classified.

The virtual device named "Cloud controller" must remain in SL1 in order to discover new organizations, as they are created in the Meraki account aligned to the credential on this device. This virtual device can be deleted, but no new Meraki organizations will be discovered.

SL1 will create a new root device for every Cisco: Meraki organization discovered. ScienceLogic recommends that you run a check for new root devices after manually aligning the Dynamic Application.

The Poll Frequency of the "Cisco: Meraki Organization Discovery [API]" Dynamic Application should be set to 5 minutes.

Assigning a Device Class to a Discovered Device

As of version 111 of the "Cisco: Meraki [API]" PowerPack, the device's model name is split into two parts when SL1 assigns a device class:

  • The first two characters of the model name are assigned to the Class Identifier 1 component identifier on the Class Identifier collection object. If the Cisco: Meraki device's model name starts with a "v", the next two characters after the "v" are assigned to this collection object instead.
  • The rest of the characters in the model name are assigned to the Class Identifier 2 component identifier on the Class Identifier 2 collection object.

SL1 will assign a device class based on the information in the Class Identifier 1 and 2 fields:

  • If the information in the Class Identifier 1 and 2 fields matches the Class Identifier 1 and 2 of a device class in the PowerPack exactly, that device class is assigned to the device.
  • If the information in the Class Identifier 1 field matches, but no match occurs on the Class Identifier 2 collection object, one of 15 fallback device classes is assigned. The fallback device class matching Class Identifier 1 with the lowest weight will be assigned.
  • If no match occurs in either of the Class Identifier fields, the "Cisco Systems | Meraki Device" default device class is assigned to the device.

This process is standard SL1 functionality that is documented in the Configuring Collection Objects as Component Identifiers section.

Viewing Cisco Meraki Component Devices

In addition to the Devices page, you can view your Cisco Meraki devices in the following places in the user interface:

  • The Device Investigator Map page (click Map in the Device Investigator page) displays a map of a particular device and all of the devices with which it has parent-child relationships. Double-clicking any of the listed devices reloads the page to make the selected device the primary device.

  • The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1. The Device Components page displays all root devices and component devices in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices. To view the component devices associated with a Cisco Meraki device, find the device and click its plus icon (+).

  • The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. The platform also updates each map with the latest status and event information. To view the map for a Cisco Meraki device, go to the Component Map page and select the map from the list in the left NavBar. To learn more about the Component Map page, see the section on Maps.

Configuring Dynamic Applications in the Cisco: Meraki [API] PowerPack

The "Cisco: Meraki [API]" PowerPack supports a number of unique configuration options that allow you to monitor Cisco Meraki systems effectively.

Certain Dynamic Applications in the "Cisco: Meraki [API]"  PowerPack are disabled by default. In order for these Dynamic Applications to begin collecting data, they must first be enabled. Others need to be manually aligned in order to collect data.

The table below displays the list of Dynamic Applications and whether they need to be manually enabled or aligned. For more information about the API endpoints used by each Dynamic Application and their API rates, see the Cisco: Meraki [API] API Endpoints Appendix.

The devices listed below are generally expected to have data for the following Dynamic Applications if the device it is aligned to has data to return, is enabled, and has the proper Dynamic Application and credential aligned. In general, only Dynamic Applications that use a bulk API call across an entire Meraki organization are enabled and aligned by default. Dynamic Applications not enabled and aligned by default are generally using API calls that are per network or per device and will utilize many more API calls to collect data than other collections. Meraki allows only 10 API calls per organization, per requesting IP address per second.

If you want to disable or unalign the "Cisco: Meraki Switch Ports Status Configuration [API]" Dynamic Application, the "Cisco: Meraki Switch Ports Status Performance [API]" Dynamic Application should be disabled as well. If the "Cisco: Meraki Switch Ports Status Configuration [API]" Dynamic Application is disabled, the "Cisco: Meraki Switch Ports Status Performance [API]" Dynamic Application will not have data to read from the cache and will not display any data.

Certain Dynamic Applications can be disabled to save API calls, as indicated in the table below. Others in the "Cisco: Meraki [API]" PowerPack can be enabled or disabled by toggling the specific API calls on either a universal or SOAP/XML credential, which will affect all devices using the credential.

Additionally, Dynamic Applications that are enabled or disabled in the snippet for the Request Manager are toggled globally across all credentials.

Dynamic Applications Enabled by Default? Aligned by Default? Aligning | Enabling / Unaligning | Disabling saves API calls? Devices Expected to Collect Data Required for Basic Device Discovery?
Cisco: Meraki API HTTP Stats [API] Yes Yes, Meraki organization No Meraki organization No
Cisco: Meraki Component Counts [API] Yes Yes, Meraki organization No Meraki organization No
Cisco: Meraki Network Discovery [API] Yes Yes, Meraki organization No Meraki organization Required to discover new networks and to populate the cache for the "Cisco: Meraki Network Configuration [API]" Dynamic Application
Cisco: Meraki Organization License Configuration [API] Yes Yes, Meraki organization No Meraki organization No
Cisco: Meraki Request Manager [API] Yes Yes, Meraki organization Yes, but Do Not Disable Meraki organization Required. Every API call is made by the Request Manager when it runs.
Cisco: Meraki Device Discovery [API] Yes Yes, Meraki network No Meraki network Required
Cisco: Meraki Network Component Counts [API] Yes Yes, Meraki network No Meraki network No
Cisco: Meraki Network Configuration [API] Yes Yes, Meraki network No Meraki network No
Cisco: Meraki Device Configuration [API] Yes Yes, all Meraki devices No Meraki devices No
Cisco: Meraki Uplink Usage Performance [API] No No Yes, but if aligned to a device, the API call will be made for every device in the organization. Devices where Meraki returns data for uplinks (usually MX and Z) No
Cisco: Meraki Uplink Performance [API] Yes Yes, all Meraki devices No Devices where Meraki returns data for uplinks (usually MX and Z) No
Cisco: Meraki Uplink Status [API] Yes Yes, all Meraki devices No Devices where Meraki returns data for uplinks (usually MX and Z) No
Cisco: Meraki VPN Status [API] Yes No Yes, but if aligned to a device, the API call will be made for every device in the organization. Devices where Meraki returns data for VPN connectivity (usually MX and Z) No
Cisco: Meraki Switch Ports Configuration [API] Yes Yes, all Meraki devices Yes, but if aligned to a device, the API call will be made for every device in the organization. Devices where Meraki returns data for switches No
Cisco: Meraki Switch Ports Status Configuration [API] No No Yes, but if aligned to a device, the API call will be made for every device in the organization. Devices where Meraki returns data for switches No
Cisco: Meraki Switch Port Status Performance [API] No No No Devices where the "Switch Ports Status Configuration [API]" Dynamic Application is aligned and collecting data No
Cisco: Meraki Wireless Stats [API] No No Yes. If aligned and enabled, the API call will be made for every network in the organization with an Access Point subcomponent. Access points No
Cisco: Meraki AP Utilization Performance [API] No No No Access points No

Bulk Unaligning a Dynamic Application from Devices

You can unalign a Dynamic Application from devices manually, or bulk unalign the Dynamic Application from multiple devices.

Upgrading from a prior version of the "Cisco: Meraki [API]" PowerPack to version 112 or later will align the "Cisco: Meraki Uplink Performance [API]" Dynamic Application to both Meraki networks and network devices. To avoid this, ScienceLogic recommends unaligning the "Cisco: Meraki Uplink Performance [API]" Dynamic Application from Meraki networks before upgrading to version 112 or later.

Upgrading to version 112 or later of the "Cisco: Meraki [API]" PowerPack will cause you to lose historical data for the "Cisco: Meraki Uplink Performance [API]" Dynamic Application. Additionally, Dynamic Applications aligned to "network" devices will stop collecting.

To bulk unalign a Dynamic Application from multiple devices:

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Type "Cisco: Meraki Uplink Performance [API]" in the Dynamic Application Name column.
  3. Click the wrench icon () and then click the Subscribers tab. The Application Subscribers page appears.
  4. Select the checkbox for each device you want to apply the action to. To select all checkboxes for all devices, select the checkbox at the top of the page.
  5. In the Select Action drop-down list, select Unalign Device and Remove Collection Data. This option unaligns the selected device from the Dynamic Application and deletes all historical data collected by the Dynamic Application from the device. The device is no longer considered a subscriber to the Dynamic Application. If you perform this option and later want to subscribe to this Dynamic Application again, you must re-align the device with the Dynamic Application.
  6. Click the Go button to apply the action to all selected devices.

Configuring Dynamic Applications to Hide Empty Rows

If you have a device that is no longer being monitored and a configuration Dynamic Application is returning empty rows in the Configs tab of that device, you can use the Hide row setting in the Dynamic Applications to hide those empty rows.

To do this:

  1. Go to the PowerPack Manager page (System > Manage > PowerPacks).
  2. Locate the "Cisco: Meraki [API]" PowerPack and click its wrench icon ().
  3. In the left pane, select Dynamic Applications.
  4. Locate a Dynamic Application with "Configuration" in its Type column and click its wrench icon ().
  5. In the Dynamic Applications Properties Editor, click the Null Row Option drop-down field and select Hide row.
  6. Click Save.
  7. Repeat steps 4-6 for each Dynamic Application in the PowerPack with "Configuration" in its Type column.

Disabling the Encoding Fix in the Cisco: Meraki Request Manager [API] Dynamic Application

In version 113.5 of the "Cisco: Meraki [API]" PowerPack, an encoding method was added within the "Request Manager" snippet of the "Cisco: Meraki Request Manager [API]" Dynamic Application to avoid the default SL1 behavior of displaying hexadecimal code for some characters outside the ASCII character set for Meraki network and device names. Additionally, this encoding change can be toggled off for the "Cisco: Meraki Organization Discovery [API]" Dynamic Application. Previously it was always on. The "encoding" function passed is used to translate non-ASCII characters to their approximate ASCII equivalents using the "fix_encoding" method in the silo-apps library. For any characters that cannot be converted directly by the method above, the snippet encoding function also allows you to specify additional replacements, as defined in the "prefix_encoding" dictionary.

The encoding fix can be disabled within the snippet of the Dynamic Application:

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Type "Cisco: Meraki Request Manager [API]" in the Dynamic Application Name column.
  3. Click the wrench icon () for the Dynamic Application and then click the Snippets tab. The Snippet Editor & Registry page appears.
  4. Click the wrench icon () next to Request Manager.
  5. Remove ,encoding=encoding from the end of the snippet.
  6. Click Save.

Updating the Polling Interval for the Cisco: Meraki Uplink Usage Performance [API] Dynamic Application

The Cisco: Meraki API does not currently expose uplink utilization directly. The "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application retrieves the limits set for the uplinks, reads the usage data from the "Cisco: Meraki Uplink Performance [API]" Dynamic Application, and then calculates the utilization based on the polling interval and the division of bits over that polling interval into average kbps (kilobits per second). Due to this complex relationship, updating the polling interval of either Dynamic Application can affect the accuracy of the data in those Dynamic Applications.

If you want to adjust the polling interval of the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application, you must:

  1. Update the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application:

    • Change the polling interval of the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application.

    • Update how many seconds the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application is dividing the usage value by in the presentation objects in the Dynamic Application. For example, currently for the "Uplink - Download Utilization Percent" presentation object , the divisor is '37500', or 125 * TIME_SPAN_IN_SEC . If you change the TIME_SPAN_IN_SEC value in the "Cisco: Meraki Request Manager [API]" Dynamic Application snippet, the divisor in the presentation object must also be changed.

  2. Update the "Cisco: Meraki Request Manager [API]" Dynamic Application:

    • Change the TIME_SPAN_IN_SEC variable in the "Cisco: Meraki Request Manager [API]" Dynamic Application snippet. This value should match the polling interval of the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application.

    • Add a new key: value item (for example, "pollFrequency": TIME_SPAN_IN_SEC) in this dictionary in the "Cisco: Meraki Request Manager [API]"Dynamic Application:

    {

    "state": True,

    "appGuid": "1D0E7B2EBCE646AD4E6A1CD23BAB48A7",

    "endpoint": "/api/v1/organizations/{organization_id}/appliance/uplinks/usage/byNetwork?timespan={time_span}".format(organization_id=get_organization_id(), time_span=TIME_SPAN_IN_SEC),

    "cacheKey": "ORGANIZATION_{root_did}_TO_APPLIANCE_UPLINK_USAGE_RESPONSE".format(root_did=self.did),

    "pollFrequency": TIME_SPAN_IN_SEC

    }

Creating Events from Cisco Meraki Emails

The "Cisco: Meraki [API]" PowerPack includes event policies that can generate events in SL1 based on emails that Cisco Meraki sends to SL1. On SL1 version 11.2 and greater, webhooks can be configured to handle these same events.

For SL1 to process events from inbound emails, you must configure your Meraki devices to send email to SL1 using certain formatting rules.

You must then enable SL1 to generate events from those inbound Meraki emails.

If configured properly, when the SL1 domain receives an email with body text that matches a Meraki network component device name and a subject that matches the regular expression (RegEx) pattern of one of the PowerPack's event policies, SL1 will generate an event aligned to that network component device.

Events from email are always aligned to network devices, even when the email includes references to one or more sub-component devices below the network device.

The email event policies included in the "Cisco: Meraki [API]" PowerPack each have an expiry delay setting that specifies the amount of time after which an active event is automatically cleared from SL1 if the event has not reoccurred. However, SL1 clearing an event for reaching its expiry delay setting does not mean that the initial condition that caused the event has been resolved.

Formatting Inbound Emails

Inbound emails must meet the following requirements to be processed as events by SL1:

  • The email must be sent to the following address:

    • notify@<SL1-domain-name>

    Where <SL1-domain-name> is one of the fully qualified domain names of the Database Server or All-In-One Appliance that is entered in the Authorized Email Domains field on the Email Settings page (System > Settings > Email).

  • The "from" address used by the external device must be "alerts-noreply@meraki.com" for non-maintenance events, "support-noreply@meraki.com" for maintenance events, or otherwise match an address defined in the Originator Address field in an email redirection policy on the Emailer Redirection page (Events > Inbound Email, or Registry > Events > Inbound Email in the classic SL1 user interface)).
  • The email subject line must begin with "Alert for" or "Scheduled maintenance for" and match the regular expression (RegEx) pattern of one of the event policies included in the "Cisco: Meraki [API]" PowerPack.

  • The email body must include the name of a network device monitored by the SL1 system.

The following RegEx patterns are used:

  • For scheduled maintenance emails: 

(Scheduled maintenance for)\s((network\s|\d\snetworks\sin\sorganization\s)"([a-zA-Z0-9_\-\.]+).*")

  • For all other emails: 

(Alert for)\s*([a-zA-Z0-9_\-\.]+)\s*

There must be a space between the RegEx pattern and the IP address, hostname, or device ID.

The event policies included in the "Cisco: Meraki [API]" PowerPack include RegEx patterns "out of the box". Users can add or modify event policy RegEx patterns to best suit their needs.

Emails that do not match the RegEx pattern of any Meraki event policy will generate a message in the system log. Emails that do not match the name of any component device in SL1 will not generate any events or messages.

You can specify how an Event from Email policy will match a RegEx to a device name on the Behavior Settings page (System > Settings > Behavior). For more information, see the Events from Email section.

Enabling Inbound Email Alerts

After you have ensured that inbound Meraki emails are formatted correctly, you must enable SL1 to generate events from the inbound Cisco Meraki emails.

To do so:

  1. Go to the Emailer Redirection page (Events > Inbound Email, or Registry > Events > Inbound Email in the classic SL1 user interface), and then click the Create button. The Add Policy modal page appears.
  2. Complete the following fields:
  • Originator Address. Type "alerts-noreply@meraki.com".
  • Alignment Type. Select If device not found, discard unmatched email.
  • Regex Pattern. Type "Alert for" or "Scheduled maintenance for network".
  • Regex Pattern Type. Select Advanced.
  • Regex Type. Select Subject.
  1. Click Save.

For more information about generating events from inbound emails, see the Events from Email section.

Configuring Cisco Meraki Webhooks

You must meet the following requirements before configuring webhooks for Cisco Meraki:

  • You must be on SL1 version  11.2.0 or later. For details on upgrading SL1, see the appropriate SL1 Release Notes.
  • You must have unique hostnames for devices across the organization, as the webhook handler is built to match alerts to a device based on their hostname.
  • Your Message Collector must have a static public IP address.
  • You must have a certificate authority (CA)-signed certificate for the Message Collector.
  • You must have a custom webhook handler and libraries.

The custom webhook handler and libraries are not included in the PowerPack. For additional information, reach out to your Customer Success Manager.

The following steps are just one way to configure Meraki webhooks; they are not the only way to configure this integration. The "Cisco: Meraki [API]" PowerPack is not needed to configure webhooks. For more information, see the Using Webhooks to Generate Events section in the Events manual.

  1. Go to the Process Manager page (System > Settings > Admin Processes).

  2. Enable the "Data Collection: Webhook Collector" process.. For more information about this, see the Enabling the Webhook Collector Process section in the Events manual.

  3. Configure the Message Collector for webhooks. For more information about this, see the Configuring Message Collectors for Webhooks section in the Events manual.

  4. Upload the CA-signed certificate to the Message Collector to the path below and update the SSL configuration to use the new certificate:

    cd /etc/nginx

    sudo sed -i 's/silossl/cert_file_name/g' /etc/nginx/conf.d/em7_webhook_collector.conf

  5. Go to the Collector Groups page (System > Settings > Collector Groups).

  6. Align the Message Collector to the collector groups. For more information about this, see the Aligning a Collector Group and Devices for Webhooks section in the Events manual.

  7. Add a ScienceLogic library with webhook handlers. For more information about this, see the Adding a ScienceLogic Library with Webhook Handlers section in the Events manual.

    You must write your own library or contact your Customer Success Manager for details on how to get a library from ScienceLogic.

  8. Go to the Device Manager page Devices > Classic Devices, or Registry > Devices > Device Manager in the classic SL1 user interface.

  9. From the Actions menu, select Create Virtual Device. The Create Virtual Device modal appears.

  10. Supply a value in each of the following fields:

    • Device Name. Name of the virtual device. Can be any combination of alphanumeric characters, up to 32 characters in length. 

    • Organization. Organization to associate with the virtual device. Select from the drop-down list of all organizations in SL1.

    • Device Class. The device class to associate with the virtual device. Select from the drop-down list of device classes. Only device classes with a device category of "virtual" and a collection type of "virtual" appear in the list.

    • Collector. Specifies which instance of SL1 will perform auto-discovery and gather data from the device. Can also specify a "virtual" poller. Select from the drop-down list of all collectors in SL1.

  11. Click the Add button to save the new virtual device. Create a virtual device for each organization.

    If devices are in user disabled or maintenance mode, a webhook alert generated for those devices will get aligned to the webhook virtual device instead of the devices themselves. ScienceLogic recommends adding these webhook virtual devices in the suppression section for the webhook event policies to avoid false alerts during maintenance activities for these devices.

  12. Go to the Webhooks page (Registry > Monitors > Webhooks)

  13. Click the Create button. The Create New Webhook modal appears.

  14. On the Create New Webhook modal:

    • Select the virtual device that you want to align to the new webhook receiver by clicking its device icon ().

    • Select the webhook_handler_example Library by clicking its library icon ().

    • Complete the following fields:

      • Device. Displays the device that you selected to align to the webhook receiver. Click Change Selected Device to select a different device.

      • Webhook Name. Type a unique name for the webhook receiver.

      • Webhook URL Suffix. Type a unique URL suffix for the webhook receiver.

      • Available Webhook URL. Displays the auto-generated full URL of the webhook receiver. The webhook URL consists of the IP address and port number of the Message Collector that is associated with the selected device's collector group, the static URL fragment "/api/v1/webhook", and the webhook URL suffix, in the following format:

        https://<IP address>:<port number>/api/v1/webhook/<webhook URL suffix>

        For example: https://10.2.20.56:8888/api/v1/webhook/test_webhook_url

      • Library. Displays the ScienceLogic Library that you selected to align to the webhook receiver. Click Change Selected Library to select a different ScienceLogic Library.

      • Import Module. Type webhook_handler_example.meraki_example in this field. This is the Python handler module that you want to import from the selected ScienceLogic Library.

      • Import Handler. Type meraki_default_template in this field. This is the name of the Python handler function that you want to import from the selected ScienceLogic Library.

    • Copy the Available Webhook URL. You will need this to configure the webhooks on the Cisco Meraki portal. Replace the <IP address> with the Public IP address or the DNS name of the Message Collector.

  15. Click Save.

  16. Go to the Alerts page on the Meraki portal. (Organization > Network-wide > Configure > Alerts)

  17. Under Webhooks, paste the Available Webhook URL you copied in step 15.

  18. Under Alerts Settings, add the Webook Name as one of the default recipients. This step must be completed for each network under each organization.

  19. Make sure the webhook configuration is synced with the Message Collector by executing the commands below in the Message Collector. This might take a while depending on the health of the system and the infrastructure:

    silo_mysql -e ‘SELECT * from master.webhook_definition;’

    silo_mysql -e ‘SELECT * from master.webhook_ingest;’

    silo_mysql -e ‘SELECT did FROM collector_state.V_device where did=virtual_device_id’

  20. For examples of Meraki webhook alerts, see the Cisco Meraki documentation.

    There is nothing to facilitate webhooks included in the "Cisco: Meraki [API]" PowerPack.

Managing the Cisco: Meraki Update Switch Configuration [API] Run Book Action Policy

The "Cisco: Meraki Update Switch Configuration [API]" run book action policy is included in the PowerPack as an example of how to use SL1 run book actions to automate actions within Cisco Meraki. This run book action policy contains code to push configuration changes to Meraki switches; specifically, to update the Power over Ethernet (POE) status of a port on a switch. You can modify this automation to perform any Cisco Meraki API call as a result of an event occurring in SL1. You can run this automation manually for testing purposes, or it can be triggered automatically by an event that has the required information in the event message. The "Cisco: Meraki Switch Port POE has been disabled" alert and event policies are provided as examples of what events can be used to trigger this automation.

To use the "Cisco: Meraki Update Switch Configuration [API]" run book action policy, you need the following components:

  • Run book automation policies:

    • Cisco: Meraki Update Switch Port Config
    • Cisco: Meraki Update Switch Port Config [Manual Execution]

  • Automation action policy:

    • Cisco: Meraki Update Switch Configuration [API]

  • Example alert:

    • Cisco: Meraki Switch Port POE has been disabled

  • Example event policy:

    • Cisco: Meraki Switch Port POE has been disabled

In an unmodified state, you must provide the following information to the "Cisco: Meraki Update Switch Configuration [API]" action policy to push the configuration to the switch:

  • Serial ID of the switch. This comes from the alert.

  • Port ID. This comes from the alert.

  • Switch Port Attribute. This is manually added in the "Cisco: Meraki Update Switch Configuration [API]" run book action policy.

  • Switch Port Attribute Value. This is manually added in the "Cisco: Meraki Update Switch Configuration [API]" run book action policy.

The "Cisco: Meraki Update Switch Configuration [API]" run book action policy and its associated automation policies are all experimental and ScienceLogic recommends caution before enabling and using them. The related "Cisco: Meraki Switch Ports Configuration [API]" and "Cisco: Meraki Switch Ports Status Configuration [API]" Dynamic Applications require a large number of API calls, which might negatively impact performance.

Executing the Cisco: Meraki Update Switch Configuration [API] Run Book Action Policy Automatically

To execute the "Cisco: Meraki Update Switch Configuration [API]" run book action policy automatically, you can use the "Cisco: Meraki Update Switch Port Config" run book automation policy.

  1. Align the appropriate event policy to the "Cisco: Meraki Update Switch Port Config" automation policy. For more information, see the Creating an Automation Policy section in the Run Book Automation manual.

  2. To change a value, configure the snippet code for the "Meraki Update Switch Configuration [API]" run book action policy. For more information, see the Creating an Action Policy that Executes a Snippet section in the Run Book Automation manual.

    • In the Snippet Code field, go to the get_event_action_fields() function and replace the <switchPortAttribute> : <attributeValue> with the switch port attribute that needs to be configured and its appropriate value under the payload attribute.

    • To specify a serial and port combination, go to the get_event_action_fields() function and replace the serial and port_id values.

  3. Enable the "Cisco: Meraki Update Switch Configuration [API]" run book action policy. For more information, see the Creating an Action Policy section in the Run Book Automation manual.

  4. Enable the "Cisco: Meraki Update Switch Port Config" run book action policy. For more information, see the Creating an Automation Policy section in the Run Book Automation manual.

  5. Enable the event policy that you aligned in step 1. For more information, see the Defining an Event Policy section in the Events manual.

Enabling and Configuring the Alert

The "Cisco: Meraki Switch Port POE has been disabled" alert is an example alert that is triggered when the POE status on a switch is disabled. This alert and its associated event can be used to change the POE Status configuration from "False" to "True".

  1. Go to the Dynamic Applications Manager page (System > Manage > Dynamic Applications or System > Manage > Applications in the classic SL1 user interface).

  2. Type "Cisco: Meraki Switch Ports Configuration [API]" in the Dynamic Application Name column.

  3. Click the wrench icon () for the Dynamic Application and then click the Alerts tab. The Alert Objects page appears.

  4. Click the wrench icon () next to the Policy Name in the Alert Object Registry.

  5. In the Active State field, select Enabled.

  6. Click Save.

Manually Executing the Cisco: Meraki Update Switch Configuration [API] Run Book Action Policy

To manually execute the "Cisco: Meraki Update Switch Configuration [API]" run book action policy , you can use the "Cisco: Meraki Update Switch Port Config [Manual Execution] [API]" run book automation policy. When using the user initiated automation policy, the serial ID, port ID, switch port attribute, attribute value, and SL1 credential ID are all added manually in the run book action policy.

  1. Configure the snippet code for the "Meraki Update Switch Configuration [API]" run book action policy. For more information about this, see the Creating an Action Policy that Executes a Snippet section in the Run Book Automation manual.

    • In the Snippet Code field, go to the get_user_actions_fields() function.

    • Add the <switchPortAttribute> : <attributeValue> , the serialId, portId and credentialId.

    • Uncomment the switchPortAttribute and portId lines and change the values as necessary. The key/value pair for the switchPortAttribute line in the payload section should follow the format provided by the Cisco Meraki documentation.

  2. Enable the "Cisco: Meraki Update Switch Configuration [API]" run book action policy. For more information, see the Creating an Action Policy section in the Run Book Automation manual.

  3. Enable the "Cisco: Meraki Update Switch Port Config" run book action policy. For more information, see the Creating an Automation Policy section in the Run Book Automation manual.

Managing the Cisco: Meraki Reboot Device [API] Run Book Action Policy

The "Cisco: Meraki Reboot Device [API]" run book action policy allows you to reboot a Meraki device. This action policy is disabled by default.

The "Cisco: Meraki Reboot Device [API]" run book action policy allows SL1 to reboot devices. This action policy is experimental and should be turned on only by a user with extensive knowledge of the effects that these actions will have on your network and devices. ScienceLogic recommends caution when enabling this action policy in a production environment.

To execute this experimental action policy, you must first:

  • Enable the "Cisco: Meraki Reboot Device [API]" run book action policy

  • Enable the "Cisco: Meraki Reboot Device [Manual Execution]" or "Cisco: Meraki Reboot Device" run book automation policy

  • Have Cisco Meraki credentials with the permissions to perform an HTTP POST request

Manually Executing the Cisco: Meraki Reboot Device Run Book Action Policy

The "Cisco: Meraki Reboot Device[API]" run book action has two policies:

  • Cisco: Meraki Reboot Automation [Manual Execution]

  • Cisco: Meraki Reboot Automation

To manually execute the "Cisco: Meraki Reboot Device [Manual Execution]" run book action policy:

  1. Enable the "Cisco: Meraki Reboot Automation [Manual Execution]" run book automation policy. For more information about this, see the Creating an Automation Policy section in the Run Book Automation manual.

  2. Modify the snippet code in the "Cisco: Meraki Reboot Device [API]" action policy to manually reboot devices. For more information about this, see the Creating an Action Policy section in the Run Book Automation manual.

    • In the Snippet Code field, go to the UPDATE VALUES HERE TO RUN MANUALLY section.

    • Enter the following details:

      • user_serial_id, for example: user_serial_id='QBSB-X4HM-KJVV

      • user_cred_id, for example: user_cred_id='104'

  3. Enable the "Cisco: Meraki Reboot Device [API]" run book action policy. For more information about this, see the Creating an Action Policy section in the Run Book Automation manual.

  4. Go to the Events page.

  5. Choose any event in the list to align to the run book action and click on the message under the Message column to open the event.

    • This event provides the serial ID of the device that needs to be rebooted.

    • The run book action will do a reboot (HTTP PUT) on the serial ID.

  6. Click the Tools drop-down menu and select the Cisco: Meraki Reboot Automation [Manual Execution] policy. The View Logs link appears.

  7. Click View Logs to verify that the action policy was executed correctly. In the window that appears, all action policies that have been executed are listed for review.

  8. Disable the "Cisco: Meraki Reboot Device [API]" run book action and the automation policy "Cisco: Meraki Reboot Device [Manual Execution]".

Executing the Cisco: Meraki Reboot Device [API] Run Book Action Policy Automatically

To execute the "Cisco: Meraki Reboot Device [API]" run book action policy automatically, you must use the " Cisco: Meraki Reboot Device " run book automation policy.

  1. In the "Cisco: Meraki Reboot Device" automation policy, select the event you would like to trigger this automation from. This event must contain the serial ID for the device being rebooted in the event message. For more information about this, see the Creating an Automation Policy section in the Run Book Automation manual.

    • Use the following format for the event message: serial_id:<serial number>. For example: Meraki: POE is disabled, serial_id:Q4AA-G999-2BBB.

  2. Enable the "Cisco: Meraki Reboot Device" run book automation policy. For more information about this, see the Creating an Automation Policy section in the Run Book Automation manual.

  3. Enable the "Cisco: Meraki Reboot Automation [API]" run book action policy. For more information about this, see the Creating an Action Policy section in the Run Book Automation manual.

Managing the Cisco: Meraki - Vanish Children Run Book Action Policy

The "Cisco: Meraki - Vanish Children" run book action policy and its associated run book automation policy ("Cisco: Meraki - Vanish Device") are included in the "Cisco: Meraki [API]" PowerPack to provide an option for overriding global vanish timers for devices that do not match the tags provided in the "Cisco: Meraki - API (Selective)" credential for use with selective discovery.

The "Cisco: Meraki - Vanish Children" run book action policy and "Cisco: Meraki - Vanish Device" run book automation policy are disabled by default and might be removed in a future release of the "Cisco: Meraki [API]" PowerPack.

If you want to override global vanish timers for devices, you must enable the "Cisco: Meraki - Vanish Children" run book action policy and "Cisco: Meraki - Vanish Device" run book automation policy. For more information about this, see the Creating an Automation Policy and Creating an Action Policy sections in the Run Book Automation manual.

Using Custom Device Classes with Cisco Meraki API

If you have Cisco Meraki devices whose device classes do not match those contained in the "Cisco: Meraki [API]" PowerPack, you can create and add custom device classes to the PowerPack to discover them in SL1.

Creating a Custom Component Device Class

The "Cisco: Meraki [API]" PowerPack includes device classes for many Cisco Meraki devices, but you can create custom device classes for devices that do not meet the criteria of the device classes in the PowerPack.

To create a custom component device class:

  1. Go to the Device Class Editor page (System > Customize > Device Classes).
  2. Click [Reset] to clear the fields in the Device Class Editor pane.
  3. Configure the device class as follows:
    • Device Type. Select Component.
    • Device Class. Enter the name of the device class.
    • Class Identifier 1. Enter the first two characters of the model name in lowercase letters. For example, if the model name is "zx-d2", enter "zx".
    • Class Identifier 2. Enter the rest of the characters of the model name in lowercase letters here. Do not begin this field with a "-" character. For example, if the model name is "zx-d2", enter "d2".
    • Device Category. Select the appropriate category from the drop-down list. This field specifies a logical categorization of devices by primary function, which allows SL1 to group related devices in reports and views.
    • Root Device. Select this checkbox if you will have additional tiers under this component device.
    • Weight. Select a value from the drop-down menu. A lower number should be assigned to a device class with a specific model (for example, c9200-MXPOX). A higher number should be assigned to fallback or catch-all device classes.
    • Description. Enter a description for the device class.
    • Device Icon. Select an icon that you created or a generic icon for the device class.

  4. Click Save to save your changes to the device class.

Adding Custom Device Classes to the PowerPack

ScienceLogic does not recommend creating and adding custom device classes without consulting your customer success manager to determine how these device classes might affect billing.

If you have created custom device classes for your Cisco Meraki devices, you can add them to the PowerPack.

To add device classes to the PowerPack:

  1. Go to the PowerPack Manager page (System > Manage > PowerPacks).
  2. Locate the "Cisco: Meraki [API]" PowerPack and click its wrench icon ().
  3. From the PowerPack Properties page, click Device Classes in the Navbar on the left side of the page.
  4. To add a device class, go to the Available Device Classes pane at the bottom of the page. Find the device class you want to include and click its lightning bolt icon (). The content will be moved to the top pane and included in the PowerPack.

If a device is no longer collecting, check to see if the device tags have been changed and no longer match the tags in the credential for selective discovery.

Troubleshooting

The following sections describe resolutions to some issues you might encounter when monitoring Cisco Meraki [API]: 

Receiving 429 Response Codes from the Cisco Meraki API

Cisco Meraki uses rate limiting to define how many API calls an API client can make in a set time frame. They limit API calls per organization, per source IP per organization, and per source IP across organizations, among others. You might receive 429 response codes from the Cisco Meraki API if the rate limit has been exceeded. This is normal behavior, and you do not necessarily need to be concerned if you receive the 429 response code. ScienceLogic recommends referencing the Cisco Meraki dashboard (on their website) to get insight into how many API calls SL1 and other tools are using, and which endpoints they are hitting.

Incorrect Calculations for Presentation Objects in the Cisco: Meraki Uplink Usage Performance [API] Dynamic Application

In version 114 of the "Cisco: Meraki [API]" PowerPack, there is a known issue where the calculations for the "Uplink - Download Utilization Percent" and "Uplink - Upload Utilization Percent" presentation objects in the "Cisco: Meraki Uplink Usage Performance [API]" Dynamic Application are incorrect and should be changed to 375 instead of 37500.

To change the calculations:

  1. Go to the Dynamic Applications Manager page (System > Manage > Applications).
  2. Type "Cisco: Meraki Uplink Usage Performance [API]" in the Dynamic Application Name column.
  3. Click the wrench icon () for the Dynamic Application and then click the Presentations tab. The Presentation Objects page appears.
  4. Locate the "Uplink - Download Utilization Percent" presentation object and click its wrench icon ().
  5. In the Formula Editor field, change 37500 to 375.
  6. Click Save.
  7. Repeat steps 4-6 for the "Uplink - Upload Utilization Percent" presentation object.

Cisco: Meraki Uplink Performance [API] Retrieves a NULL Value

Currently, the behavior when the "Cisco: Meraki Uplink Performance [API]" Dynamic Application retrieves a value of "NULL" for the uplink is:

  • The string 'NoName' + Serial Number is added as the index for the graphs.

  • The 'lossPercent' value could be 100%, which may trigger alerts at the network device level in the component tree.

This behavior currently exists in the PowerPack, since it could not be determined what a "NULL" value for the uplink means and whether it is useful.

You can choose to alter your alert policies to ignore these "NULL" value uplinks.

Meraki Organizations are Not Modeling

In versions 113.5 and 113.6 of the "Cisco: Meraki [API]" PowerPack, there is a known issue that prevents Meraki organizations from being modeled if another device in SL1 has the same name. If this situation occurs, SL1 modifies the existing device's name and does not create a new device. To work around this issue:

  1. Run the "Cisco: Meraki Organization Discovery [API]" Dynamic Application in debug mode.

  2. Identify the organization name where the failure is happening by either looking into the logs in the SL1 user interface or the /tmp/meraki_organization_creation.log file.

  3. Locate the device with the similar name, and change the name of the device if possible.

  4. Once you have changed the name of the device, SL1 will no longer try to update the existing device and will continue to create a new Meraki device.