At work, we use Fusion Reactor to help monitor the health and performance of our ColdFusion J2EE applications. When certain application metrics reach a given threshold, Fusion Reactor sends out an Email Alert with a massive amount of data including a full stack-trace and a list of all the running requests. This email alert has been invaluable and I thank my lucky stars that such a product even exists! But, I think it could be better; or rather, there are ways that it could be made more readable. And, to start playing around with some of these ideas, I thought a great first step would be to parse the raw email content into a usable data structure.
The FusionReactorAlert.cfc is a ColdFusion component that takes the raw email content and provides methods for accessing the running requests, threads, CFThreads, and an aggregate report of all the data in structured format. Once instantiated, the ColdFusion component provides the following public methods:
- getColdFusionThreads() :: array
- getJavaThreads() :: array
- getReport() :: struct
- getRunningRequests() :: array
The "report" is a structure that contains two ColdFusion query objects:
By default, the running-requests query is ordered by request duration (DESC); however, since it's a ColdFusion query, you can run your own query-of-queries to order it as you see fit. The running-requests query also contains a query column, "thread," that embeds the Java thread directly in the request query record.
Here is a screenshot from the "Example" from the GitHub project. It just dumps out the two queries contained within the report:
| || || |
| || |
| || || |
The parsing in this ColdFusion component is based on the way that GMail reports the "original" email content. I am not sure if this "original" data is consistent across various email clients; or, if this is just how you can expect it in a GMail context. Furthermore, I built this using Fusion Reactor alerts from a single ColdFusion application; as such, I am sure there is going to be variation in formatting that I have not accounted for.
Anyway, now that I can get my Fusion Reactor alerts in structure format, I should be able to build some tooling around making the emails more readable and actionable.
Looking For A New Job?
Ooops, there are no jobs. Post one now for only $29 and own this real estate!
It's just a first attempt; but, I've already used it today :)
Hi Ben! That's awesome stuff you did! Just curious if we can reproduce this by using our new app mailparser.io!? You can create a free 30-day trial at http://mailparser.io
That's an interesting question. I have not heard of mailparser before. I couldn't really find any docs on your site. From the few screenshots on the homepage, it looks like the rules may be a bit too simple for my use case. If you look at the code for the component:
... it normalizes the data before parsing; then, it uses regular expressions to locate, and break up the data, which is subsequently transforms into data structures with standardized keys.
Perhaps you can shed some insight into how to parse complex emails; or provide a link to the docs for mailparser? Thanks!
the pattern matching with regular expressions is currently missing. We had this request already from some clients and we want to develop taht very soon. The rest (normalizing, cleaning, etc.) should be fine with mailparser.io.
If you like, give it a try. The trial is free and we won't bother you if you don't want to use it.