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.

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

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

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.

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.

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