Zenoss Cloud Frequently Asked Questions
(Zenoss Cloud) Frequently Asked Questions
Overview |
|
---|---|
This is a FAQ for questions to supplement the Getting Started with Zenoss Cloud doc maintained by the ESM Monitoring Team and should be the first place to look for questions about the service and how to use it. Users are also recommended to read documentation by the vendor for more advanced topics. Table of Contents
|
|
General Questions |
|
What if I don't want to maintain my own monitors and just need simple endpoint monitoring or up/down status?This the purpose for which our sister service, Thousand Eyes, is intended. Make a request to the Monitoring Team to set up monitoring in Thousand Eyes. What is an Organizer in Zenoss?"Organizer" is a term Zenoss uses for any of groupings in the left column in the Infrastructure view, such as DEVICES, GROUPS, SYSTEMS, LOCATIONS, and COMPONENT GROUPS. We currently only use DEVICES which contain the specific devices assigned as Administrative Objects that belong solely to your Collection Zone group that a user has read/write access to, and SYSTEMS, which is a hierarchical organization of all the devices by owner that corresponds to the University's org chart.
How do I rename a device in Zenoss Cloud?You can change an IP or a device class fairly easily, but the best practice is to remove a device and recreate it with a new name. It's much easier that way that prevents unintended issues in the future.
How do I set up access for new users?If you have a new user or need to remove access from someone leaving your organization, you will need to make a request to the Monitoring Team. Access is set for your organization by the Monitoring Team when you enroll a service for monitoring. If your group owns multiple services, typically everyone in your group will have access to see, acknowledge, clear, edit, remove, and add new monitors to the console for those services.
What do you mean by organization? Is that like an Organizer?No, an organization is our term for something in the UT org chart that generally falls under a single manager, and usually encompasses multiple services that may alert to separate UT Lists. Everyone on the Monitoring Team, for example, will receive alerts for service level issues with Zenoss, Thousand Eyes, SCOM, and Splunk, but everyone in the larger ITS Campus Solutions ESM organization have console access to all the monitors for all the services under it. It's not an iron clad rule, but it is more manageable to maintain one AD / Cloud / Collection Zone tandem for ESM rather than 20 for each service.
Why can't I use my own AD group for access to Zenoss Cloud and maintain that on our own?As explained in the Getting Started documentation, Zenoss has multiple layers for access, an AD layer that specifies an AD Group with corresponding members for an organization, along with a Cloud Layer group with the same name that mirrors it. This grants login access to the Cloud Layer, which permits a login and access to very basic functions (not any monitors). As this login is done via ADFS, it requires one use a UT email address, so the AD users added to a group must be regular EIDs that correspond to one's normal UT email.
How do I set up alerting?Alerting is set up by the Monitoring Team. It is entirely separate from access to the Collection Zone in the Zenoss Cloud UI. When onboarding a new service, we set up a Trigger, which is a ruleset that by default will fire a Notification that is pointing to a group email owned and maintained by the owner (typically a UT List), which gives the owner control of who receives these alerts. That ruleset is based on the location of a device in the SYSTEMS hierarchy. That means if an owner adds more devices to that location, Zenoss already knows where to send alerts to and nothing new needs to be created. If you have a completely new service that's owned by your organization, with an all new email address to send alerts to, then you will need to send a ticket to the Monitoring Team in Service Now to create a new Trigger and Notification pair.
What is Out-of Service and why are my TEST devices in Out-of Service Production State?
When the Monitoring Team adds devices, by default, we do this in the Pre-Production state, but for TEST and DEV devices (*-d0* and *-t0*), we put them into the Out-of-Service state by default. Per the service definition, users are asked to help conserve resources by leaving TEST and DEV devices in the Out-of-Service if there is no present reason to actively monitor them, and to set them to production only for testing new features or updates.
What ports does Zenoss use?The short answer is, it depends, but standard practice when whitelisting an ACL or firewall is to allow all traffic from the network range 10.157.27.164/30. This is because customers way want to collect open ports, watch web processes, and so on and many features won't otherwise. But strictly speaking, Ping-only devices use ICMP (so no port to specify), WinRM (for Windows servers) use ports 5985/5986, and SNMP (Linux devices)use udp port 161. |
|
Zenoss says a host is down, and I know it’s not downt's almost always a configuration issue. So let's go over all the configuration details required of a device for Zenoss to monitor it. If these don't work, move on to the next section (Linux or Windows) for more information.
Check the Network Config on your deviceIf Zenoss can't see your host, it will see it as down. Make sure that your host can ping/traceroute the Zenoss collectors at 10.157.27.167 and 10.157.27.166. |
|
Check DNS, for both A record and Reverse (PTR Record)You can do this by pulling up the server in question within Zenoss Cloud, and clicking on (lower right) Commands button -> DNS Reverse. Zenoss has DNS has a dependency, so if reverse DNS isn't set properly, Zenoss has difficulty modeling a host. |
|
Check that the IP is correct in ZenossIs this the IP set in DNS? |
|
Has the IP changed since you originally configured it?You'll need to do this if you changed the IP of your device. Click on the gear button on the lower left * -> Reset/Change IP Address |
|
Windows Specific Issues |
|
(Re)Configure WinRM for Zenoss CloudIf your device was provisioned by ESM this typically is set up by ESM, but you might :
If your device was NOT provisioned by ESM, you'll want to copy these GPOs and link them In any case, checking that these things are set right will usually resolve WinRM issues. Link ITSY-Settings-Windows - Enable WinRM for Zenoss MonitoringLink the GPO ITSY-Settings-Windows - Enable WinRM for Zenoss Monitoring, which will configure the following:
Link ITSY-Authorization Control-Restricted Groups - Zenoss Service AccountLink the GPO ITSY-Authorization Control-Restricted Groups - Zenoss Service Account, which will add the group SYS-ZenossSvc to the local Administrators group. This group contains the service account that will make the WinRM connection for monitoring of Windows devices. Link GPO ITSY-Advanced Firewall - ZenossLink the GPO ITSY-Advanced Firewall - Zenoss which will configure the Windows Firewall to allow any TCP port in from the Zenoss monitoring VLAN. If this is a non-ESM provisioned devie, you will want to ensure that 10.157.27.164/30 is open in your firewall.WinRM ConfigurationIf it still is not working, check that WinRM is turned on and port 5985 open. |
|
Linux Specific Issues |
|
One Collector but not the otherSince the move to Zenoss Cloud, some hosts were set up to whitelist the first Zenoss Cloud collector, but not the second. Hosts will ping and model normally and then shortly after send alerts that it is down. If this is the case, make sure the entire network range is whitelisted in your firewall.If the firewall doesn’t have this rule, the Zenoss Cloud collectors can’t reach it. ACCEPT all -- 10.157.27.164/30 anywhere Open port 161At a minimum, customers need to allow udp port 161 traffic from the Zenoss subnet for SNMP monitoring to work. It is common however for customers to allow all traffic from the Zenoss subnet so that web servers, open ports, etc. can also be monitored easily. Overly Aggressive TCP WrappersIf you're using TCP Wrappers with an aggressive deny all policy you may also have to allow SNMPD through: /etc/hosts.allow snmpd : 10.157.27.164/30 : ALLOW
SNMPD IssuesSNMP is how Zenoss communicates with all Linux devices and is often a point of failure with networking issues. Is SNMP Installed and set to run at boot time?root# yum -y install net-snmp net-snmp-devel net-snmp-utils Is SNMPD being noisy/creating huge logs due to Zenoss communication? Typically SNMPD is very noisy in the logs already -- being polled by a Zenoss collector every five minutes can make it worse. This can be fixed by only logging more severe messages using the following options in the /etc/sysconfig/snmpd file. /etc/sysconfig/snmpd OPTIONS="-LS0-4d -Lf /dev/null -p /var/run/snmpd.pid" (Re)Configure SNMPD for Zenoss CloudThis is all set up at provisioning by ESM, but you might :
In any case, checking that these things are set right will usually resolve SNMP issues when all other avenues fail. So:
|
|
Using the GUI |
|
How come I can only add a single device? Why is adding multiple devices greyed out?Zenoss will only allow a user to change things owned as Administrative Objects by a Collection Zone group he or she belongs to. When creating a single monitor in the web GUI, the System and Device can be specified, but when using the interface to add multiple devices, it does not allow that to be specified and must be specified after the fact, which requires admin access. However, a user can use the API to get around this and specify all the relevant Organizers to add multiple monitors in one go.
I'm in my SYSTEMS group and can't add anything? What's going on?The GUI is finicky, and it's very easy to click out of an Organizer without realizing it. The easiest workaround it to click into the Organizer in question, such as one's Systems path, and copy the url from the browser, and then paste it back into the browser to return to that exact spot if you have functions greyed out that shouldn't be. How do I find a specific device or only certain types of devices I own?Finding a specific monitor or type of monitor is often necessary when you maintain a large fleet of devices. There are many ways to do this in the GUI, but the easiest is to use checkboxes and type into the headers in the Infrastructure View. You can type a string in the left-hand Device view to match, such as "Linux" to see only your Linux devices. You can similarly use type "zenoss" in the Device header to see only device names with the string "zenoss" in them or assuming all your hostnames follow convention, alternatively "t0" to see all TEST devices you own. You can select the check boxes under Production State to only see devices in a certain Production State, like only those in Maintenance. You can also add many together to get the results you are looking for, such as all Linux devices with the name "zenoss" in them. You can also use the general search box in the upper right. This will show devices that match your string, as well as alerts and components as well. |
|
API Questions |
|
What is a UID in the context of Zenoss Cloud?The UID of a device is its path, as it exists in the Zope Object Database (ZODB). For example, a device that exists in the For example, to execute getComponents(**sort, **uid, **keys, **start, **meta_type, **limit, **page, **dir, **name) |