Search the Community

Showing results for tags 'collector'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • From LogicMonitor
    • General Announcements
    • LM Staff Contributions
    • Community Events
  • LogicMonitor Product Discussion
    • Feature Requests
    • LM Exchange
    • Ask the Community

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

  1. Is it possible from the debug console to reboot the collector box? If so what command can I use to do this? TIA..
  2. A while back I published some very simple ConfigSources to monitor your collector .conf files: Here's an adaptation that writes the various collected configs to a dashboard, writing each of the config outputs to a text widget. Notes: THIS IS A PROOF OF CONCEPT. No warranty is given or implied (value of your investments may go down as well as up, check with your health professional before taking this medicine, etc). Please test before deploying! As with all data within LogicMonitor (or any system), be aware of access rights of users - in this case to whatever Dashboard(s) the config data will be presented on. Be sure to configure your Roles and Users such that only users who have legitimate need to see this data can access whatever Dashboard(s) you send it to. This uses the REST API v1 to verify the target dashboard exists or create it if it doesn't, and also to create / update the text widgets. It will therefore need an API token for an account with management permission for the relevant Dashboard(s), with ID and Key values set as device properties apiaccessid.key and apiaccesskey.key. All of the API interaction is contained with a groovy checkpoint, rather than within the config collection script, so this could very simply be copied into other ConfigSources. The same logic could be used in other LogicModules, such as to write non-numeric outputs of SQL queries or any data collection methods to dashboards. While this provides no history retention as written, it will show current / most recent values. Within the script you can define the desired Dashboard path, e.g. 'Collector Configs/Groovy Check' (default as presented here), Dashboard name (hostDisplayName is the default), widget name format (hostDisplayName: wildvalue) and other initial parameters such as widget colour scheme, description, etc. This is written for REST API v1. One day I may get around to updating it for v2, for greater efficiency, but today is not that day. Tomorrow is not looking likely either. Dashboard text widgets do have a maximum character limit (65,535 characters). I don't think I've seen a collector config near to or in excess of this, so I have no idea whether a larger config from another device would be truncated or whether the widget creation would fail. Other widgets on the dashboard are unaffected by this script creating and updating widgets; likewise later manual changes to widget size, colours, etc should be respected; updates should be to the text content of the widgets only, so the target dashboard could contain other data from the device. For example, it might look a bit like this: Known issues: On the first config collection for a multi-instance ConfigSource like this, and where the target dashboard does not already exist, only one widget will be created in the dashboard. This is because all instances collect more or less simultaneously, and each determines the dashboard is not initially present. Each, therefore, attempts to create the dashboard and as soon as the first instance does so, the others will fail as they cannot create a dashboard that (now) already exists. This could be coded around with a simple delay / re-check on failure, but I haven't had time, and the second config collection will create all expected widgets without issue. Additionally, if you create the dashboard first, this issue will not occur.
  3. A couple of choices of ConfigSource to monitor the .conf files of your collectors. Note these are two versions of the same thing - you do not need both. One explicitly monitors only the four key .conf files; agent.conf, sbproxy.conf, watchdog.conf, wrapper.conf. That's done via the Active Discover script simply printing those four known filenames as instances: 76PEZ2 (v1.2) The other version has a more involved Active Discovery that lists any .conf found in the Collector config folder, with the exception of 'persistent_task.conf' as this file is continually being updated. This has the advantage that it will catch any new or renamed .conf files we add in in future: K992D7 (v1.2) The collection script of each simply reprints the content of each .conf file and alerts on changes, with a couple of exclusions for expected changes. AppliesTo = hasCategory("collector") They are grouped to appear within the 'Collector' datasource group on the devices alongside the collector-specific datasources.
  4. I would like to see a prompt for SDT that when I specify "[location].All" LM asks if I would like to place the Collector in SDT. I would never think to look in "Settings" area to place the collector in SDT, or that when I specify "All" the collector is not included. I understand why it separate, but the location for SDT on the collectors is not intuitive. I naturally went to [Domain].Collectors, which was incorrect, after I was told the collector SDT is separate. Thanks
  5. Hi All, As we all know, that currently logic monitor has a feature to setup only 1 fail over collector. I would like to request for a feature, where we can have multiple fail-over collectors and in such a way that even if, the collector is active and polling objects, it still can be set as a fail-over collector. Thanks & Regards, Akash Pandya
  6. Windows Server Core and (the free) Hyper-V Server Core are GUI-less versions of Windows that can be administered remotely with GUI tools. We've recently seen an uptick in requests for deployment of the collector to these platforms, as Windows introduces a lot of overhead with the addition of the GUI; the other compelling reason to go this route being that Hyper-V Core is a free license of Windows from Microsoft (similar to the free flavor of ESXi, only it can run a Windows collector!) Microsoft Documentation: Managing a Server Core Server Configure Server Core with the SConfig command Option A: Remote Desktop Install Establish a remote desktop session to the Server Core server using the instructions provided by Microsoft. Within the standard Command shell, type the word "PowerShell" to load a PowerShell session. Add a new (Windows) LogicMonitor Collector in your portal, and select the PowerShell command instead of the download. Paste (and run) the PowerShell command into the open PowerShell windows within the Remote Desktop Session on the Server Core server. You'll see a message indicating that the download has started, and after some time, the normal InstallShield Wizard will launch as expected. Complete the collector account configuration and proceed as you would with an OS with a GUI. Collect on! Additional methods are certainly possible (Windows Admin Center, Remote PowerShell, more?) and as I have a chance to test/ validate, I will continue to update this post.
  7. I know that it is not exactly recommended/reliable to use a 1GB/1CPU Core machine to monitor...but it seems that installing a "nano" sized collector on a t2.micro AWS instance and having it just monitor itself brings the AWS instance to a screeching halt. I am seeing that when the collector is running, top shows that CPU pegs to 100% almost nonstop. Memory is not hit quite as bad..but it does get up there to use 500mb+ But the CPU load average is 5+ cores and it makes the system unusable. Sometimes this causes the instance to throw status alerts & even crash. Question: Has anybody been able to tweak the wrapper.conf etc files to make the collector CPU load less demanding?
  8. Just in case this helps other customers... SYMPTOMS: The Windows collector installed ok and the two Collector services were running but the collector could not finish the verification/registration step and showing the 'flame alert' on Settings > Collectors screen. After some troubleshooting, we looked in the wrapper.log file on the collector and saw this error message: [MSG] [CRITICAL] [main::controller:main] [AgentHttpService.checkCertificateOrWait2Valid:1029] The santaba server is not trusted, and "EnforceLogicMonitorSSL" is enabled. Wait 1 minute to retry. Please check the network settings, or disable "EnforceLogicMonitorSSL" in agent.conf and restart collector The customer set up a whitelist on their Palo Alto firewall for * and it started working (or list of ~15 IP address ranges). Alternatively you can lower security and change the agent.conf (config file) from EnforceLogicMonitorSSL=true to false.
  9. I would like the REST API to support Scheduling a collector version update Applying a one-time collector version update Working with the Collector Custom Properties (recently added I think, but don't see anything in the online documentation about support in REST API).
  10. Collector groups were added recently, and are detailed here: Now let's expand upon that functionality...What if collectors be grouped dynamically? Identically to how Devices dynamic groups work, could I assign properties to collectors, then build dynamic groups based from the properties? Ways that envision sorting collectors: Production/test, primary/backup, collector number (1-99, 100-199, 200-299, etc.), zip code, time zone, alphabetical. In each of these cases, this would give full flexibility on how collector upgrades are scheduled. Currently if we have a mass collector upgrade to a new General Release, it can be a little painful to manage so many upgrades running simultaneously (or at least in very short order). I am most interested in being able to split them up into primary, backup and single collector groups. This way, I know that it's pretty safe to upgrade the collectors that have backups after hours, since there is another collector to failover to. And I surely want to be available staff-wise if I am doing upgrades for those collectors that have no backup collector. Close behind sorting into primary/backup/single is the need to sort them by customer (which currently works fine). The issue is that you can't put a collector into more than one group, which precludes from even setting up these to items manually.
  11. Hi I am having a frustrating experience when I have tried to make LM redundant using multiple collectors, but then I am at the mercy of the customers internet connection so when the collectors go down, I then get a couple of thousand host status events rather than a number of critical collector alerts making it very hard to see the wood for the trees in the UI alerts page as I cannot just filter out host status alerts as I could have more from other customers. Am I missing something? Do others have a decent scalable workaround? Has this been raised as a feature request before? and if so is there a reason its not materialised? Thanks in advance David
  12. Has anyone else experienced any issues with Collector 27.002? I updated our SNMP collector (8G RAM, about 600 devices) a few days ago and twice it has gone down with memory maxing out. Have downgraded back to 27.000. I did a Send Logs to LogicMonitor, if it helps.
  13. I know I've brought this up before, but I'd like to bring it up again. LM's requirement that collectors run as local admins (or system) is a GAPING security hole in your product. No amount of certificate signing, or other like security measures are a replacement for running a collector or an agent as a read only account. The fact is, with every security measure you take, if the collector is running as an admin account or a system account, its going to be exploitable in one way or another. Having the signed scripts and what not, would be great, but really it shouldn't be the primary focus IMO. Security is much better when its locked down by default and opened up as needed, compared to what you guys are doing, which is a completely open system, that you're trying to add security enhancements on top of. It's almost akin to you guys having no firewall,and then adding a few rules here an there to block certain types of traffic, while the rest of the network is completely exposed. A more prefered architecture (security wise) would be an agent / collector that can run as a read only account and be supported. WMI, perfmon, and many other functions all work fine with a regular user, when it's executed locally. That is why an agent or a special collector is needed. Most ideal communication path would be an "agent" talks to a "collector" which then talks to the portal. This would also allow us to keep our internet locked down. I suspect this would also have the other advantage of taking a lot of load off the collectors and really putting most of the work on the agent, which is ultimately better given that the workload would be distributed. For now though, even having a "supported" configuration for a collector not running as a local admin / system would be a great step in the right direction. The reason this is less of a concern for solution like Solarwinds and SCOM is they're on premises based solutions, meaning there is much lower external risk factor. You guys are cloud, and there for need to design the solution from an untrusted point of view.
  14. Hi, Maybe the community are intressted in using collectors as stand-alone outside a domain (in a workgroup).. We are and have ran into all possible effects of it... one thing is to monitor Windows DHCP Servers that ar joined to a domain. THen you need to authenticate against some classes to discover and to get metrics. Had some chat sessions with the LM support and they got me closer to the solution.. But I solved it finally using credentials to discover and inventory the DHCP server and Scopes with powershell using domain credentials on my collector in a workgroup Here they Are Microsoft DHCP Scopes: 6R7ZKC Microsoft DHCP Server: Z2JTFN Enjoy!!
  15. These are not ConfigSources. They do not record, store, alert on changes to, let you view historic (etc) config files. If that's what you're after and you have LM Config, take a look here: These, however, are DataSources that read and parse out certain values from certain Collector .conf files, that let you quickly see a few key settings without having to look at and scroll through the config files. Graphs can show you how values have been changed over time. Mostly these are for information only, although there are a couple of useful alert thresholds set. All have AppliesTo of hasCategory("collector") === LogicMonitor_Collector_Settings_General: v1.0.0: PYXRR4 Reads a few key values from agent.conf and wrapper.conf, such as any restart setting, logger size, SB Proxy connector capacity and Java max heap. Will generate a warning alert if the SB Proxy connector capacity may need increasing due to a large Java max heap size.Additionally monitors the ID of the collector being used to monitor the collector device and alerts if the collector is being monitored by a different collector (we strongly recommend collectors monitor themselves). === LogicMonitor_Collector_Settings_DataCollection: v1.0.0: DM76FY Reads the enable setting (true|false, mapped to 1|0), threadpool and timeout settings for each collection method (snmp, wmi, script, etc) defined in the collector's agent.conf file.Will generate a warning alert for any collection method disabled in the config. === LogicMonitor_Collector_Settings_EventCollection: v1.0.0: N4ENYL Similar to the above, reads the enable setting and threadpool for event collecting tasks. Will generate a warning alert for any that are disabled in the config. ===
  16. New to this forum. We are trialing LogicMonitor as a replacement for a traditional NMS system. We're a resell of NMS service. I believe the industry calls that an MSP. We want to resell this service using an appliance as collector. Basically we want to preload the collector software and send it to a customer location and then go from there. What I'm struggling with is some guide to what hardware we should spec out for this. I realize a one size fits all is not going to get it. Our customers service is all WAN only routers and some customers have netflow. We have some customers that have 10 or 15 devices and some that have all the way up to 1000 to 1200 devices with every thing in between. The protocols used are SNMP, ICMP, Syslog, Netflow. So I'm thinking one type of hardware for 0 to 200 devices, another for 200 to 500 devices, and a third for 500 to 1200 devices. I figure anything above that is going to take more than one collector. I have found a industrial vendor that can supply boxes with every thing from Celeron to Xeon class CPUs and everything in between with 2g to 16g or more and SDD or HDD drives. The first question is does any one have any experience running collectors with Quad Core Celeron processors. Second question is what size hard drives show we have. There's not really in formal documents that the company publishes on Collector hardware other than an obscure document list Xeon class servers and even that has no disc sizing recommendations. Any help and advice would greatly be appreciated
  17. Ability to filter !tlist output. Example, !tlist all data points not returning any data aka nan.
  18. This article provides information on High CPU usage on the Collector . (1) General Best Practices (a) First and foremost we advise our customers to be on latest General Release Collectors (unless advised not to) . Further information all the Collector information could be retrieved on the link below : Also on the release notes of each newer Collector version we will indicate if we have fixed any known issues : (b) Please also view our Collector Capacity guide to get a full overview on how to optimise the Collector Performances : (c) When providing information on High CPU usage it would be useful if you can advise if the High CPU usage is all the time or a certain timeframe only (also if any environmental changes were done on physical machine that may have triggered this issue). Please do advise also if this occurred after adding newer devices on the collector or if this issue occurs after applying a certain version of the Collector. (2) Common Issues On this topic i will go through some of the common issues which have been fixed or worked upon by our Development Teams : (A) Check if the CPU is used by the Collector (Java Process) or SBproxy or other processes. (i) To monitor Collector Java Process : Use the datasource Collector JVM status to check the Collector (Java process) CPU usage (as shown below). (ii) To monitor the SBProxy usage : We can use the datasource : WinProcessStats.xml (for Windows collector / For Linux data source (this datasource is still being developed) . (B) If the high CPU usage is caused by the Collector Java processes, below are some of the common causes : (i) Collector java process using high CPU How confirm if this the similar issue : In the Collector Wrapper Logs you are able to view this error message : In our Collector wrapper.log, you can see a lot of logs like the below: DataQueueConsumers$] Un-expected exception - Must be BUG, fix this, CONTEXT=, EXCEPTION=The third long is not valid version - 0 java.lang.IllegalArgumentException: The third long is not valid version - 0 at com.santaba.agent.reporter2.queue.QueueItem$Header.deserialize( at com.santaba.agent.reporter2.queue.impl.QueueItemSerializer.head( This issue has been in Collector version EA 23.200 (ii) CPU load spikes on Linux Collectors As shown in the image below the CPU usage of Collector Java process has a periodic CPU spike (on an hourly basis) . This issue has been fixed on Collector version EA 23.026 (iii) Excessive CPU usage despite not having any devices running on it In the collector wrapper.log, you can see similar logs as below : [04-11 10:32:20.653 EDT] [MSG] [WARN] [pool-20-thread-1::sse.scheduler:sse.scheduler] [SSEChunkConnector.getStreamData:87] Failed to get SSEStreamData, CONTEXT=current=1491921140649(ms), timeout=10000, timeUnit=MILLISECONDS, EXCEPTION=null java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask.get( at com.logicmonitor.common.sse.connector.sseconnector.SSEChunkConnector.getStreamData( at com.logicmonitor.common.sse.processor.ProcessWrapper.doHandshaking( at com.logicmonitor.common.sse.processor.ProcessorDb._addProcessWrapper( at com.logicmonitor.common.sse.processor.ProcessorDb.nextReadyProcessor( at com.logicmonitor.common.sse.scheduler.TaskScheduler$ at java.util.concurrent.Executors$ at at java.util.concurrent.ThreadPoolExecutor.runWorker( at java.util.concurrent.ThreadPoolExecutor$ at This issue has been fixed on EA 24.085 (iv) SSE process stdout and stderr stream not consumed in Windows Please note this issue occurs on only on Windows Collectors and the CPU usage of the Windows operating system has a stair-step shape as shown below. This has been fixed in Collector EA 23.076 (v) Collector goes down intermittently on daily basis In the Collector wrapper.logs, you can see similar log lines : [12-21 13:10:48.661 PST] [MSG] [INFO] [pool-60-thread-1::heartbeat:check:4741] [Heartbeater._printStackTrace:265] Dumping HeartBeatTask stack, CONTEXT=startedAt=1482354646203, stack= Thread-40 BLOCKED ( com.santaba.common.logger.Logger2$1.print ( com.santaba.common.logger.Logger2._log ( com.santaba.common.logger.Logger2._mesg ( ( com.santaba.agent.util.Heartbeater$HeartBeatTask._run ( com.santaba.agent.util.Heartbeater$ ( java.util.concurrent.Executors$ ( ( java.util.concurrent.ThreadPoolExecutor.runWorker ( java.util.concurrent.ThreadPoolExecutor$ ( ( [12-21 13:11:16.597 PST] [MSG] [INFO] [pool-60-thread-1::heartbeat:check:4742] [Heartbeater._printStackTrace:265] Dumping HeartBeatTask stack, CONTEXT=startedAt=1482354647068, stack= Thread-46 RUNNABLE ( com.santaba.common.logger.Logger2$1.print ( com.santaba.common.logger.Logger2._log ( com.santaba.common.logger.Logger2._mesg ( ( com.santaba.agent.util.Heartbeater$HeartBeatTask._run ( com.santaba.agent.util.Heartbeater$ ( java.util.concurrent.Executors$ ( ( gobler terminated ERROR 5296 java.util.concurrent.ThreadPoolExecutor.runWorker ( java.util.concurrent.ThreadPoolExecutor$ ( ( This issue has now been fixed in Collector EA 22.228 (C) High CPU usage caused by SBProxy (i) Collector CPU spikes until 99% The poor performance of WMI or PDH data collection on some cases will cause too many retries will occur and this consumes a lot of CPU. In the collector sbproxy.log, you can search the log string as shown below and you can see the retry times is nearly 100 per request and subsequently this will consume a lot of CPU. ,retry: This is being investigated by our development team at this time and will be fixed in the near future . (3) Steps to take when facing high CPU usage for Collector (i) Ensure the collector has been added as a device and enabled for monitoring : There are set of New Datasources for the Collector (LogicMonitor Collector Monitoring Suite - 24 DataSources) which as shown below and please ensure they have been updated in your portal and applied to your Collectors and also ensure the Linux CPU or Windows CPU datasources have been applied to the Collector : (ii) Record a JFR (java flying record) in debug command window of the Collector : this can done through this method : // unlock commercial feature !jcmd unlockCommercialFeatures // start a jfr , in real troubleshooting case, should increase the duration a reasonable value. !jcmd duration=1m delay=5s filename=test.jfr name=testjfr jfrStart // stop a jfr !jcmd name=testjfr jfrStop // upload the jfr record !uploadlog test.jfr (iii) Upload the Collector Logs : From the Manage dialog you can send your logs to LogicMonitor support. Select the manage gear icon for the desired collector and then select 'Send logs to LogicMonitor': Credits: LogicMonitor Collector development team for providing valuable input in order to publish this article .
  19. Has anybody downloaded a valid collector executable for windows using the rest API? I tried both python and powershell code to download, but the file downloaded cannot be executed. Logic Monitor Support has confirmed that this is a bug and they are working on it. Request #77831
  20. Let’s walk through the attached Python script that utilizes the LogicMonitor API. This script will automate a collector install for Linux. It will Create the Collector Object, Download the collector installer, give the collector executable permissions, and finally install and register the collector. Full documentation including examples for the LogicMonitor REST API can be fond in the below link We have examples for most of the functions in the API on our support site. Using these examples, it’s possible to copy\paste only making minor changes to create a script for your needs. This example will explain how to do this as well as combine multiple example scripts together. Declaring the environment and classes. This can be mostly copied\pasted from the example templates. #!/bin/env python import requests import json import hashlib import base64 import time import hmac import commands This is the authentication setup. It’s easier than it looks. To get the AccessID and AccessKey, open the console and create a new or use an existing user. Under the API Tokens, press the + button to generate the tokens. The company name is the portal ie, mine is ‘’ so my company is 'lmjeffwoeber' #Account Info AccessId ='bB29823sN4MdwC9B3k3i' AccessKey ='P-6D)xH_76Q4+AS2-T67hZ%N3|Nc2]6LC4U647%5' Company = 'lmjeffwoeber' Now that we have our authentication setup we need to gather the data to put into our API call URL and create the collector object on the portal. This is from the example on the Add a Collector page Feel free to add or remove properties to the “data=’{" string to fit your environment, a complete list of properties can be found in the above link. #Create Collector Object #Request Info httpVerb ='POST' resourcePath = '/setting/collectors' queryParams = '' data = '{"description":"TestCollector1","backupAgentId":39}' #Construct URL url = 'https://'+ Company +'' + resourcePath +queryParams Next construct the URL, this can be mostly copied\pasted as it does not really change. #Get current time in milliseconds epoch = str(int(time.time() * 1000)) #Concatenate Request details requestVars = httpVerb + epoch + data + resourcePath #Construct signature signature = base64.b64encode(,msg=requestVars,digestmod=hashlib.sha256).hexdigest()) #Construct headers auth = 'LMv1 ' + AccessId + ':' + signature + ':' + epoch headers = {'Content-Type':'application/json','Authorization':auth} This part executes the URL and the API will create the Collector Object #Make request response =, data=data, headers=headers) Next is the tricky part. We need the collector ID for the rest of the script so we have to extract that from the returned JSON file and add it to a local variable for later use. LogicMonitor uses the JSON format as payloads. You can read about parsing JSON files from Lets use the script to walk through the parsing process. This is JSON snippet is what the Add Collector function will return. Response Body: { "status" : 200, "errmsg" : "OK", "data" : { "id" : 84, "createdOn" : 1486761412, "updatedOn" : 1486761412, "upTime" : 0, "watchdogUpdatedOn" : 1486761412, "status" : 0, The collectorID:# or '"id" : 84' is needed for the rest of the script. The jsonResponse = json.loads(response.content) is used to grab the JSON response from the above response function and define it to the local variable jsonResponse. This will give the script access to the returned JSON data. The JSON dictionaries needs to be specified to pull specific data, to accomplish this take a look at the "{", entries in the JSON snippet. These are the dictionaries. To simplify this, we need to place them in [ ] to pull the data out of the JSON file. In this case their is only the main body dictionary which does not need to be references and a "data" dictionary. To pull the value for the ID dictionary use the syntax ['data']['id'] as seen in the example below. #Parse response jsonResponse = json.loads(response.content) #The CollectorID is needed to download the installer deviceID=(jsonResponse['data']['id']) Now the ID number is assigned to the variable 'deviceID'. We are using the Collector ID for URLs so we need to convert this from a int to a string. Easy enough using the str() function #Converting the int to a str deviceIDstr=str(deviceID) #print(deviceIDstr) Now the string version of the collector ID is in the variable deviceIDstr and we can use that in the API URLs. The print function provides nice feedback for the end user so they can track what is happening. print"Create Collector Object ID:"+(deviceIDstr)+" success!" The first part is done and we have created a Collector Object on the portal and stored the Collector ID locally in a variable. Time to download the collector installer. The template for this section can be found on our support site Declaring the environment and classes and setting up authentication can be skipped as it’s already done. Lets build the URL according to the example script. #Download Collector Installer #Request Info httpVerb ='GET' Next add the collector ID to the URL this can do this by adding in the deviceIDstr var directly in the resource path. #Adding the CollectorID to the URL resourcePath = '/setting/collectors/'+deviceIDstr+'/installers/Linux64' Any property found on the above link to the REST API Collector download can be set on the queryParams variable. The example is using collectorsize= and setting it to nano, as this is just a lab. #Specify size [nano|small|medium|large] queryParams = '?collectorSize=nano' data = '' Just in the case as the previous section, it's possible to copy\paste the construction of the URL as it’s mostly the same as the example. #Construct URL url = 'https://'+ Company +'' + resourcePath +queryParams #Get current time in milliseconds epoch = str(int(time.time() * 1000)) #Concatenate Request details requestVars = httpVerb + epoch + data + resourcePath #Construct signature signature = base64.b64encode(,msg=requestVars,digestmod=hashlib.sha256).hexdigest()) #Construct headers auth = 'LMv1 ' + AccessId + ':' + signature + ':' + epoch headers = {'Content-Type':'application/json','Authorization':auth} #Make request response = requests.get(url, data=data, headers=headers) This part downloads the collector as “LogicMonitorSetup.bin” to the current working directory. #Print status and write body of response to a file print 'Response Status:',response.status_code file_ = open('LogicMonitorSetup.bin', 'w') file_.write(response.content) file_.close() The download is now complete, now we need to give the LogicMonitorSetup.bin file execute permissions and run it. I used the commands function feel free to use any preferred alternative, we are just running shell commands at this point. #Give execute perm to collector install and install with the silent option commands.getstatusoutput('chmod +x LogicMonitorSetup.bin') End user feedback print"adding execute permissions to the collector download" print"Starting collector install" Run the Setup.bin file with the silent option -y A full list of install options can be seen by running ./LogicMonitorSetup.bin -h commands.getstatusoutput('./LogicMonitorSetup.bin -y') print"Script Complete" And that's it! A new collector should be registered on the portal. -Jeff Below is a copy of the example script used for this post. #!/bin/env python import requests import json import hashlib import base64 import time import hmac import commands #Account Info AccessId ='j53939s54CP3Z9SUp6S5' AccessKey ='k[t2nP6-Srie[=M9Ju%-H8riy8Sww3Mp9j%kse5X' Company = 'lmjeffwoeber' #Create Collector Object #Request Info httpVerb ='POST' resourcePath = '/setting/collectors' queryParams = '' data = '{"description":"TestCollector1"}' #Construct URL url = 'https://'+ Company +'' + resourcePath +queryParams #Get current time in milliseconds epoch = str(int(time.time() * 1000)) #Concatenate Request details requestVars = httpVerb + epoch + data + resourcePath #Construct signature signature = base64.b64encode(,msg=requestVars,digestmod=hashlib.sha256).hexdigest()) #Construct headers auth = 'LMv1 ' + AccessId + ':' + signature + ':' + epoch headers = {'Content-Type':'application/json','Authorization':auth} #Make request response =, data=data, headers=headers) #Parse response jsonResponse = json.loads(response.content) #The CollectorID is needed to download the installer deviceID=(jsonResponse['data']['id']) #Converting the int to a str deviceIDstr=str(deviceID) #print(deviceIDstr) print"Create Collector Object ID:"+(deviceIDstr)+" success!" #Download Collector Installer #Request Info httpVerb ='GET' #Adding the CollectorID to the URL resourcePath = '/setting/collectors/'+deviceIDstr+'/installers/Linux64' #Specify size [nano|small|medium|large] queryParams = '?collectorSize=nano' data = '' #Construct URL url = 'https://'+ Company +'' + resourcePath +queryParams #Get current time in milliseconds epoch = str(int(time.time() * 1000)) #Concatenate Request details requestVars = httpVerb + epoch + data + resourcePath #Construct signature signature = base64.b64encode(,msg=requestVars,digestmod=hashlib.sha256).hexdigest()) #Construct headers auth = 'LMv1 ' + AccessId + ':' + signature + ':' + epoch headers = {'Content-Type':'application/json','Authorization':auth} #Make request response = requests.get(url, data=data, headers=headers) #Print status and write body of response to a file Print"Downloading Collector Installer" print 'Response Status:',response.status_code file_ = open('LogicMonitorSetup.bin', 'w') file_.write(response.content) file_.close() #Give execute perm to collector install and install with the silent option commands.getstatusoutput('chmod +x LogicMonitorSetup.bin') print"adding execute permissions to the collector download" print"Starting collector install" #-m bypasses mem check as my lab only has 1 gig of ram. Remove in production commands.getstatusoutput('./LogicMonitorSetup.bin -y -m') print"Script Complete"
  21. LM Team, When you are on your primary collector and choose a failover collector and are deciding to check that box "Automatically failback when THIS collector becomes available again". The way that it is worded, THIS collector could mean the current collector you are configuring. Then again, the checkbox is underneath the failover collector you just selected and it is indented, so it's easy to convince yourself that it could be referring to the failover collector. I think it would be worth re-wording or at least offering a hover-hint (?) box to clarify that the failback will be occurring on the collector you are currently configuring. Looking back, I had checked this box differently depending on how I felt that day and which made most sense to me at the time. Some clairification would be good. Thanks!
  22. Collectors can be installed using Nano/Small/Medium/Large configurations. Please add a column in Settings->Collectors to show this.
  23. Hi All, Could you please consider the following as product feature. To make changes to the "Configure LogicMonitor Collector" without the need to uninstall and reinstall the collector. For example the error stating that your credential is wrong no you need to schedule down time just to uninstall and reinstall the collector where you can just simply modify your credential which take you 5 sec to do. Thank you! Looking forward to the out come. Kind Regards Gerrit
  24. I understand that at this moment we can only receive LM Collector update notifications by subscribing to which then sends an email when a new version is released. It would be nice to be able to receive such kind of notifications, using email and/or integrations, when the internal LM 'variable' for Settings->Collectors->Updates->Upcoming->version is changing. An addition to that would be some kind of button/link in the notification to process the update for all or some (selected) LM Collectors.
  25. Some times the collector has an issue and we would like to determine this from the alerts page