This site requires JavaScript to be enabled
Welcome|
Recent searches
IE BUMPER

Zenoss Cloud Frequently Asked Questions

Number of views : 42
Article Number : KB0018906
Published on : 2024-01-25
Last modified : 2024-01-25 15:23:50
Knowledge Base : ESM External

(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.

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.

Even if an organization was careful only to add plain EIDs (not prefixed, departmental EIDs) to an AD Group for Zenoss Cloud access, an entirely separate Collection Zone group also has to be maintained by the Monitoring Team that has the Administrative Objects associated with it.

 

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 hierarchyThat 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.

Triggers can do more than just send notifications. You could write a rule set that if say a certain condition exists for a certain kind of server in a certain place, run a script or call an Ansible playlist or create a SN ticket, etc, which we hope to support in the future.

 

What is Out-of Service and why are my TEST devices in Out-of Service Production State?


The Out-of-Service production state was created by the Monitoring Team to make managing devices easier in a multi-tenant environment. It's to be used for devices that aren't in Production, but aren't in a Maintenance window, aren't being newly configured in Pre-Production, and aren't being Decommissioned.

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 Organizers in the Infrastructure View

Zenoss says a host is down, and I know it’s not down

t'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 device

If 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.

Are there network ACLs not allowing traffic from the 10.157.27.164/30 range?

 

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 DNS

Check that the IP is correct in Zenoss

Is this the IP set in DNS?

Is this the same one 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

Reset Zenoss IP

Windows Specific Issues

 

(Re)Configure WinRM for Zenoss Cloud

If your device was provisioned by ESM this typically is set up by ESM, but you might :

  1. Have a host that was not configured by ESM but needs to be monitored by Zenoss Cloud, or
  2. Something got messed up and you need to set WinRM back to how it was when it was provisioned.

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 Monitoring

Link the GPO ITSY-Settings-Windows - Enable WinRM for Zenoss Monitoring, which will configure the following: 

  • Allow remote server management through WinRM (and allows it to listen on all IPs configured on the device).
  • Allow remote shell access.
  • Allows unencrypted WinRM traffic  (Because the WinRM traffic will be contained entirely within the Data Center, encryption is not required according to the ISO.Configuring WinRM over HTTPS requires additional configurations that are not easily automated.

Link ITSY-Authorization Control-Restricted Groups - Zenoss Service Account

Link 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.

If this is a non-ESM provisioned device, you will want to share the account and password via stache with the Monitoring Team.

Link GPO ITSY-Advanced Firewall - Zenoss 

Link 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 Configuration

If it still is not working, check that WinRM is turned on and port 5985 open.

 

Linux Specific Issues

 

One Collector but not the other

Since 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 161

At 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 Wrappers

If 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 Issues

SNMP 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 

rhel6 root# /sbin/chkconfig snmpd on

rhel7 and rhel8 root# systemctl enable snmpd


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 Cloud

This is all set up at provisioning by ESM, but you might :

  1. Have a host that was not configured by ESM but needs to be monitored by Zenoss Cloud, or
  2. Something got messed up and you need to set SNMPD back to how it was when it was provisioned.

In any case, checking that these things are set right will usually resolve SNMP issues when all other avenues fail. So:

  1. Submit a request for Zenoss monitoring by sending email to monitoring@its.utexas.edu.  Your request should include the following information for each host requested:
    • FQDN
    • Zenoss Group (if applicable) and System

  2. You'll need to configure SNMPD for Zenoss Cloud monitoring by adding the zenoss SNMPv3 user. Replace AUTHPASS and PRIVPASS below with the passwords the monitoring team shares via the stache entry called Zenoss SNMPv3 zenoss user default credentials.

    #Stop the service
    service snmpd stop
    Back up the conf file:
    mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig
    Create the new one:
    echo 'rouser zenoss authPriv' > /etc/snmp/snmpd.conf

    #Depending on your version of Linux one of the two commands below should work.
    #If the first option gives you a command not found error, try the second.

    #Option 1:
    net-snmp-create-v3-user -ro -a 'AUTHPASS' -x 'PRIVPASS' -X AES -A SHA zenoss

    #Option 2:
    net-snmp-config --create-snmpv3-user -ro -a 'AUTHPASS' -x 'PRIVPASS' -X AES -A SHA

    #And don't forget:
    zenoss service snmpd start
  3. In the original Service Now request you created (or reply to the email), inform the Zenoss team SNMPD has been configured on the host(s).

 

 

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.


Filter by Device Type

 


Filter by Device Name

 


Filter by Production State

 

 


General Search

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 /Server/Linux device class might have a uid of /zport/dmd/Devices/Server/Linux/devices/my_test_device.company.loc.

For example, to execute getComponents via the DeviceRouter, a uid is required:

getComponents(**sort, **uid, **keys, **start, **meta_type, **limit, **page, **dir, **name)

Source

 

 

Thank You! Your feedback has been submitted.

Feedback