Tcat Alerting: not your grandfather’s Ops tool

November 15 2010

0 comments
motif

We all recognize the need for both server and application monitoring in a production environment and Tcat Server makes this easy. However, the development and process can also benefit from this feature.

At MuleSoft I’m often asked to write small one-off webapps for different parts of our internal infrastructure — often they are interim solutions or somewhat experimental; since these are somewhat less critical applications, at best I’ll create some unit tests, create a plan on our CI Server, and do some “developer QA” — which amounts to clicking around the basic flow and cajoling some co-workers into basic sanity and acceptance testing. Since I’m also responsible for provisioning the server and deploying the application, I like to take as many shortcuts as I can. Fast and informal is the name of the game here.

However, lately I’ve been using Tcat’s Alerting with these applications in both the production and QA cycles. This has allowed me to spend less time tracking issues and to catch obscure errors and performance issues before I deploy into production.

The first thing I’ll do is create a couple of alert types definitions in Tcat. I’m going to use the Low Memory and Log Regex Alerts for this particular application since I’ll be doing some fairly intensive I/O and also integrating with a new service provider that only returns vague error messages as strings (however, I do know that they start all their error strings with “Error:”, so I can easily parse that with a regex!).

After my project builds locally and the unit tests pass, I’ll deploy to my local Tcat repository via the maven plugin; then it’s a simple task of updating my deployments in the Tcat console with the newly created wars and Tcat will redeploy to my dedicated QA (and production if I’m ready) servers.

At this point I can offer up the application for acceptance testing and just sit back and hope those new I just setup aren’t triggered — no news is good news.  Once I deploy to production via Tcat, the same alerts can be reused to notify me if anything goes haywire in the future. At that point, I can leverage all the other diagnostic and monitoring tools available with Tcat.  There are many ways to skin this cat, but for me Tcat was an easy and obvious solution.

In the next installment we’ll take advantage of Tcat’s Dashboard feature to present all this information (and more) at a glance.


We'd love to hear your opinion on this post