Modified items

All recently modified items, latest first.

ZenPacks.community.PrinterToner-4.2.5_1.40.4-1.lbn19.noarch: Printers that have been tested are HP, Brother, Canon and Xerox. The results vary and there is 100% support for HP and Brother printers and only 80% success on Canon and Xerox printers. You will need to associate the community.snmp.PrinterTonerMap with the /Printers/Laser under zCollectorPlugins. A new tab is added to the Device details for printers - called Printer Toner. Under this new tab, the details per cartridge may be obtained. Perf data is calculated as a percentage and alerts can be set of these values.

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

ZenPacks.community.HPMon-4.2.5_2.3.0-1.lbn19.noarch: zProperties zHPExpansionCardMapIgnorePci - ignore PCI cards other than RAID and iLO controllers Modeler Plugins community.snmp.HPCPUMap - CPU modeler plugin community.snmp.HPDaCntlrMap - modeler plugin for HP Smart Array controllers community.snmp.HPDaLogDrvMap - modeler plugin for Logical Disks on HP Smart Array controllers community.snmp.HPDaPhyDrvMap - modeler plugin for Physical Disks on HP Smart Array controllers community.snmp.HPDeviceMap - device modeler plugin, tried to identify Model, Vendor and Serial Number community.snmp.HPExpansionCardMap - PCI cards modeler plugin, tried to identify all PCI cards, RAID and iLO controllers, put it to the end of *Collector Plugins* list community.snmp.HPFanMap - Fan modeler plugin community.snmp.HPFcTapeCntlrMap - modeler plugin for FC Tape controllers community.snmp.HPFcaCntlrMap - modeler plugin for HP StorageWorks Modular Smart Array controllers community.snmp.HPFcaLogDrvMap - modeler plugin for Logical Disks on HP StorageWorks Modular Smart Array controllers community.snmp.HPFcaPhyDrvMap - modeler plugin for Physical Disks on HP StorageWorks Modular Smart Array controllers community.snmp.HPHardDiskMap - Hard Disks modeler plugin returned to zenmodeler information collected by other Physical Disk modeler plugins, so put it in Collector Plugins list after all Physical Disk modeler plugins. community.snmp.HPIdeAtaDiskMap - modeler plugin for IDE/ATA Physical Disks community.snmp.HPIdeControllerMap - modeler plugin for IDE/ATA controllers community.snmp.HPIdeLogicalDriveMap - modeler plugin for Logical Disks on IDE/ATA controllers community.snmp.HPLogicalDiskMap - Logical Disks modeler plugin returned to zenmodeler information collected by other Logical Disk modeler plugins, so put it in Collector Plugins list after all Logical Disk modeler plugins. community.snmp.HPMemoryModuleMap - Physical Memory modeler plugin, tried to identify memory modules community.snmp.HPNicMap - Network Cards modeler plugin community.snmp.HPPowerSupplyMap - Power Supply modeler plugin community.snmp.HPSasHbaMap - modeler plugin for SAS controllers community.snmp.HPSasLogDrvMap - modeler plugin for Logical Disks on SAS controllers community.snmp.HPSasPhyDrvMap - modeler plugin for Physical Disks on SAS controllers community.snmp.HPScsiCntlrMap - modeler plugin for SCSI controllers community.snmp.HPScsiLogDrvMap - modeler plugin for Logical Disks on SCSI controllers community.snmp.HPScsiPhyDrvMap - modeler plugin for Physical Disks on SCSI controllers community.snmp.HPSm2CntlrMap - modeler plugin for iLO Management controllers community.snmp.HPSsChassisMap - External Chassis modeler plugin community.snmp.HPTemperatureSensorMap - Temperature Sensor modeler plugin Monitoring Templates Devices/Server/rrdTemplates/HPFan Devices/Server/rrdTemplates/HPPowerSupply Devices/Server/rrdTemplates/HPTemperatureSensor Devices/Server/rrdTemplates/cpqDaCntlr Devices/Server/rrdTemplates/cpqDaCntlrPerf Devices/Server/rrdTemplates/cpqDaLogDrv Devices/Server/rrdTemplates/cpqDaLogDrvPerf Devices/Server/rrdTemplates/cpqDaPhyDrv Devices/Server/rrdTemplates/cpqFcaCntlr Devices/Server/rrdTemplates/cpqFcaHostCntlr Devices/Server/rrdTemplates/cpqFcaLogDrv Devices/Server/rrdTemplates/cpqFcaPhyDrv Devices/Server/rrdTemplates/cpqHeResMem2Module Devices/Server/rrdTemplates/cpqIdeAtaDisk Devices/Server/rrdTemplates/cpqIdeController Devices/Server/rrdTemplates/cpqIdeLogicalDrive Devices/Server/rrdTemplates/cpqNicIfPhysAdapter Devices/Server/rrdTemplates/cpqSasHba Devices/Server/rrdTemplates/cpqSasLogDrv Devices/Server/rrdTemplates/cpqSasPhyDrv Devices/Server/rrdTemplates/cpqScsiCntlr Devices/Server/rrdTemplates/cpqScsiLogDrv Devices/Server/rrdTemplates/cpqScsiPhyDrv Devices/Server/rrdTemplates/cpqSiMemModule Devices/Server/rrdTemplates/cpqSm2Cntlr Devices/Server/rrdTemplates/cpqSsChassis Reports Reports/Device Reports/HP ProLiant Reports/Hard Disks Reports/Device Reports/HP ProLiant Reports/Storage Controllers Reports/Device Reports/HP ProLiant Reports/iLO Boards MIBs CPQFCA-MIB CPQHLTH-MIB CPQIDA-MIB CPQIDE-MIB CPQNIC-MIB CPQSCSI-MIB CPQSM2-MIB

ZenPacks.community.Fortigate-4.2.5_1.2.1-1.lbn19.noarch: Provides a /Network/Router/Firewall/Fortigate Device Class and a Fortigate template that can be \ bound to monitor CPU usage, Memory Utilization and Number of Sessions for a Fortigate Firewall.

ZenPacks.community.DistributedCollectors-4.2.5_2.0.1-1.lbn19.noarch: Description: This ZenPack provides UI for configuring multiple collectors with Zenoss Core. It implement remote collector configuration method described in How to install distributed collectors manual (http://community.zenoss.org/docs/DOC-2496). Adding Remote Collector 1. install DistributedCollectors ZenPack on master server 2. install Zenoss on remote collector without any ZenPacks 3. configure "ssh public key authentication" on remote collector for user 'zenoss' 4. in "Collectors" -> select menu item "Add Remote Monitor..." and enter name or ip address of remote collector Updating Remote Collectors (after zenpacks install or remove) 1. in "Collectors" select all remote collectors you want update. 2. in "Collectors" -> select menu item "Update Remote Monitors..."

ZenPacks.community.DellMon-5.0.5_2.5.0-1.lbn19.noarch: Monitored Systems On monitored system, Dell OpenManage Agents must be installed and properly configured. Usage Installing the ZenPack will add the following items to your Zenoss system. zProperties zDellExpansionCardMapIgnorePci - ignore PCI cards other than RAID and DRAC controllers Modeler Plugins community.snmp.DellCPUMap - CPU modeler plugin community.snmp.DellDeviceMap - device modeler plugin, tried to identify Model, Vendor and Serial Number community.snmp.DellExpansionCardMap - PCI cards modeler plugin, tried to identify all PCI cards, RAID and DRAC controllers community.snmp.DellFanMap - Fan modeler plugin community.snmp.DellHardDiskMap - Hard Disks modeler plugin community.snmp.DellLogicalDiskMap - Logical Disks modeler plugin community.snmp.DellMemoryModuleMap - Physical Memory modeler plugin, tried to identify memory modules installed in server community.snmp.DellPowerSupplyMap - Power Supply modeler plugin community.snmp.DellTemperatureSensorMap - Temperature Sensor modeler plugin Monitoring Templates Devices/Server/rrdTemplates/DellDiscreteTemperatureSensor Devices/Server/rrdTemplates/DellExpansionCard Devices/Server/rrdTemplates/DellFan Devices/Server/rrdTemplates/DellHardDisk Devices/Server/rrdTemplates/DellLogicalDisk Devices/Server/rrdTemplates/DellMemoryModule Devices/Server/rrdTemplates/DellPowerSupply Devices/Server/rrdTemplates/DellPowerSupplyAP Devices/Server/rrdTemplates/DellPowerSupplyVP Devices/Server/rrdTemplates/DellStorageCntlr Devices/Server/rrdTemplates/DellTemperatureSensor Reports Reports/Device Reports/Dell PowerEdge Reports/DRAC Controllers Reports/Device Reports/Dell PowerEdge Reports/Storage Controllers Reports/Device Reports/Dell PowerEdge Reports/Hard Disks MIBs MIB-Dell-10892 ArrayManager-MIB

ZenPacks.community.ConstructionKit-4.2.5_2.5-1.lbn19.noarch: This ZenPacks automates to a large extent the development of other ZenPacks. It eliminates the bulk of "boilerplate" code that accompanies the typical "custom component" type of zenpack while providing many nice features. The goal is to reduce the maintenance cost (development time) associated with dependent ZenPacks by removing most of their code. ConstructionKit-dependent ZenPacks should consist only of a Definition.py class file that subclasses the provided "BasicDefinition" class, as well as any additional ZenPack-specific files such as modeler plugins, check scripts, and exported Zenoss templates, event classes, etc (objects.xml).

ZenPacks.community.CiscoEnvMon-4.2.5_1.1-1.lbn19.noarch: Cisco Environmental monitoring including fans, temperature sensors, power supplies and expansion modules.

ZenPacks.community.BastionLinux-1.1-2.lbn19.noarch: This SSH-based ZenPack extends the Linux Monitor and Linux Monitor AddOn ZenPacks to provide additional functionality for Bastion/Fedora Linux, specifically OS Make and Software inventory.

ZenPacks.community-4.2.4-1.lbn19.noarch: ZenPacks.community python module

ZenPacks.chudler.GoogleAppEngine-4.2.5_1.0-1.lbn19.noarch: With this ZenPack you can monitor the status of your Google AppEngine applications. It provides: All Quota statistics (allowances, percent used, and raw used). Application status (version deployed) Monitoring of multiple google accounts Automatic detection of new quotas types Automatic detection of new applications and changes to existing applications

ZenPacks.atelepin.cbCiscoQOS-4.2.5_1.2-1.lbn19.noarch: Background ========== This project is a Zenoss extension (ZenPack) primarily intended for ISPs which extensively use different QoS on their network (like MPLS), and need to know statistics by each class. About Cisco Base QOS on Cisco site This is prerelease but all main functionality work. Almost think i need change or add write in the code as TODO or FIXME Overview ======== Because ServicePolicy bound to Interface (IpInterface), installation create additional relation between cbServicePolicy and IpInterface. ZenPack contain automated modeler which grab QOS Object configuration from device. From this configuration modeler create particular class instance and create hierarchy of that objects (see more about nested object in cisco site). In this release i collect only two statistic item PostPolicyBitRate and PostPolicyDropRate. From code point of view each statistic item is different component, but from user point of view, this item belong to cbServicePolicy and statistics should be visible as single item (for example on single graph). In this case cbServicePolicy work not only as container but also provide internal API to gather statistic from his child.

ZenPacks.ZenSystems.ApcUps-4.2.4_1.2-6.lbn19.noarch: The ZenPack has the following Device Class /Devices/Server/Windows Components are: ApcUpsBattery which has details for: Various elements of battery status 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.TwoNMS.PrinterMIB-4.2.5_2.0.0-2.lbn19.noarch: This ZenPack monitors printers supporting the new RFC3805 PrinterMIB (supersedes RFC1759). Version 2.0.0 creates separate components for toners, supplies and input trays. In case you don't see the Printer components then try deleting the printer + adding it directly to the /Printer/PrinterMIB tree.

ZenPacks.RomanTykhonov.OracleDB-4.2.5_2.0-2.lbn19.noarch: With SNMP Trap destination setup in Oracle Enterprise Manager it is the best way to monitor many Oracle Single Instance/RACs for FREE. (if you have Oracle Standard Edition - Perfomance Tab have to be disabled due to Standard Edition Licence Agreement)

« Previous 20 items Next 20 items » 1 ... 1933 1934 1935 1936 1937 1938 1939 ... 2446


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

Sections

Modified items