Accelerate Your Path to Full-Stack Monitoring and Alerting
Register for this live webinar featuring Zenoss and VictorOps today!
Why Customers Choose Us
Discover why the largest companies in the world choose Zenoss.
Customer Support Portal
Zenoss Learning Center
Zenoss Partner Portal
Become a Partner
Top 5 Focus Areas to Succeed With DevOps
Forrester shares the tools, technologies and best practices to meet the challenges of today's modern IT environments.
Learn. Discuss. Participate.
Join thousands of Zenoss users and experts to learn, discuss and participate in the Zenoss Community.
Hybrid IT Monitoring
Zenoss provides complete visibility into physical, virtual, cloud and converged environments.
Request A Demo
This ZenPack is included with commercial versions of Zenoss and enterprise support for this ZenPack is provided to Zenoss customers with an active subscription.
The ZenPacks.zenoss.JBossMonitor ZenPack monitors JBoss application servers.
This ZenPack uses the JMX Remote API and accesses MBeans deployed within JBoss that contain performance information about the components that are being managed. The collected performance information includes: pool sizes for data sources (JDBC), Enterprise Java Beans (EJBs), message queues (JMS), threads, servlets, JSPs, and classloaders. Cache information is also accessible, providing system administrators insight into the number of hits (or misses) their cache policy has produced.
This ZenPack also aggregates individual performance metrics into higher level concepts that provide a picture of the performance of the application. Cache hits and misses are combined on the same graph to provide an overall picture of cache performance. Likewise, queue metrics are combined to show the number of messages currently on the queue, being processed, and being placed on the queue. Queue subscribers and publishers are also graphed.
Each of the individual performance metrics can be trended and predicted, and thresholds can be explicitly defined. Both the predicted thresholds and explicit thresholds inform system administrators of potential future problems before they occur. Since so much of J2EE involves "managed resources", the ability to monitor pool sizes and alert administrators prior to resources being exhausted is extremely valuable and can reduce the likelihood of a fatal outage caused by resource depletion.
Most of the metrics represent combinations of individual component metrics. For example, the Thread Pool metric represents all threads in all pools. It is possible to configure this ZenPack to perform at higher granularity and have it monitor a Thread Pool with a particular name. However, since these names are application specific we have chosen to configure this ZenPack to collect at a rather coarse-grained level by default. The installer is highly encouraged to customize and configure!
One particular monitoring template that requires end-user configuration involves Servlets. If a site to be monitored is revenue generating, and credit card submissions from the website are handled via a back-end servlet, it may be critically important to monitor the resources made available by the JBoss container to the servlet container. If the number of free spaces in the servlet pool dwindles to zero it could prevent your application from making a sale.
The following are the collected metrics for JBoss servers:
JBoss uses the JAVA_OPTS approach for enabling remote access to MBeans. However, it requires some additional properties. To set up your JAVA_OPTS for use in JBoss see the following code segment:
When you start JBoss via the run.sh you must also pass the "-b 0.0.0.0" argument:
./run.sh -b 0.0.0.0
JMX actually uses two separate ports for MBean access: one is used for initial connection handling and authentication, and the other is used for RMI access. During the handshake between a JMX Client and the JMX Agent the agent tells the client the IP address and port number for the RMI registry. By default JBoss sets the IP address to 127.0.0.1. This works when the JMX client and the JMX agent reside on the same device, but it won't work in a distributed environment.
By passing the "-b 0.0.0.0" argument you instruct JBoss to bind to all available network ports, and this results in the JMX Agent's handshaking logic using a network reachable address when informing clients of the RMI registry hostname and port.
The jmx-console Web page in JBoss allows you to view the different MBeans that are available; however, this does not mean that these MBeans are available remotely. If JConsole can view MBeans, then so can the zenjmx daemon that gathers this information.
All JBoss services must have a device entry under the /Devices/Server/JBoss device class.
Note: The zenjmx daemon must be configured and running. .
Tip: The out-of-the-box JBoss data source configuration has been defined at the macro level, but can be configured to operate on a more granular basis. For example, the Servlet Reload Count applies to all servlets in all Web applications but it could be narrowed to be Servlet /submitOrder in Web application "production server."
View the discussion thread.
This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.