Search results for zenoss

ZenPacks.zenoss.PythonCollector-5.0.5_1.8.0dev-4.lbn19.noarch

This ZenPack provides a new Python data source type. It also provides a new zenpython collector daemon that is responsible for collecting these data sources. The goal of the Python data source type is to replicate some of the standard COMMAND data source type's functionality without requiring a new shell and shell subprocess to be spawned each time the data source is collected. The COMMAND data source type is infinitely flexible, but because of the shell and subprocess spawning, it's performance and ability to pass data into the collection script are limited. The Python data source type circumvents the need to spawn subprocesses by forcing the collection code to be asynchronous using the Twisted library. It circumvents the problem with passing data into the collection logic by being able to pass any basic Python data type without the need to worry about shell escaping issues. The Python data source type is intended to be used in one of two ways. The first way is directly through the creation of Python data sources through the web interface or in a ZenPack. When used in this way, it is the responsibility of the data source creator to implement the required Python class specified in the data source's Python Class Name property field. The second way the Python data source can be used is as a base class for another data source type. Used in this way, the ZenPack author will create a subclass of PythonDataSource to provide a higher-level functionality to the user. The user is then not responsible for writing a Python class to collect and process data.

ZenPacks.zenoss.RabbitMQ-5.0.5_1.1.0dev-3.lbn19.noarch

To start monitoring your RabbitMQ server you will need to setup SSH access so that your Zenoss collector server will be able to SSH into your RabbitMQ server(s) as a user who has permission to run the rabbitmqctl command. This almost always means the root user. See the Using a Non-Root User section below for instructions on allowing non-root users to run rabbitmqctl. To do this you need to set the following zProperties for the RabbitMQ devices or their device class in Zenoss. * zCommandUsername * zCommandPassword * zKeyPath The zCommandUsername property must be set. To use public key authentication you must verify that the public portion of the key referenced in zKeyPath is installed in the ~/.ssh/authorized_keys file for the appropriate user on the RabbitMQ server. If this key has a passphrase you should set it in the zCommandPassword property. If you'd rather use password authentication than setup keys, simply put the user's password in the zCommandPassword property. You should then add the zenoss.ssh.RabbitMQ modeler plugin to the device, or device class containing your RabbitMQ servers and remodel the device(s). This will automatically find the node, vhosts, exchanges and queues and begin monitoring them immediately for the following metrics. * Node Values o Status - Running or not? Generates event on failure. o Open Connections & Channels o Sent & Received Bytes Rate o Sent & Received Messages Rate o Depth of Send Queue o Consumers o Unacknowledged & Uncommitted Messages * Queue Values o Ready, Unacknowledged & Total Messages o Memory Usage o Consumers There is a default threshold of 1,000,000 messages per queue. This is almost certainly an absurdly high threshold that shouldn't trip in normal systems. However, by clicking into the details of any individual queue you can set the per-queue threshold to a more reasonable value that makes sense for a given queue.

ZenPacks.zenoss.WindowsMonitor-5.0.5_1.1.2dev-4.lbn19.noarch

This package provides the capability to monitor windows systems. The following daemons perform Windows monitoring tasks: zenwin - monitors Windows service processes zeneventlog - imports events from the Windows Event Log into Zenoss zenwinperf - collects performance information from Windows machines

ZenPacks.zenoss.XenMonitor-5.0.5_1.1.0-1.lbn19.noarch

Xen Monitor --------------------------- XenMonitor is a ZenPack that allows you to monitor virtually hosted operating systems running on a Xen hypervisor. It depends on the prior installation of the ZenossVirtualHostMonitor zenpack. This zenpack: 1) Extends ZenModeler to find Guest OS's and add them to Virtual Hosts 3) Provides templates for collecting resources allocated to Guest OSs. To Use XenMonitor: 1) Ensure that you have SSH keys to your Xen servers (as root). 2) Create your Xen servers using the /Servers/Virtual Hosts/Xen device class. If you have these servers modeled already, remove them and recreate them under the Xen device class. DO NOT MOVE THEM. 3) Select the Guest menu and ensure that the guest hosts were found when the devices were added.

ZenPacks.zenoss.ZenJMX-5.0.5_3.12.0dev-2.lbn19.noarch

ZenJMX is a full-featured JMX client that works "out of the box" with JMX agents that have their remote APIs enabled. It supports authenticated and unauthenticated connections, and it can retrieve single-value attributes, complex-value attributes, and the results of invoking an operation. Operations with parameters are also supported so long as the parameters are primitive types (Strings, booleans, numbers), as well as the object version of primitives (such as java.lang.Integer and java.lang.Float). Multi-value responses from operations (Maps and Lists) are supported, as are primitive responses from operations. The JMX data source installed by ZenJMX allows you to define the connection, authentication, and retrieval information you want to use to retrieve performance information. The IP address is extracted from the parent device, but the port number of the JMX Agent is configurable in each data source. This allows you to operate multiple JMX Agents on a single device and retrieve performance information for each agent separately. This is commonly used on production servers that run multiple applications. Authentication information is also associated with each JMX data source. This offers the most flexibility for site administrators because they can run some JMX agents in an open, unauthenticated fashion and others in a hardened and authenticated fashion. SSL-wrapped connections are supported by the underlying JMX Remote subsystem built into the JDK, but were not tested in the Zenoss labs. As a result, your success with SSL encrypted access to JMX Agents may vary. The data source allows you to define the type of performance information you want to achieve: single-value attribute, complex-value attribute, or operation invocation. To specify the type of retrieval, you must specify an attribute name (and one or more data points) or provide operation information. Any numerical value returned by a JMX agent can be retrieved by Zenoss and graphed and checked against thresholds. Non-numerical values (Strings and complex types) cannot be retrieved and stored by Zenoss. When setting up data points, make sure you understand the semantics of the attribute name and choose the correct Zenoss data point type. Many JMX Agent implementations use inconsistent nomenclature when describing attributes. In some cases the term "Count" refers to an ever-increasing number (a "Counter" data point type). In other cases the term "Count" refers to a snapshot number (a "Gauge" data point type).

zenoss-build-5.0.5-1.1.lbn19.noarch

RPM build macros

zenoss-metric.consumer-5.0.4-1.1.lbn19.noarch

Consume and report metrics

zenoss-metric.consumer-javadoc-5.0.4-1.1.lbn19.noarch

API documentation for zenoss-metric.consumer.

zenoss-parent-5.0.5-1.1.lbn19.noarch

Parent POM file for Zenoss Specs.