This zenpack uses <code>df</code> utility to monitor filesystems capacity, and this utility could give misleading results for ZFS. When there are more then one filesystems in the same disk pool, the used plus free space for them will be less than total space, because some of it will be used for other filesystem. See: [http://docs.oracle.com/cd/E26502_01/html/E29007/gbcik.html#gbchp Oracle Solaris ZFS and Traditional File System Differences].

+

== Zenoss Analytics ==

== Zenoss Analytics ==

Line 389:

Line 404:

* zLDOMsAutodiscover

* zLDOMsAutodiscover

* zNodesAutodiscover

* zNodesAutodiscover

−

;Device Classes

+

;Device Classes

* /Server/Solaris

* /Server/Solaris

* /Server/SSH/Solaris

* /Server/SSH/Solaris

Line 397:

Line 412:

;Modeler Plugins

;Modeler Plugins

* zenoss.cmd.solaris.cluster

* zenoss.cmd.solaris.cluster

+

* zenoss.cmd.solaris.cluster_did

* zenoss.cmd.solaris.cpu

* zenoss.cmd.solaris.cpu

* zenoss.cmd.solaris.df_ag

* zenoss.cmd.solaris.df_ag

Line 480:

Line 496:

== Changes ==

== Changes ==

+

+

; 2.4.0

+

* Added support for updating zone status during monitoring (ZEN-17912)

;2.3.1

;2.3.1

Revision as of 08:10, 2 September 2015

Note: This ZenPack is available in commercial versions of Zenoss. Click here to request more information about this commercial ZenPack. Click here to see all commercial ZenPacks.

Background

The SolarisMonitor ZenPack enables Resource Manager to use either
Secure Shell (SSH) or the Simple Network Management Protocol (SNMP)
to monitor Solaris hosts. Resource Manager models and monitors devices
placed in the /Server/Solaris or /Server/SSH/Solaris
device classes. Data collection is performed on the Resource Manager
server (if using a local collector) or on a distributed collector.
The account used to monitor the device does not require root access or special privileges.

This ZenPack enables Resource Manager to model and monitor the following Solaris features:

Performance Monitoring

LDOM Device Discovery

You can optionally configure each Solaris LDOM server to attempt to discover
and monitor the guest operating systems running within each Solaris LDOM.
This requires that your Zenoss system has the network and server
access it needs to monitor the guest system.

Configure LDOM Device Discovery

Navigate to the Configuration Properties panel.

Checkmark zLDOMsAutodiscover to set it to true.

Cluster Features

Cluster information is collected using Secure Shell (SSH) and will
be displayed as components of the Cluster server.

Discovery

The following entities will be discovered.

Cluster Nodes

Attributes: Name, IP Address, Node Status

Relationships: Cluster DIDs, Cluster Resource Groups

ClusterDeviceGroup

Attributes: Name, Device Group Status

Cluster DIDs

Attributes: Name, Full Path, Replication, DID Status

ClusterIPMPGroup

Attributes: Name, IPMP Group Status

ClusterNASDevice

Attributes: Name, NAS Type

Cluster Resources

Attributes: Name, Resource Group, Status Message, Resource State

Cluster Resource Groups

Attributes: Name, Node Name, Suspended, Resource Group State

Relationships: Cluster Resources

Cluster Switches

Attributes: Name, Type, State

Relationships: Cluster Switch Ports

Cluster Switch Ports

Attributes: Name, Port State

Cluster Transport Paths

Attributes: Endpoint #1, Endpoint #2, Transport Path Status

Performance Monitoring

The following metrics will be collected every 5 minutes by default.

Cluster (Device)

Nodes: Offline Nodes, Online Nodes, Total Nodes (count)

Quorum: Votes Needed, Votes Possible, Votes Present (count)

Cluster Node Device Discovery

You can optionally configure each Solaris Cluster server to attempt to discover
and monitor the guest operating systems running within each Solaris Cluster node.
This requires that your Zenoss system has the network and server
access it needs to monitor the guest system.

Configure Cluster Node Device Discovery

Navigate to the Configuration Properties panel.

Checkmark zNodesAutodiscover to set it to true.

Service Impact

When combined with the Zenoss Service Dynamics product, this ZenPack adds
built-in service impact capability for Solaris. The following service
impact relationships are automatically added. These will be included in
any services that contain one or more of the explicitly mentioned entities.

Usage

Depending on the version of Solaris you may be able to monitor the server using
either SSH or SNMP. For OpenSolaris and Solaris 10, you can choose to use
either SSH or SNMP monitoring. For Solaris 9, only SSH monitoring is supported.

Configure SSH Monitoring

Use the following steps to configure Zenoss to monitor your Solaris server(s)
using SSH.

Verify that your Solaris server(s) SNMP community strings are listed in the zSnmpCommunities property.

Add your Solaris server(s) to the /Server/Solaris device class.

Configure LDOM Monitoring

For OpenSolaris and Solaris 10 servers you will also get support for monitoring
LDOMs if they're used on the server. However, this monitoring is always
performed using SNMP. If you're already monitoring your Solaris server using
SNMP there is no additional configuration required to monitor its LDOMs. If you
configured Zenoss to monitor your Solaris server using SSH you should take the
following steps to monitor LDOMs.

Verify that your Solaris server(s) SNMP community strings are listed in the zSnmpCommunities property.

Navigate to the Modeler Plugins panel and enable zenoss.snmp.solaris.ldommap plugin.

Remodel your Solaris server(s) if they're already in the system. Otherwise add them to the /Server/SSH/Solaris device class.

Configure Cluster Monitoring

This ZenPack also provides support for monitoring Solaris Cluster, however, this monitoring is always performed using SSH.
Use the following steps to configure Zenoss to monitor your Solaris Cluster server(s).

Troubleshooting

Please refer to the Zenoss Service Dynamics documentation if you run into
any of the following problems:

ZenPack will not install

Adding a device fails

Don't understand how to add a device

Don't understand how to model a device

If you cannot find the answer in the documentation, then Resource Manager (Service Dynamics)
users should contact Zenoss Customer Support.
Core users can use the #zenoss IRC channel or the community.zenoss.org forums.

Resolving CHANNEL_OPEN_FAILURE Issues

The zencommand daemon's log file ($ZENHOME/collector/zencommand.log) may
show messages stating:

If the sshd daemon's log file on the remote device is examined, it may report
that the MAX_SESSIONS number of connections has been exceeded and that it is
denying the connection request. In the OpenSSH daemons, this MAX_SESSIONS
number is a compile-time option and cannot be reset in a configuration file.

To work around this sshd daemon limitation, use the configuration property
zSshConcurrentSessions to control the number of connections created by
zencommand to the remote device:

Navigate to the device or device class in the Resource Manager interface.

If applying changes to a device class:

Select the class in the devices hierarchy.

Click Details.

Select Configuration Properties.

If applying changes to a device:

Click the device in the device list.

Select Configuration Properties.

Set the zSshConcurrentSessions property. Try 10 first, and 2 if that doesn't resolve the problem.

Resolving Command Timeout Issues

The zencommand daemon's log file ($ZENHOME/collector/zencommand.log) may show
messages stating:

If this occurs, it usually indicates that the remote device has taken too long
to return results from the commands. To increase the amount of time to allow
devices to return results, change the configuration property
zCommandCommandTimeout to a larger value.

Navigate to the device or device class in the Resource Manager interface.

If applying changes to a device class:

Select the class in the devices hierarchy.

Click Details.

Select Configuration Properties.

If applying changes to a device:

Click the device in the device list.

Select Configuration Properties.

Increase the zCommandCommandTimeout property incrementally to a maximum of 240 until the timeout is resolved.

Blank Fields in Analytics View

Having blank fields when creating Ad Hoc Views in Analytics server may
mean that your device have been monitored before Analytics support was
implemented for this ZenPack. To resolve this, you have to delete the
dimension tables for Solaris components in the reporting database on
the analytics server and restart the ZenETL daemons.

Known issues

This zenpack uses df utility to monitor filesystems capacity, and this utility could give misleading results for ZFS. When there are more then one filesystems in the same disk pool, the used plus free space for them will be less than total space, because some of it will be used for other filesystem. See: Oracle Solaris ZFS and Traditional File System Differences.

Zenoss Analytics

This ZenPack provides additional support for Zenoss Analytics. Perform the
following steps to install extra reporting resources into Zenoss Analytics
after installing the ZenPack.