PropertySource polling interval
I have a device property that I would like to update every 15 minutes or so. This is because I have groups with auto-include rules that are looking for that property. I need to have the device move in and out of the groups on the fly. It would be great if we could setindividual custom propertysources to update on a more frequent basis. Currently I'm achieving this using the LogicMonitor Rest API which I have baked right into adatasource as a workaround - but I think this solution is messy. Thanks!27Views0likes0Comments
Update Instance level properties from propertysource
I am working on an integration utilizing autoinstance properties. I am adding instance level properties to custom discovery scripts which end up in the json payload when an alert is triggered. I use the property to escalate to different teams in the organization. This is based on https://www.logicmonitor.com/support/datasources/active-discovery/script-active-discovery/ The issue I am running into and thus the feature request. I would like to have an instance level property added automatically to built in data sources where I don't use a custom discovery script. One datasource I use is SQLServerStatistics which does auto discovery via perfmon. There is no way for me to add a property to the datasource or discovery instances. Currently we can add auto properties to devices themselves via PropertySources but thats as granular as I can get. I could do this with the api but then there is a lot more management on my side of things. It would be nice if I write a propertysource to update/add an instance level property like you can with a custom discovery script.20Views0likes0Comments
Customisable "Minimal Monitoring" PropertySource
This PropertySource uses the LogicMonitor API to examine the DataSources that are actively applied to a Device, and from there determine whether the Device should be considered to be "minimally" monitored. Note that many accounts have an automatically created "Minimal Monitoring" dynamic Device Group; this Group has various conditions that have to be met for a device to be included: system.sysinfo == "" && system.sysoid == "" && isDevice() && !(system.virtualization) && (monitoring != "basic") However, there are certain types of Device - for example, those from which LogicMonitor *only* pulls data from an API or CLI tool and for which no sysinfo is available- that may fall outside of the group's definition. These Device types are currently very small in number, so if the current Minimal Monitoring Group does everything you need it to, you can pretty much stop reading here! This PropertySourcedetermines whether a device should be classed as being minimally monitored based on presence (or rather, absence!) of multi-instance, Auto-Discovery,DataSources, with specific exclusions that a user can edit in the script. (SSLCerts-,Port-,HTTP-,HTTPS-,LogicMonitor_Collectorby default / initially) The logic for this is that single-instance DataSources can appear on a Device regardless of data collection permissions (e.g. Ping, DNS), or by having their "AppliesTo" set to a specific Device or Group, and their presence does not indicate proof of data collection. Similarlya small number of multi-instance DataSources (such as SSLCerts-, Port-, HTTP-, HTTPS-) can be correctly applied and returning data without credentials. A further group of multi-instance DataSources (such as PingMulti-, UNC Monitor-) can have instances manually applied without necessarily working, or proving monitoring of the device is working. Finally, the LogicMonitor_Collector* DataSources will work for a Linux collector regardless of the collector's ability to monitor its machine's own SNMP data, so these are also ignored. The presence of actively discoveredinstances of the remaining multi-instanceDataSources on a Device will (almost) always indicate that the collector has been able to communicate with the device sufficiently to permit Active Discovery to query the device and have data returned. It is possible to construct DataSources that fall outside of this general rule, so the script can therefore be edited to ignore these too. You will need: A REST API Access ID and Access Key for a user with permissions to at least view all Devices within the account (or all Devices in whichever Groups you wish to consider). These should be set as properties 'apiaccessid.key' and 'apiaccesskey.key' within the Devices tree (generallythe root level,or a Group level if appropriate). The PropertySource will use these to determine the likely status of the Device, and create an auto.monitoring property for all devices. auto.monitoring will have the value 'minimal' where no suitable multi-instance DataSources are found on a Device; the value 'active' where there are such DataSources, or one of two error messages if the required API details are not present or do not give sufficient access to query the Device. At the top of the script is the following code block; the list of multi-instanceDataSourcesto ignore (stored as excludedDataSourcesList)can be edited if so desired - please read the important notes first: // --------------------------------------------------------------------------------------- // You can amend the following list to ignore (or not) the presence of whichever // DataSources you do not wish to consider when determining "minimal" monitoring. // IMPORTANT NOTES: // 1. Single-instance datasources are excluded by default. // 2. Multi-instance datasources with MANUAL instance creation are excluded by default. // 3. You MUST use the DataSource Name as found in the Name field of the DataSource definition. // This is not always the same as the displayed name as seen in the Devices page // (and in the "Displayed as" field of the DataSource definition). // 4. Exclusions are done by "dataSourceName!~", which is "name not like" - so we are effectively // excluding "*dataSourceName*", rather than an exact match. Excluding "LogicMonitor_Collector" // therefore excludes ALL DataSources with "LogicMonitor_Collector" in their name. def excludedDataSourcesList = [ 'SSLCerts-', 'Port-', 'HTTP-', 'HTTPS-', 'LogicMonitor_Collector', ]; // --------------------------------------------------------------------------------------- You can the create or modify a "Minimal Monitoring" group with an auto-assign custom query of: auto.monitoring == "minimal" ...to include all Devices you may want to further investigate / debug. :)/emoticons/smile@2x.png 2x" title=":)" width="20"> v1.1.0:Z97KZX11Views0likes2Comments
Automatic grouping by service status
A customer recently requested assistance with grouping some of their hosts that were running a particular service. This can be achieved by a combination of Active Discovery, Dynamic Groups, PropertySources, and of course functioning WMI. ? First, we have to figure out how to dynamically group these. We can rely on a custom query to automatically match the devices we want to see, but must depend on the properties from a device’s Info tab for any evaluation. We can use a PropertySource to do some of this work for us, and have it perform a check for the service and apply a property if it is found. Let's confirm we can query this host, and see how it identifies itself. I can query the win32_service class for a test host and see what gets returned: Great, so I've found an example of the service I want, and canreference its NAME attribute in our PropertySource to check for a match and determine if a host has this service installed. This PropertySource runs a WMI query against the win32_service class, looking for the NAME of the service as it’s report as an attribute. If it finds a match, it checks to seeif it’s running, and if those two pass it applies a property called "auto.GoldenEye" to the device. The nice thing about this PropertySource is that if discovery finds the device no longer runs the installed service, it will remove the autoproperty, and thus remove it from the dynamic group. This allows you to have a top level view of only thosedevices with the service actually running. Now that we have a method to automatically flag the service we want to track, we can reference this property name in our Dynamic Group query. This is a simple boolean check to see if the property is applied to any given host As an optional step, but highly advised, we can add the services as monitored instances. You may already know that running services can be added into LM through the Add Other Monitoring option in the UI, but this can become cumbersome if you want to add the same or multiple services into monitoring for manydevices. Since the wizard in the link above is just a frontend for the WinServices datasource, we can work with a clone of it, enable Active Discovery to automatically apply to eligibledevices, and utilize filtering to specify which services to monitor.Here I've specified that I want it to match by the DISPLAYNAMEattribute of the win32_service class: Once this is applied, discovery automatically checks each host for the desired service, and returns it as an alertable instance so you can be notified when it is not running or has degraded performance. Further reading: LogicMonitor Scripting Monitoring Processes and Services Creating PropertySources PropertySource embedded Groovy script example: import com.santaba.agent.groovyapi.win32.WMI import com.santaba.agent.groovyapi.win32.WMISession // Set hostname def hostname = hostProps.get('system.hostname'); // Form the full query. def wmiQuery = "Select name,state from Win32_Service Where name='someservicenameNOTdisplayname'"; try { // using default namespace def session = WMI.open(hostname); def result = session.queryFirst("CIMv2", wmiQuery, 10); // Did we get anything? if (result.STATE == "Running") { // Yes, apply the properties println 'auto.somedesiredpropname=yes' } } catch(Exception e) { println e return 1; } // Exit by returning 0. return 0;10Views0likes0CommentsPropertySource - Installed Windows Server Features
Useful for inventory, auditing, and auto-grouping. Displays the a list of all installed Windows Features separated by commas. Example below. auto.winfeatures [Active Directory Lightweight Directory Services, .NET Framework 3.5.1 Features, Telnet Client, Remote Server Administration Tools, .NET Framework 3.5.1, Role Administration Tools, AD LDS Snap-Ins and Command-Line Tools, AD DS and AD LDS Tools, Active Directory module for Windows PowerShell] WMN9DN6Views4likes9CommentsPropertySource - Windows Services
WARNING - This propertysource pulls a list of all Windows services installed. This does not filter the services to only show running or auto-starting services. Useful for auditing, auto-grouping, and inventory. Example below Displays the a list of all installed Windows Services. auto.winservices [AeLookupSvc, ALG, AppIDSvc, Appinfo, AppMgmt, aspnet_state, AudioEndpointBuilder, AudioSrv, BESClient, BESClientHelper, BFE, BITS, Browser, CertPropSvc, clr_optimization_v2.0.50727_32, clr_optimization_v2.0.50727_64, clr_optimization_v4.0.30319_32, clr_optimization_v4.0.30319_64, COMSysApp, CryptSvc, DcomLaunch, defragsvc, Dhcp, DiagTrack, Dnscache, dot3svc, DPS, EapHost, EFS, eventlog, EventSystem, FCRegSvc, fdPHost, FDResPub, FontCache, FontCache3.0.0.0, gpsvc, hidserv, hkmsvc, idsvc, IEEtwCollectorService, IKEEXT, IPBusEnum, iphlpsvc, KeyIso, KtmRm, LanmanServer, LanmanWorkstation, lltdsvc, lmhosts, MMCSS, MpsSvc, MSDTC, MSiSCSI, msiserver, MSSQL$SVSSDB, MSSQLFDLauncher$SVSSDB, MSSQLServerADHelper100, napagent, Netlogon, Netman, NetMsmqActivator, NetPipeActivator, netprofm, NetTcpActivator, NetTcpPortSharing, NlaSvc, nsi, PerfHost, pla, PlugPlay, PolicyAgent, Power, ProfSvc, ProtectedStorage, RasAuto, RasMan, RemoteAccess, RemoteRegistry, RpcEptMapper, RpcLocator, RpcSs, RSoPProv, sacsvr, SamSs, SCardSvr, Schedule, SCPolicySvc, seclogon, SENS, SessionEnv, SharedAccess, ShellHWDetection, SNMPTRAP, Spooler, sppsvc, sppuinotify, SQLAgent$SVSSDB, SQLBrowser, SQLWriter, SSDPSRV, SstpSvc, swprv, TapiSrv, TermService, THREADORDER, TrkWks, TrustedInstaller, UI0Detect, UmRdpService, upnphost, UxSms, VaultSvc, vds, VGAuthService, VMTools, vmvss, VMware Physical Disk Helper Service, VSS, W32Time, WcsPlugInService, WdiServiceHost, WdiSystemHost, Wecsvc, wercplsupport, WerSvc, WinHttpAutoProxySvc, Winmgmt, WinRM, wmiApSrv, WPDBusEnum, WRSVC, wuauserv, wudfsvc] Z4LHDZ4Views3likes11CommentsPropertySource - ConnectWise_ConfigID
PropertySource to retrieve the ID of a matching Configuration (CI) in ConnectWise. Quote This PropertySource uses the auto.entPhysicalSerialNum Device property (set by Cisco_Product_Info PropertySource) to query a ConnectWise site (instance) to find a matching Configuration ID. You can override the auto.entPhysicalSerialNum property with a manually-applied physicalSerialNum property. A matching Configuration ID is saved as a Device property, auto.connectwise.configid. Required properties: auto.entPhysicalSerialNum or physicalSerialNum connectwise.companysite connectwise.companyloginid connectwise.public.key connectwise.private.key These 4 properties can be found from ConnectWise's API documentation: https://developer.connectwise.com/ LM Locator:YR77GF3Views0likes1CommentUse of per collector http proxy settings for PropertySource scripts using Groovy HTTP helper methods.
I have created a Groovy script based PropertySource, that uses a REST call to contact an external site using the included HTTP helper methods in order to fill some information fields. This works fine in itself. The issue I have is the need to set the proxy details on the object after it is instantiated in the script. As far as I know, the collector properties/settings are not exposed in any way to a scripted PropertySource, despite the script running locally on the collector. Nor does the HTTP connection use the existing proxy as set on the collector. Unless I am missing something, it seems exceptionally convoluted to get those details, and then propagate them into property fields for all devices on that collector. to then be able to reference them properly inside the script. Is there any way to call the equivalent of getHostProps(), but for the collector properties? This would also be useful in cases of say, independent customer sites that use separate API keys for the same script.2Views0likes1CommentWindows MAC addresses PropertySource
@Dave Lee Qcame up with idea this initially, thenwe kicked it around a bit refining it, tweaking it, and completely rewriting it, before finally settlingon this version. What it does: Creates auto.interfaceindex_X.YYY property sources for every network interfacewith a MAC address on a Windows device. auto.interfaceindex_<interfaceIndex>.mac auto.interfaceindex_<interfaceIndex>.name auto.interfaceindex_<interfaceIndex>.netconnectionid Additionally, it creates a single auto.device.macaddresses property containing a semi-colon separatedlist of all MAC addresses on the device (to make life easier if you want to create and search a Device Inventory Report, for example). For details of the values returned, see Microsoft's documentation at:https://msdn.microsoft.com/en-us/library/aa394216(v=vs.85).aspx v1.2.0: 6AKP47 It'll give you something a little bit like this: You might also be interested in this mod of the WinIf- datasource, which finds and stores MAC addresses (and other properties) of monitored interfaces as Instance Level Properties: /topic/1584-winif-windows-interfaces-with-instance-level-properties/2Views0likes0Comments