Where beet Fits

From the above discussion, there are some obvious needs not easily met by existing tools:

  1. Easy addition of instrumentation at runtime, not compile-time

  2. Logging that is both detailed (method-call granularity) and low-overhead, so that it can always be active, even in production

  3. most importantly, strong correlation of events across multiple layers of a system, so that you know which request triggered that expensive SQL statement without needing to infer it.

beet aims to balance these needs against each other, so that you can react with more focus to production problems, and so that you can proactively understand how users behave as you consider ways to grow your system. The ideal use of beet combines it with judicious toolkit logging, system resource monitoring, and JMX console access to provide you with a profoundly detailed portrait of your live production system.

Why Spring?

The first release of beet targets Spring applications exclusively. This is mostly because of Spring's excellent runtime AOP support, which is critical to beet's aim of zero code modification. Spring is also unusual in being of generally high quality, completely free, and wildly popular. Finally, many other important frameworks make Spring compatibility a priority.

Still, the core components of beet are not tightly coupled to Spring and support for other deployment scenarios is conceivable. Deployment in a pure EJB3 container is a likely target for a future release.

Commercial and Open-Source Alternatives

There are many high-quality commercial alternatives. If closed-source and/or commercial tools are an option for you, make sure you evaluate a few. We won't specifically endorse any of them here, however :). Generally the benefit of a commercial alternative will be in the out-of-the-box data analysis tools; with our library, you mostly get the data, and what you do with it is your business. Many portal application servers (Sun Glassfish and BEA WebLogic come to mind) have some behavior tracking features; make sure you consider the capabilities of your target platform. Even if you have some tools available, beet may offer you something in simplicity, flexibility, and performance.

There is a growing body of excellent open source projects out there geared toward gathering performance metrics and monitoring a production system. You may want to evaluate:

and there are many others. Each tool has advantages and drawbacks. Beet is focused on delivering:

  • Single event granularity. Many tools take the approach of statistical aggregation to monitor quality-of-service. While you can use beet in this way, beet also maintains detailed information about individual executions (method calls, HTTP requests, SQL statements) and how those executions are nested for more effective post-mortem analysis of system outages. This configurable level of detail includes parameter values and user names.

  • Deploy-time installation. Beet is designed for use in existing production applications, without necessitating a recompile.

  • Centralized configuration. All aspects of beet configuration can be centralized in a single Spring configuration file, usually in 3-4 lines of simple markup.

  • Application scope. Beet does not require manipulation of the JVM or its runtime parameters, so you can instrument an application when you don't have strong control of the production environment.

  • Integration. Beet is designed for high-performance, meaningful data capture. It exposes data through JMX or XML to integrate with other popular monitoring and aggregation tools, rather than providing monolithic data analysis services.

Related Tools

As described in Chapter 4, JMX Integration, beet can export mbeans for integration with JMX monitoring tools. Besides jconsole (which ships standard with an SDK install), some open source tools worth considering in this role:

You should also check out MessAdmin for examining and administering session state in JEE applications.