Short application health checklist to ensure you’re getting the most out of FusionReactor
The notification email address is where FusionReactor will send the daily, weekly and monthly reports to and is also the email used to send crash protection notifications. If you have not done this already, it’s very important to set this up as soon as possible.
Configure your mail settings within the FusionReactor settings page.
Crash protection will alert you and attempt to keep your server/application responding when certain events or situations occur. The alerts are usually the first capability enabled, because these will provide critical insight into what’s going wrong and why.
Crash protection can alert you when:
For each of these alerts an email can be sent, which contains details of the running requests, resource usage and a full stack trace at the time the event triggered.
NOTE: Even when you have set up your notification email, you still need to set
CrashProtection email to ENABLED before the email will be sent. You can do this in the Crash Protection Settings.
As well as email alerts you can also queue or reject new requests coming into the application server to reduce load whilst the server recovers.
Once the notification email is configured, you will automatically start receiving daily reports from your FusionReactor instance, in the report, you will see information on any outages, total load for the day and number of erroring requests.
NOTE: All editions of FusionReactor provide a Daily Report – however, the Enterprise and Ultimate Editions also provide a weekly and monthly report.
Archive metrics allow you to view your historic log data within a user-friendly interface, so you can go back in time to identify issues and spot behavioural patterns within the application server.
A key issue for
With FusionReactor, we have made this process simple as you can view all the metrics available in the running server but for the past 31 days of captured logs.
In the example above we can examine the Garbage Collection activity at the time before a crash and see that we had a steady increase until the point the server became unstable and crashed.
If your web request makes any HTTP, JDBC, Mongo, Redis or ColdFusion tag (and many others), these are tracked as sub-transactions that you can see as an overview in the Relations tab of the request and drill into.
Resources allows you to monitor the health of the JVM and find potential optimizations.
Within resources, you have multiple graphs that allow you to monitor:
From the Thread’s view, we can see the state of each thread in live time and perform a stack trace to see what each thread is doing.
Comments are closed.