Modified items

All recently modified items, latest first.

ZenPacks.lbn.APCUPS-4.2.5_4.0.1-1.lbn19.noarch: Modeler plugins are: ApcUpsDeviceMap Gathers Hardware and Software manufacturer and product Serial number Total number of battery packs Number of bad battery packs Basic output status ApcUpsBatteryMap Gathers battery data for status Time on battery Battery last replacement date Battery replacement indicator Device template ApcUps provides device-level performance information: Data Sources Voltage Current Remaining capacity and time Temperature Thresholds Low capacity Low time remaining High temperature Graph Definitions Voltage Current Remaining capacity Remaining time Temperature Device template ApcUpsInsAndOuts provides specific input / output performance information: Data Sources Input frequency and voltage Output frequency, voltage, load and current Thresholds High load Graph Definitions Input frequency and voltage Output frequency, voltage, load and current A separate APC UPS Information menu delivers tabular and graphical information for the overall device

ZenPacks.community.zenMongoDB-4.2.5_1.1-1.lbn19.noarch: Monitoring for MongoDB (component)

ZenPacks.community.zenJavaApp-4.2.5_2.1-1.lbn19.noarch: This zenpack allows a modified version of the standard JMX template to work for multiple JVMs running on the same device. Each JMX-capable application is detected by a modeler plugin that checks responsive ports from a given list of potential ports. Components: The ZenPack has the following Objects JavaApp Template provides a component-level modified version of the standard "Java" template that ships with zenJMX ZenPack. The ZenPack also provides: A modeler plugin JavaAppMap that models available JMX-capable servers A new zProperty zJavaAppPorts that contains a list of port numbers to be scanned by the modeler plugin A CLI-based jmx agent used by the modeling process

ZenPacks.community.puppet-4.2.5_1.21-1.lbn19.noarch: This ZenPack provides support for the following in Puppet (via ssh) Report and listing of puppet clients for each master on a separate tab Report of all puppet clients in a PuppetClientList report Tracking of update times of clients Device addition from puppet via events The ZenPack provides a device class /Server/PuppetMaster, with a collector plugin PuppetModeler.

ZenPacks.community.libvirt-4.2.5_1.97-1.lbn19.noarch: This ZenPack leverages the libvirt API for monitoring virtualization servers (e.g. XEN, KVM, etc...). This uses the system python and libvirt python API to monitor various virtualization platforms remotely. It provides a /Server/libvirtHost device class and this module is tested using ssh as a transport for the libvirt API, it could be made to use TLS or TCP with further development. It provides a libvirtvirtualHostlist report as well. You can set zLibvirtUsername and zLibvirtConnectType to customize access to the hosts, though only qemu+ssh:// was tested at the moment. libvirt supports: * The Xen hypervisor on Linux and Solaris hosts. * The QEMU emulator * The KVM Linux hypervisor * The LXC Linux container system * The OpenVZ Linux container system * The User Mode Linux paravirtualized kernel * The VirtualBox hypervisor * The VMware ESX and GSX hypervisors * Storage on IDE/SCSI/USB disks, FibreChannel, LVM, iSCSI, NFS and filesystems

ZenPacks.community.f5-4.2.5_1.7-1.lbn19.noarch: The ZenPack has the following: /Network/f5 Device Class A Device template which graphs many of the same performance stats as would be seen in the Overview >> Performance section of the 10.x UI Virtual Server Component Modeling A component template for virtual servers. Virtual Server filtering. This pack adds a new zProperty, zF5BigipVirtualServerNameFilter, which when set will limit which virtual servers are included during a modeling cycle. Node Component Modeling A component template for nodes. Node filtering. This pack adds a new zProperty, zF5BigipNodesNameFilter, which when set will limit which nodes are included during a modeling cycle. Pool Component Modeling A component template for Pools. Pool filtering. This pack adds a new zProperty, zF5BigipPoolsNameFilter, which when set will limit which pools are included during a modeling cycle.

ZenPacks.community.deviceAdvDetail-5.0.5_2.9.0-1.lbn19.noarch: This ZenPack is extends Zenoss with possibility to display additional hardware details and could be used by other ZenPacks as well. Examples of details include: dynamic deviceHardwareDetail tab dynamic deviceOsDetail tab dynamic deviceSoftwareDetail tab Number of CPU Cores Memory Modules section Logical Drives sections status indication for all hardware components It also make changes deviceOSDetail tab to show only monitored Network Interfaces Usage Installing the ZenPack will add the following items to your Zenoss system. Event Class /Change/Set/Status Threshold Class StatusThreshold

ZenPacks.community.Varnish3-4.2.5_1.2-1.lbn19.noarch: A ZenPack to provide support for Varnish version 3.x metrics. It introduces a new command parser that is intended to be run over SSH. Metrics are parsed from the output of the varnishstat command on the Varnish 3.x server

ZenPacks.community.VMwareESXiMonitor-4.2.5_2.0.1-1.lbn19.noarch: DESCRIPTION: This ZenPack allows Zenoss to monitor VMware ESXi Hosts and VMs via the vSphere SDK for Perl. It creates the /Server/VMware/ESXi Device Class. All ESXi Hosts have to be added to this Device Class. INSTALLATION: First install the vSphere SDK for Perl on your Zenoss Collector Server. After that you can install the ZenPack as usually and restart Zenoss. ZPROPERTIES: The ZenPack will add two zProperties: zVSphereUsername: Name of a User that has read-only access to the ESXi Host zVSpherePassword: The corresponding Password

ZenPacks.community.SuSE-4.2.5_1.1-1.lbn19.noarch: This SSH-based ZenPack extends the Linux Monitor and Linux Monitor AddOn ZenPacks to provide additional functionality for SuSE Linux, specifically OS Make and Software inventory.

ZenPacks.community.Splunk-4.2.5_1.1.1-2.lbn19.noarch: This ZenPack allows Splunk alerts to be sent to Zenoss as alerts; escalation can then be handled with Zenoss alerts.

ZenPacks.community.SQLDataSource-4.2.5_1.99-2.lbn19.noarch: This Functionality ZenPack provides a new zenperfsql daemon and SQL data source. It based on Twisted twisted.enterprise.adbapi interface to the standardized DB-API 2.0 API, which allows you to access a number of different RDBMSes.

ZenPacks.community.ResponsiveUI-4.2.5_2.0.5-1.lbn19.noarch: Make life of mobile Zenoss users a bit easier by adding light user interface to access Infrastructure, Device details, Components and Events console. ZenPack also extends Zenoss with settings for User Interface colors and full-screen mode. Mobile User Interface When accessing Zenoss from your mobile device (phone, tablet) it will show lite pages for: Login page Add a Single Device Infrastructure Events console Device overview Device components Device events This can be turn ON/OFF on User Interface settings page in Zenoss. Tune Zenoss colors for your own Zenpack brings a color settings to Zenoss: navigation bar menu sidebar panel table rows Zen mode ON A small button in the footer to hide sidebar and navigation. Cool for small screens.

ZenPacks.community.RDBMS-4.2.5_2.5-1.lbn19.noarch: This ZenPack provides basic "Database" and "DBSrvInst" component class.

ZenPacks.community.PagerDuty-4.2.5_1.0.0-2.lbn19.noarch: DESCRIPTION: This ZenPack is designed to facilitate a tight integration between Zenoss (www.zenoss.com) and Pagerduty (www.pagerduty.com). It provides the following capabilities: 1. A script designed to be run by Zenoss "Event Commands" (3.x) or "Notifications" (4.x) that creates Pagerduty incidents for specific Zenoss events. a. incident is created for Pagerduty service by specifying the service key as a runtime argument. b. if Pagerduty service is in maintenance, the Zenoss event will be acknowledged and updated with a relevant message c. if Pagerduty service is disabled, the Zenoss event will be left unacknowledged, but updated with a relevant message 2. A Zenoss daemon that runs periodically and synchronizes Zenoss event/Pagerduty incidents. The daemon: a. determines which side (Zenoss or Pagerduty) was most recently updated. b. changes the status of the non-authoritative event/incident to match the authoritative one c. copies/formats Pagerduty incident logs for view within the Zenoss event console details. This ZenPack uses the web service APIs of both Zenoss and PagerDuty. CREATING PAGERDUTY INCIDENTS: Since Pagerduty uses a key to identify the "Services" that notifications should be assigned to, the idea is to create a default service key event attribute (via transform) that Zenoss will use when creating Pagerduty Incidents. The default service key can then be overwritten by other event transforms according to the administrator's needs. For example, the following event transform might be applied at the root of the event class hierarchy. This transform determines whether a given device is a Windows or Unix device, and assigns the appropriate service key accordingly: unixServiceKey = 'UNIXKEY' # Unix Team windowsServiceKey = 'WINDOWSKEY' # Windows Team defaultServiceKey = 'DEFAULTKEY' # Default Team try: devClass = device.deviceClass().getOrganizerName() # string representing device class organizer if 'Linux' in devClass: evt.pdServiceKey = unixServiceKey elif 'AIX' in devClass: evt.pdServiceKey = unixServiceKey elif 'WMI' in devClass: evt.pdServiceKey = windowsServiceKey elif 'Windows' in devClass: evt.pdServiceKey = windowsServiceKey else: evt.pdServiceKey = device.zPDServiceKey except: # set to default if nothing found evt.pdServiceKey = defaultServiceKey This initial transform can then be overridden later by other event transforms depending on the event class (or whatever the administrator designs). Once the event has a corresponsing service key assigned, it can be passed as a parameter to an "Event Command" (Zenoss 3.x) or "Notification" (Zenoss 4.x) such as: python zenpagerduty.py -a create -z ${dev/zPDZenossServer} -u ${dev/zPDZenossUser} -p ${dev/zPDZenossPass} -H ${dev/zPDDomain} -T ${dev/zPDToken} -U ${dev/zPDUser} -e ${evt/evid} -S ${evt/pdServiceKey} which creates the Pagerduty Incident with the provided arguments. SYNCHRONIZING SERVICE: This ZenPack provides a service daemon called "zenpdsync" which periodically (default 60 seconds) pulls the last N ('eventsBuffer' option default 20) events from both Zenoss and Pagerduty. It correlates these into pairs and determines which was last updated. If the status of one of the pair differs from the other, then the most recently updated one's status is copied to the other. Relevant Pagerduty incident log details are also copied to the Zenoss console. ZPROPERTIES PROVIDED: zPDZenossServer: hostname of zenoss server zPDZenossUser: zenoss user allowed to query events zPDZenossPass: password for zenoss user zPDDomain: YOURNAMEHERE.pagerduty.com zPDToken: Token key needed for API calls zPDUser: Pagerduty user used for automatic updates (this will show in the console, I use a fake user called "Zenoss") zPDServiceKey: optional per-device service key (would need to be assigned in transform if used, however) COMPONENTS: The ZenPack has the following objects: An example notification (Zenoss 4.x) An example event command (Zenoss 3.x) INSTALLATION: It is recommended to run the "zenpdsync" from only one hub or collector, since the process does not need to be run multiple times for a single Zenoss installation. This means disabling the "zenpdsync" daemon on all but one of the hub/collectors. Be sure also to set defaults for the zProperties, as well as creating an event transform under the root class similar to the sample above. The bare minimum event transform would be: try: evt.pdServiceKey = device.zPDServiceKey except: evt.pdServiceKey = 'YOURSERVICEKEY' A transform has not been provided, as the author has encountered complications in the past related to event classes (they get removed if the Zenpack is uninstalled).

ZenPacks.community.OracleMon-4.2.5_1.2-1.lbn19.noarch: This Monitoring ZenPack provides Oracle Database monitoring. There is a community.sql.OracleDatabaseMap zCollectorPlugin that the device will need to use.

ZenPacks.community.OpenTSDB-4.2.5_1.0.0-1.lbn19.noarch: Publish Zenoss RRD data to OpenTSDB

ZenPacks.community.LinuxMonitorAddOn-4.2.5_1.0-1.lbn19.noarch: This SSH-based ZenPack supplements the Linux Monitor ZenPack and provides perf monitoring for Interfaces and adds routing and memory as well.

ZenPacks.community.Jenkins-4.2.5_1.0-2.lbn19.noarch: ZenPack for Jenkins build monitoring

ZenPacks.community.HPUXMonitor-4.2.5_2.2-2.lbn19.noarch: HPUX SNMP-based monitoring/coordination

« Previous 20 items Next 20 items » 1 ... 1785 1786 1787 1788 1789 1790 1791 ... 2355


	Copyright © 2000-2024 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items