Search the Community

Showing results for tags 'propertysource'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • LogicModule Exchange
    • LM Exchange
    • LM Staff Contributions
  • Product Announcements
    • LogicMonitor Notices
  • LogicMonitor Product Q&A
    • Feature Requests
    • Ask the Community
    • From the Front

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 13 results

  1. This one goes into some additional detail but hasn't been completely cleaned up for debugging purposes. The ones that have switch stacks pull all the stack serials and model numbers. Work in progress was the versioning. We have about 1500+ network devices across many many different models and versions so this has taken a little bit of work to get to work across all. MWXMXZ - Cisco-IOS FKA79M - Cisco IOS XE 9LF63N - NXOS G366DD - Cisco ASA
  2. Q: What does it do? A: Calls the LogicMonitor API and finds, for each applicable device, a list of DataSource Names that exist on the Device, i.e. have at least one instance. This also includes ConfigSources active on the Device. These are put together as a semicolon-seperated list in the property auto.activedatasources: Q: Why? I can just look at the Device in the Device tree. A: You can, but... This PropertySource means you can create Dynamic Groups and Device Inventory Reports based on the presence or absence of *any* combination of DataSources on Devices. Q: Can you give me a real-world example of this being useful? A: Yes. On a Microsoft SQL server, LogicMonitor will find the SQL Services via WMI, but the actual SQL Server metrics are found via Perfmon or JDBC methods. If we can't access Perfmon or JDBC for any reason (required services not running, lack of credentials, etc) we'll be missing the SQL stats but quite probably getting all the other Windows metrics (via WMI). This can be very difficult to spot if you have one affected SQL server out of 1,000. With this PropertySource running, you could create a Dynamic Group with a custom query of: auto.ActiveDataSources =~ "WinSQLServices-" && auto.ActiveDataSources !~ "WinSQLServer-" && auto.ActiveDataSources !~ "WinSQLServer_JDBC-" This will list all the devices on which we've found SQL Services but have failed to find any SQL metrics. Similarly Exchange Services are discovered via WMI, whilst most Exchange metrics come from Perfmon. Or, maybe you want to create a Group to contain all your Linux servers that are running Apache web server and MySQL: isLinux() && auto.ActiveDataSources =~ "Apache-" && auto.ActiveDataSources =~ "Mysql-" 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 (generally the root level, or a Group level if appropriate). The PropertySource will use these to find the list of DataSources present on the Device, and create the auto.activedatasources property for all devices. auto.activedatasources will have one of two error messages if the required API details are not present or do not give sufficient access to query the Device; this could of course also be used to create Dynamic Groups and in Device Inventory Reports. Note that DataSources are listed by their (unique) 'Name' rather than their (not necessarily unique) 'Displayed As' string seen in the Device tree. v1.0.0: ZLTDWM Current limitations: The auto.property fields are limited to 2,000 characters, so if the list of DataSource Names exceeds this size, the data will be truncated. This is likely to be an edge case only seen on test Devices with multiple custom DataSources applied. Auto Properties are updated daily or when Active Discovery is run for a Device, so there may (will!) be a time lag between DataSources being applied to a Device and those DataSources appearing in this auto.activedatasources property list.
  3. 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.
  4. 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 set individual 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 a datasource as a workaround - but I think this solution is messy. Thanks!
  5. 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] WMN9DN
  6. This is a PropertySource which runs with active discovery and adds the property auto.lmstatus to the device properties with the current Hoststatus value. It does this using the REST API and It works great with Dynamic grouping, for example if you wanted to know which device in your portal were currently in a dead status you could create a dynamic group with the applies to of “auto.lmstatus=="dead". One advantage to using a property source is if the device comes back on-line, Active Discovery will immediately run and change the property to "normal" removing the device from the group. A copy of the PropertySource is at the bottom of the post. Let’s walk through the groovy script. Define the account information This is polling the device properties. I recommend setting this at the group level so they are inherited to the devices. an example of the properties would be api.user = 5kCPqLgY4DGYP27uw2hc api.pass = ye[$3y7)_4g6L6uH2TC72k{V6HBUf]Ys+9!vB)[9 *note, any property with .pass in the name will not have visible data. api.account = lmjeffwoeber //Account Info def accessId = hostProps.get("api.user"); def accessKey = hostProps.get("api.pass"); def account = hostProps.get("api.account"); Define the Query. We just need the HostSatatus for the device the script is running on. def queryParams = '?fields=hostStatus&filter=displayName:'+hostName; def resourcePath = "/device/devices" Next we build the URL for the API. def url = "https://" + account + ".logicmonitor.com" + "/santaba/rest" + resourcePath + queryParams; This next part builds the security and runs the API. It can pretty much be copy\pasted into any groovy scripts that use the REST API. //get current time epoch = System.currentTimeMillis(); //calculate signature requestVars = "GET" + epoch + resourcePath; hmac = Mac.getInstance("HmacSHA256"); secret = new SecretKeySpec(accessKey.getBytes(), "HmacSHA256"); hmac.init(secret); hmac_signed = Hex.encodeHexString(hmac.doFinal(requestVars.getBytes())); signature = hmac_signed.bytes.encodeBase64(); // HTTP Get CloseableHttpClient httpclient = HttpClients.createDefault(); httpGet = new HttpGet(url); httpGet.addHeader("Authorization" , "LMv1 " + accessId + ":" + signature + ":" + epoch); response = httpclient.execute(httpGet); responseBody = EntityUtils.toString(response.getEntity()); code = response.getStatusLine().getStatusCode(); The API will return a JSON payload. We use the Groovy Slurper to transfer the payload to respose_obj were we can use the data. // user groovy slurper json_slurper = new JsonSlurper(); response_obj = json_slurper.parseText(responseBody); They JSON will look like data=[total:1, items:[[hostStatus:dead]] We can use the value with response_obj.data.items[0].hostStatus.value Now we print the Key=Value for the property source //print output println "LMStatus=" +response_obj.data.items[0].hostStatus.value; httpclient.close(); This will add the property source "auto.lmstatus" to the device finally we return 0 do indicate a success. return (0); This is how the PropertySource will appear on the device Lastly, we can create Dynamic Groups based off the Hostatus. For example use an applies to auto.lmstatus=="dead" to group all of the dead devices into one group, or auto.lmstatus=~"dead" to also include Dead-Collector LMStatus PropertySource import org.apache.http.HttpEntity import org.apache.http.client.methods.CloseableHttpResponse import org.apache.http.client.methods.HttpGet import org.apache.http.impl.client.CloseableHttpClient import org.apache.http.impl.client.HttpClients import org.apache.http.util.EntityUtils import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import org.apache.commons.codec.binary.Hex;import com.santaba.agent.groovyapi.http.*; import groovy.json.JsonSlurper; def hostName = hostProps.get("system.displayname"); //Account Info def accessId = hostProps.get("api.user"); def accessKey = hostProps.get("api.pass"); def account = hostProps.get("api.account"); data = '' def queryParams = '?fields=hostStatus&filter=displayName:'+hostName; def resourcePath = "/device/devices" def url = "https://" + account + ".logicmonitor.com" + "/santaba/rest" + resourcePath + queryParams; //get current time epoch = System.currentTimeMillis(); //calculate signature requestVars = "GET" + epoch + resourcePath; hmac = Mac.getInstance("HmacSHA256"); secret = new SecretKeySpec(accessKey.getBytes(), "HmacSHA256"); hmac.init(secret); hmac_signed = Hex.encodeHexString(hmac.doFinal(requestVars.getBytes())); signature = hmac_signed.bytes.encodeBase64(); // HTTP Get CloseableHttpClient httpclient = HttpClients.createDefault(); httpGet = new HttpGet(url); httpGet.addHeader("Authorization" , "LMv1 " + accessId + ":" + signature + ":" + epoch); response = httpclient.execute(httpGet); responseBody = EntityUtils.toString(response.getEntity()); code = response.getStatusLine().getStatusCode(); // user groovy slurper json_slurper = new JsonSlurper(); response_obj = json_slurper.parseText(responseBody); //print output println "LMStatus=" +response_obj.data.items[0].hostStatus.value; httpclient.close(); return (0);
  7. 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 PropertySource determines 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_Collector by 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. Similarly a 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 discovered instances of the remaining multi-instance DataSources 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 (generally the 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-instance DataSources to 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. v1.1.0: Z97KZX
  8. 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.
  9. @Dave Lee Q came up with idea this initially, then we kicked it around a bit refining it, tweaking it, and completely rewriting it, before finally settling on this version. What it does: Creates auto.interfaceindex_X.YYY property sources for every network interface with 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 separated list 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:
  10. EntPhysical shows Device-level information about the device chassis: 4GT264
  11. PropertySource to retrieve the ID of a matching Configuration (CI) in ConnectWise. LM Locator: YR77GF
  12. 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] Z4LHDZ
  13. Useful for inventory purposes. Displays the total number of CPU's, cores, and logical processors on Windows machines. Also provides a description of each CPU. Example below. auto.cpu.cores 4 auto.cpu.logicalcount 4 auto.cpu.total 4 auto.cpu0.description Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz auto.cpu1.description Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz auto.cpu2.description Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz auto.cpu3.description Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz MRF3XG