Stuart Weenig

Administrators
  • Posts

    854
  • Joined

  • Last visited

Reputation

118 Excellent

3 Followers

About Stuart Weenig

  • Rank
    Myth
    Myth
  • Birthday 02/29/1980

Recent Profile Visitors

1,272 profile views
  1. Do you already have a script started? You might check here and here for examples of how to fetch web pages in Groovy. From there, since you're fetching XML, it shouldn't be too hard to parse XML. I like this tutorial.
  2. The python script that builds the dynamic groups shouldn't have any impact unless you're running it on the collector. It makes a few GETs to find out what is present already and makes 1 call to create the parent group (if it doesn't already exist), 1 call per collector group to create the collector group groups, and 1 call per collector to create the collector group. So, if you have 30 collectors across 3 groups, it makes up to 34 API calls. The DS makes one API call for discovery and one for collection. All told, they should both be pretty lightweight.
  3. I like this. Sort of a "rebalance if over X" and "don't fail to me if it'll put me over Y". X defines when to shed load and Y determines when to refuse shedded load.
  4. Yes, the Host Status alert should cause the device to be marked as "Dead" which should suppress all other alerts on that device. However, there's often a race condition if other thresholds are set. The Host Status alert threshold is >300 on the idleInterval datapoint. It's definition is: So, the alert opens at 5 minutes, then the logic kicks in to mark the device as down at 6 minutes. If any alerts open before that, they are not closed, and there was nothing stopping them from opening. I know there have been a few requests allowing customers to modify the built-in server-side logic that marks a device as dead. I recommend you reach out to your CSM to add your support to that request.
  5. I've had this DS hanging out in my portal for a while and never committed it to the repo nor my github. It's now on my github. Simply add your portal as a device and add the token with the appropriate property names. It'll create instance groups under the applied device, one group per Collector. Devices are created as instances under the Collector group it is assigned to (preferred collector). I also built this python script to automatically create dynamic resource groups. It creates Collector groups, with groups for each Collector in the group, then dynamically adds the devices.
  6. While not strictly used to backup configurations, LM Config can do that, while at the same time evaluating the config for various scenarios. This is done through ConfigSources. Like other LogicModules, you can look through the Exchange to see if any other customers have written ConfigSources for the Aruba IAPs. If that proves unfruitful, you could think about writing a ConfigSource yourself. This can be done using Groovy, Powershell, or any other scripting language that might be best for the target. In most cases, the ConfigSource makes use of Expect to login to the device via SSH and echo the configuration to stdout. An alternative is to use HTTP to query either the API on the device or the API of the controller to fetch the config (any SDK the manufacturer may have provided may make this easier). Obviously these methods require SSH access to the device or an API endpoint from where the config can be fetched. If going the SSH route or fetching the config from the AP's own API, the Aruba IAP will need to be monitored to LogicMonitor. If the APs are ephimeral, you may consider keeping LM up to date using a scripted NetScan, fetching the AP list from a controller or something similar. That's a separate discussion, but something that can be addressed later. Here's an example Expect script that logs into a device and executes a couple of commands. If you can fetch the configs from the API of a controller, you'd need to write two scripts: 1) discovery and 2) collection. The discovery script would need to fetch the list of configs to be monitored. This would mostly be the list of APs given that there will be one config for each AP. Then your collect script would need to fetch each config previously discovered. The identifier each config is in a variable called "instanceProps.wildvalue". You'd write your script to fetch a single config. LM would run the script multiple times, changing out the value of "instanceProps.wildvalue" each time it is run.
  7. /device/devices/{deviceId}/devicedatasources/{hdsId}/instances/{instanceId} If it's a single instance datasource, you don't need to specify the instance id since /instances will return a list of instances which contains the field you're looking for: look for the "lastCollectedTime" value.
  8. Yeah, or do it on the graph with a virtual datapoint calculating the 95th percentile.
  9. Like i said, if it's working, you're done, especially if you're not interested in per-process stats.
  10. Ok, here's a quick tutorial on getting the python sdk up and running. I did this in docker because it's easier than installing a full vm and it's conceptually simpler (to me) than virtual python environments. Following this completely requires that you have docker installed on a machine that has access to the internet. 1. Start with the ubuntu:latest container. This should be equivalent to Ubuntu 20.04.3 LTS: docker run --rm -it ubuntu:latest 2. Install python 3 and pip (3) (and make sure everything is up to date): apt update apt upgrade -y apt install -y python3 python3-pip pip3 install --upgrade pip 3. Install the logicmonitor sdk: pip3 install logicmonitor-sdk 4. Write your script (this one fetches 50 alerts, see documentation for other methods you can run in the try block): from __future__ import print_function import time import logicmonitor_sdk from logicmonitor_sdk.rest import ApiException from pprint import pprint # Configure API key authorization: LMv1 configuration = logicmonitor_sdk.Configuration() configuration.company = 'YOUR PORTAL NAME' configuration.access_id = 'YOUR ACCESS ID' configuration.access_key = 'YOUR ACCESS KEY' # create an instance of the API class api_instance = logicmonitor_sdk.LMApi(logicmonitor_sdk.ApiClient(configuration)) try: # get alert list api_response = api_instance.get_alert_list() pprint(api_response) except ApiException as e: print("Exception when calling LMApi->getAlertList: %s\n" % e) If you will be using it a lot, or if you want to use the interactive python interpreter, you can put my LM Wrapper in the same directory as your script and call it. It will do all the messy work of setting up the objects and get you ready in one line: 4. After step 3 (Instead of writing out the whole script), install nano and curl: apt install -y curl nano 5. Download the wrapper: curl -o lm.py https://raw.githubusercontent.com/sweenig/lmcommunity/master/LMAutomation/lmwrapper/lm.py 6. Setup your creds file. This will be a json file in the same directory called "creds.json". It should contain JSON with your access id, key, and company name: { "API_ACCESS_ID": "adelarthrosomatous", "API_ACCESS_KEY": "zygomaticoauricularis", "COMPANY_NAME": "yourportalname" } 7. Either write your script or run it interactively: from lm import lm alerts = lm.get_alert_list() devices = lm.get_device_list(size=1000)
  11. Cool that it's working. I think it would be pretty easy to modify the existing DS to pull from separate pages, then LM can aggregate if you need it but also show individual stats as well. Is there a programmatic way to discover the addresses of all the pages?
  12. I think it's the 427972 that's not right. Hard to say without navigating your IDs directly. Here's what I'd do (in code or in postman). If this is what you're already doing, ignore: /device/devices -> find the "id" of the device of interest (here, i'll call it $device_id) /device/devices/$($device_id)/devicedatasources -> find the "id" (not the dataSourceId) of the datasource of interest (here, i'll call it $DS_id) /device/devices/$($device_id)/devicedatasources/$($DS_id)/instances -> find the "id" of the instance of interest (here, i'll call it $instance_id) /device/devices/$($device_id)/devicedatasources/$($DS_id)/instances/$($instance_id)/data -> should have data here from the last hour For what it's worth, i was skeptical about postman too. I'm old school CLI as well. But i quickly got addicted. The other thing i got addicted to was the Python SDK. Combining it with my custom LM wrapper, the code becomes: from lm import lm data = lm.get_device_datasource_instance_data(9,9512,146237749) Where 9 is the $device_id, 9512 is the $DS_id, and 146237749 is the $instance_id.
  13. Is each page at its own address (port)? If so, we should be able to easily modify the discovery and collection scripts to pull from each one. If that's an option, you can try it. If it's pure SNMP, you might try the no-code option of building an SNMP DataSource in LM.
  14. What do you mean a CSV version?
  15. Would suggest you get postman up and running and vet out all the calls you are trying to make before you try to code them in. That will eliminate the question of whether it's something about the call or Posh. Just a suggestion. That said, when i did your call, the $($DS_CPU.id) variable is the id (9512), not the dataSourceId (24131557): And my $($inst_CPU.id) was the id (146237749), not any other id. That one stumped me for a while until i learned that lesson. So, my final call was {{url}}/device/devices/9/devicedatasources/9512/instances/146237749/data Where my $($device.id) is 9, $$DS_CPU.id) is 9512 (id) and my $($inst_CPU.id) was 146237749.