Search results for zenoss

ZenPacks.lbn.CouchDB-4.2.5_4.0.1-3.lbn13.noarch

CouchDB is a ZenCommand monitor for remotely gathering CouchDB server statistics. The following metrics will be collected and graphed for the LDAP Server: * Database Statistics o Reads o Writes o Open Databases o Open File System Files o Request Time * Daemon Statistics o Bulk Requests o Requests o Temporary View Reads o View Reads * Operations o Copy o Delete o Get o Head o Move o Post o Put * HTTP Statuses (20x, 30x, 4xx, 500) You can add CouchDB monitoring to the device within Zenoss by simply binding the CouchDB template to the device. 1. Navigate to the device in the Zenoss web interface. 2. Click the device menu, choose More then Templates. 3. Click the templates menu, choose Bind Templates. 4. Ctrl-click the CouchDB template from /Devices/Server to choose it. 5. Click OK. You will now be collecting the CouchDB Server metrics from this device.

ZenPacks.lbn.LDAPMonitor-4.2.5_4.0.2-1.lbn13.noarch

LDAPMonitor ----------- LDAPMonitor provides a method for pulling performance metrics from any LDAP server which implements the cn=Monitor standard. The monitor works by directly querying the LDAP server using the configured user dn and password credentials. Make sure that your LDAP server is available from your Zenoss console, you've enabled cn=monitor on it, and that the user has sufficient permissions to perform a 'cn=snmp,cn=monitor' search. The following metrics will be collected and graphed for the LDAP Server: * Operations o Add Entry o Modify Entry o Delete Entry o Search Entry * Bindings o Anonymous o Simple Auth o Unauthorised * Errors o Bind Security o Security o Other Errors o Failures * Response Time * Referrals You can add LDAP monitoring to the device within Zenoss by simply binding the LDAPMonitor template to the device. 1. Navigate to the device in the Zenoss web interface. 2. Click the device menu, choose More then Templates. 3. Click the templates menu, choose Bind Templates. 4. Ctrl-click the LDAPMonitor template from /Devices/Server to choose it. 5. Click OK. You will now be collecting the LDAP Server metrics from this device.

ZenPacks.lbn.SquidMonitor-4.2.5_4.0.2-1.lbn13.noarch

his ZenPack monitors Squid Proxy server's using SNMP. The following MIB's are monitored: cacheClients 1.3.6.1.4.1.3495.1.3.2.1.15.0 cacheCurrentFileDescrCnt 1.3.6.1.4.1.3495.1.3.1.12.0 cacheCurrentFileDescrMax 1.3.6.1.4.1.3495.1.3.1.13.0 cacheCurrentResFileDescrCnt 1.3.6.1.4.1.3495.1.3.1.11.0 cacheCurrentUnusedFDescrCnt 1.3.6.1.4.1.3495.1.3.1.10.0 cacheDnsSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.8.5 cacheHttpAllSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.2.5 cacheHttpErrors 1.3.6.1.4.1.3495.1.3.2.1.3.0 cacheHttpHitSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.5.5 cacheHttpHits 1.3.6.1.4.1.3495.1.3.2.1.2.0 cacheHttpInKb 1.3.6.1.4.1.3495.1.3.2.1.4.0 cacheHttpMissSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.3.5 cacheHttpNhSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.11.5 cacheHttpNmSvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.4.5 cacheHttpOutKb 1.3.6.1.4.1.3495.1.3.2.1.5.0 cacheIcpQuerySvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.6.5 cacheIcpReplySvcTime.5 1.3.6.1.4.1.3495.1.3.2.2.1.7.5 cacheNumObjCount 1.3.6.1.4.1.3495.1.3.1.7.0 cacheProtoClientHttpRequests 1.3.6.1.4.1.3495.1.3.2.1.1.0' cacheRequestByteRatio.1 1.3.6.1.4.1.3495.1.3.2.2.1.10.1 cacheRequestByteRatio.5 1.3.6.1.4.1.3495.1.3.2.2.1.10.5 cacheRequestByteRatio.60 1.3.6.1.4.1.3495.1.3.2.2.1.10.60 cacheRequestHitRatio.1 1.3.6.1.4.1.3495.1.3.2.2.1.9.1 cacheRequestHitRatio.5 1.3.6.1.4.1.3495.1.3.2.2.1.9.5 cacheRequestHitRatio.60 1.3.6.1.4.1.3495.1.3.2.2.1.9.60 cacheSysPageFaults 1.3.6.1.4.1.3495.1.3.1.1.0 cacheSysStorage 1.3.6.1.4.1.3495.1.1.2.0 cacheSysVMsize 1.3.6.1.4.1.3495.1.1.1.0 cacheUptime 1.3.6.1.4.1.3495.1.1.3.0 A full list of possible MIB's to extend your monitoring is available at http://wiki.squid-cache.org/Features/Snmp To use this zenpack, you'll need to enable snmpd in squid.conf: acl snmppublic snmp_community mysecretcommunity snmp_port 3401 snmp_access allow snmppublic all and proxy these through your hosts snmpd.conf: view systemview included .1.3.6.1.4.1.3495.1 proxy -m /usr/share/snmp/mibs/SQUID-MIB.txt -v2c -Cc -c mysecretcommunity localhost:3401 .1.3.6.1.4.1.3495.1

ZenPacks.lbn.ZopeMonitor-4.2.5_4.0.4-1.lbn13.noarch

ZopeMonitor ------------- ZopeMonitor provides a method for pulling performance metrics from a Zope Application Server (http://www.zope.org/) directly into Zenoss. It is necessary to first install the munin.zope eggs from pypi.python.org or our own repo at http://linux.last-bastion.net/LBN/up2date/monitor, and to have wget installed on this server. The monitor works by utilising ZenCommand to run wget on the local system - you do not need to make zope ports available through your firewall. The munin plugins do require a user with 'View Management Screens' access at the root however. This is configured using the zZopeURI zProperty of the device. This parameter uses Extended HTTP Authentication to specify user credentials, host and port. Note that the host is the hostname on the remote instance and should probably remain 'localhost' unless you've explicitly bound your Zope to a NIC. Note that the munin plugins expect to be installed on a Unix-like operating system with a /proc filesystem. The following metrics will be collected and graphed for the Zope Server. * Threads (only if you set up munin.zope on target - see code) o Free threads o Total threads * Cache o Total objects o Total objects in memory o Targe number * ZODB Activity o Total connections o Total load count o Total store count * Memory Utilisation o VmHWM - peak resident set size ("high water mark") o VmExe - size of text segments o VmStk - size of stack segments o VmPeak - peak virtual memory size o VmData - size of data segments o VmLck - locked memory size o VmPTE - page table entries size o VmLib - shared library code size o VmRSS - resident set size Once your Zope Server has the munin plugins installed, you can add Zope monitoring to the device within Zenoss by simply binding the ZopeMonitor template to the device. 1. Navigate to the device in the Zenoss web interface. 2. Click the device menu, choose More then Templates. 3. Click the templates menu, choose Bind Templates. 4. Ctrl-click the ZopeMonitor template from /Devices/Server to choose it. 5. Click OK. You will now be collecting the Zope Server metrics from this device.

ZenPacks.oie.KannelMonitor-4.2.5_3.0.0-3.lbn13.noarch

KannelMonitor ------------- KannelMonitor uses the nagios check-kannel plugin to retrieve input queue and delivery volumes from any Kannel-based SMPP server. Once your Kannel Server has the check-kannel plugin installed, you can add Kannel monitoring to the device within Zenoss by simply binding the KannelMonitor template to the device. 1. Navigate to the device in the Zenoss web interface. 2. Click the device menu, choose More then Templates. 3. Click the templates menu, choose Bind Templates. 4. Ctrl-click the KannelMonitor template from /Devices/Server to choose it. 5. Click OK. You will now be collecting the Kannel Server metrics from this device.

ZenPacks.rhybudd.alerts-4.2.5_1.0.0-2.lbn13.noarch

This ZenPack adds new event notification actions that are used by the zenactiond daemon to instantly deliver alerts to any Rhybudd enabled Android devices. Features The following event notification actions have been added: Send Alert to Rhybudd This action allows Zenoss to push events directly to Android devices that have the Rhybudd App installed. Alert delivery is usually sub-second. Rhybudd is free, open source and available from http://bit.ly/ZenossAndroid Limitations These notification actions are not able to provide immediate feedback as to whether or not configuration information is correct, so the zenactiond.log file must be checked to ensure that the actions are working correctly. Rhybudd must be installed to your phone or tablet and the steps detailed in the usage section below must be followed. Usage Phone / Tablet: New Install: Install the Rhybudd app to your phone. Configure the Zenoss server details (URL, username & password) Tap the Configure Rhybudd Push Tab Confirm all tests pass [Optional] Add an event filter (see below for server side configuration of filters) Existing Install upgraded to Rhybudd 4.0 Load up the app Tap the Home / Drawer menu icon Choose Configure Rhybudd Push Confirm all tests pass [Optional] Add an event filter (see below for server side configuration of filters) Zenoss: Basic Configuration: Navigate to Events -> Triggers page. Click on the Notifications menu item. Click on the plus sign ('+') to add a new notification. From the dialog box, specify the name of the notification and select the Send Alert to Rhybudd action. Enable the notification and add a trigger to be associated with this action. Configuring Filters: Follow steps 1 - 4 of Basic Configuration Click on the Contents tab. Input a "Filter Key" Click on the Submit button. On your Android device tap the Home / Drawer menu icon Choose Configure Rhybudd Push Confirm all tests pass Add the Filter key from Step 3 into the edit box. Tap Back or the Home button on the ActionBar Advanced Configuration: To prevent your alerts traversing the ColdStart.io infrastructure and instead have them go straight to your phone (via Google GCM) do the following; Login to Zenoss and navigate to Advanced Select Rhybudd Push from the left hand menu Follow the instructions from Google to create a GCM key http://developer.android.com/google/gcm/gs.html Add the GCM API Key and Sender ID to the page, press submit On your phone load the app, tap the Home icon, choose Configure Rhybudd Push, tap the refresh icon on the action bar. (This will update the local Sender ID and change the GCM Registration ID if neccessary)

ZenPacks.zenoss.AWS-4.2.5_2.2.2dev-1.lbn13.noarch

This ZenPack provides support for monitoring Amazon Web Services (AWS). Monitoring for the following EC2 entities is provided through a combination of the AWS EC2 and CloudWatch APIs. Features The features added by this ZenPack can be summarized as follows. They are each detailed further below. Discovery of EC2 entities. Monitoring of CloudWatch metrics. Optional auto-discovery and monitoring of instance guest operating systems. Optional service impact with addition of Zenoss Service Dynamic product. Discovery The following entities will be automatically discovered through an account name, access key and secret key you provide. The attributes, tags and collections will be updated on Zenoss' normal remodeling interval which defaults to every 12 hours. Regions Attributes: ID Collections: VPCs, Subnets, Zones, Instances, Volumes Zones Attributes: ID, Region, State Collections: Instances, Volumes, Subnets VPCs Attributes: ID, Region, CIDR Block Tags: Name, Collector Collections: Subnets, Instances Subnets Attributes: ID, Region, VPC, Zone, State, CIDR Block, Available IP Address Count, Zone Default, Auto-Public IP Tags: Name Collections: Instances Instances Attributes: ID, Region, VPC, Zone, Subnet, State, Instance Type, Image ID, Platform, Public DNS Name, Private IP Address, Launch Time, Guest Device Tags: Name Collections: Volumes Other: Guest Device (if monitored by Zenoss) Volumes Attributes: ID, Region, Zone, Instance, Type Created Time, Size, IOPS, Status, Attach Data Status, Attach Data Device Tags: Name Monitoring The following metrics will be collected every 5 minutes by default. Any other CloudWatch metrics can also be collected by adding them to the appropriate monitoring template. The Average statistic is collected, and the graphed value is per second for anything that resembles a rate. Regions Metrics: CPUUtilization, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes, NetworkIn, NetworkOut Instances Metrics: CPUUtilization, DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes, NetworkIn, NetworkOut, StatusCheckFailed_Instance, StatusCheckFailed_System Volumes Metrics: VolumeReadBytes, VolumeWriteBytes, VolumeReadOps, VolumeWriteOps, VolumeTotalReadTime, VolumeTotalWriteTime, VolumeIdleTime, VolumeQueueLength Provisioned IOPS Metrics: VolumeThroughputPercentage, VolumeReadWriteOps The Amazon CloudWatch datasource type also allows for the collection of any other CloudWatch metric. Guest Device Discovery You can optionally configure each monitored AWS account to attempt to discover and monitor the guest Linux or Windows operating systems running within each EC2 instance. This requires that your Zenoss system has the network and server access it needs to monitor the guest operating system. VPC and non-VPC modes are supported. The guest operating system devices' life-cycle are managed along with the instance. For example, the guest operating system device is set to a decommissioned production state when the EC2 instance is stopped, and the guest operating system device is deleted when the EC2 instance is destroyed. Service Impact When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact capability for services running on AWS. 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. Service Impact Relationships Account access failure impacts all regions. Region failure affects all VPCs and zones in affected region. VPC failure affects all related subnets. Zone failure affects all related subnets, instances and volumes. Subnet failure affects all instances on affected subnet. Volume failure affects any attached instance. Instance failure affects the guest operating system device. Usage Adding AWS Accounts Use the following steps to start monitoring EC2 using the Zenoss web interface. Navigate to the Infrastructure page. Choose Add EC2 Account from the add device button. Enter your AWS account name, access key and secret key. Optionally choose a collector other than the default localhost. Click Add. Alternatively you can use zenbatchload to add accounts from the command line. To do this, you must create a file with contents similar to the following. Replace all values in angle brackets with your values minus the brackets. Multiple accounts can be added under the same /Device/AWS/EC2 section. /Devices/AWS/EC2 loader='ec2account', loader_arg_keys=['accountname', 'accesskey', 'secretkey', 'collector'] <accountname> accountname='<accountname>', accesskey='<accesskey>', secretkey='<secretkey>', collector='<collector>' You can then load the account(s) with the following command. $ zenbatchload <filename> Configuring Guest Device Discovery Use the following steps to configure instance guest device discovery. Guest device discovery must be configured individually for each EC2 account. Navigate to one of the EC2 accounts. Click the edit link beside Device Class for Discovered Linux Instances Choose the device class for Linux and/or Windows instances. Verify that appropriate SSH, SNMP or Windows credentials are configured for the chosen device class(es). Remodel the EC2 account by choosing Model Device from its menu. If your instances are VPC instances, and are in a different VPC than the Zenoss server that's monitoring the EC2 account, you must add a Collector tag to containing VPC with the value set to the name of the Zenoss collector to which discovered guest devices should be assigned. Installed Items Installing this ZenPack will add the following items to your Zenoss system. Device Classes /AWS /AWS/EC2 Modeler Plugins aws.EC2 Datasource Types Amazon CloudWatch Monitoring Templates EC2Region (in /AWS/EC2) EC2Instance (in /AWS/EC2) EC2Instance-Detailed (in /AWS/EC2) EC2Volume (in /AWS/EC2) EC2Volume-IOPS (in /AWS/EC2) Device Types EC2Account (in /AWS/EC2) Component Types EC2Region (on EC2Account) EC2VPC (on EC2Region) EC2VPCSubnet (on EC2Region) EC2Zone (on EC2Region) EC2Instance (on EC2Region) EC2Volume (on EC2Region)

ZenPacks.zenoss.ActiveDirectory-4.2.5_2.1.0-1.lbn13.noarch

This Zenpack: - Creates a device class for Microsoft Active Directory with appropriate priorities. - Creates Windows Service and IP Service classes for Active Directory-related services with monitoring enabled. - Monitors the following metrics: DS Client Binds/Sec DS Directory Reads/Sec DS Directory Searches/Sec DS Directory Writes/Sec DS Monitor List Size DS Name Cache Hit Rate DS Notify Queue Size DS Search Sub-operations/Sec DS Server Binds/Sec DS Server Name Translations/Sec DS Threads In Use KDC AS Requests KDC TGS Requests Kerberos Authentications LDAP Active Threads LDAP Bind Time LDAP Client Sessions LDAP Closed Connections/Sec LDAP New Connections/Sec LDAP New SSL Connections/Sec LDAP Searches/Sec LDAP Successful Binds LDAP UDP Operations/Sec LDAP Writes/Sec NTLM Authentications

ZenPacks.zenoss.ApacheMonitor-4.2.5_2.1.4-1.lbn13.noarch

ApacheMonitor ------------- ApacheMonitor provides a method for pulling performance metrics from the Apache HTTP Server (http://httpd.apache.org/) directly into Zenoss without requiring the use of an agent. This is accomplished by utilizing the standard mod_status module that comes with version 1 and 2 of the HTTP server. The following metrics will be collected and graphed for the Apache HTTP Server. * Requests per Second * Throughput (Bytes/sec & Bytes/request) * CPU Utilization of the HTTP server and all worker processes/threads * Slot Usage (Open, Waiting, Reading Request, Sending Reply, Keep-Alive, DNS Lookup and Logging) Follow these steps to setup your HTTP server so that it will allow Zenoss to access the server status. 1. On the Apache server, find your httpd.conf file. This is normally located in /etc/httpd/httpd.conf or /etc/httpd/conf/httpd.conf. Other locations are possible depending on your operating system and setup. 2. Turn the ExtendedStatus option on in the httpd.conf file. This option will typically be commented out. You can enable it by uncommenting it. ... becomes ... ExtendedStatus on 3. Enable the /server-status location in the httpd.conf file. This is another option that typically already exists but is commented out. ... becomes ... <Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from zenoss.yourdomain.com </Location> 4. Save the httpd.conf file with these changes then restart httpd. This can normally be accomplished with following command. apachectl restart Once your Apache HTTP Server is configured to allow Zenoss to access the extended status, you can add Apache monitoring to the device within Zenoss by simply binding the Apache template to the device. 1. Navigate to the device in the Zenoss web interface. 2. Click the device menu, choose More then Templates. 3. Click the templates menu, choose Bind Templates. 4. Ctrl-click the Apache template from /Devices/Server to choose it. 5. Click OK. You will now be collecting the Apache HTTP Server metrics from this device.

ZenPacks.zenoss.CloudFoundry-4.2.5_1.0.4-1.lbn13.noarch

This ZenPack makes it possible to monitor the capacity and performance of applications running on a Cloud Foundry platform. This works for applications hosted in a local micro-cloud or a hosted environment such as the one offered by VMware at cloudfoundry.com. Cloud Foundry is an open PAAS (Platform as a Service) project initiated by VMware. Usage Once the CloudFoundry ZenPack is installed you can add endpoints by going to the infrastructure screen and clicking the normal button for adding devices. You will find a new option labeled, "Add CloudFoundry Endpoint." Choose that option and you'll be presented with a dialog asking for the following inputs. Target - An example would be api.cloudfoundry.com or api.vcap.me. Email - The email address you used to register. Password Once you click Add Zenoss will contact the target and get all of the operationally interesting information that exists. Once it is complete you'll find a new device in the /CloudFoundy device class with the same name as the target you entered into the dialog. Click into this new device to see everything that was discovered. The following elements are discovered: Frameworks Runtimes App Servers System Services Provisioned Services Apps App Instances The following performance metrics are collected: Per-Endpoint (target) Limits App URIs Apps Memory Services Usage App URIs Apps App Instances Running App Instances Memory Services Utilization App URIs Apps Memory Services Per-App Resources Memory Disk Usage CPU (average across instances) Memory Disk Utilization Memory Disk Instances Total Running Services URIs Per-App Instance Quota Memory Disk Usage CPU Memory Disk Utilization Memory Disk The following default thresholds are configured: Over 99% utilization of.. Endpoint App URIs Endpoint Apps Endpoint Memory Endpoint Services App CPU (average across instances) App Memory App Disk App Instance CPU App Instance Memory App Instance Disk Less than 1 running instance per App