Child pages
  • Overview of FusionReactor Logs
Skip to end of metadata
Go to start of metadata

FusionReactor provides many helpful graphs and metrics to help you see how your system is performing.   These graphs are available in real-time and will also show you a short history of what happened (depending on the amount of data which has been generated), but what happens when your server begins to crash?   Lots of this data is stored in-memory so it can be used to generate reports and lists for the FusionReactor Administrator.  If you are having problems which cause (or necessitate) restarts of the server process, this in-memory data is lost - however all of this data will have been captured to one of FusionReactor's extensive log files. 

This data can in almost all cases be used in a post-mortem session to pinpoint the location of problems within a system. In addition to immediate post-mortem work, the logs can also be used to analyze usage patterns, trends and to derive longer-term aggregate data. 

As of FusionReactor 4.0, there are two styles of logging which is supported by FusionReactor. You can change current logging method on the Log Settings page.

If you wish to use the FusionAnalytics Connector then you must be using the Centralized Archive and Rotation logging method. If you try to enable the FusionAnalytics Connector whilst in Traditional mode then you will be be notified that the logging method will need to change and be given the option of having FusionReactor automatically make that change for you.

Centralized Archive and Rotation

If you install FusionReactor from scratch then this is the logging mechanism you will be using by default. The idea behind Centralized Archive and Rotation is that you end up with a set of log folders named with a timestamp (within the existing Log Directory specified on the Log Settings page) that each contain a complete set of log files for a specified period of time. You can choose whether a new folder be created every 'n' minutes, or you can specify a time at which the logs are daily rotated. Additionally you can specify how much log data you want to save, either by amount of disk space used, or period of time covered (or you can save all the logs if you have a big enough hard drive). The main advantage to this logging method over the older Traditional method is that is is a lot easier to batch up a complete set of log files covering a distinct period of time which is very useful when trying to compare values between log files or when importing them into something like FusionAnalytics.

All of these log settings are available on the Log Settings page.

Traditional Per-Log Rotation

If you upgrade an older version of FusionReactor to 4.0 then this will be the default logging mechanism you will be using. It is the logging mechanism used by all versions of FusionReactor prior to 4.0. The idea behind this logging mechanism is that, for each log file in the system, you can specify how big that file is allowed to become and how many log files you want to keep. If you specify a log size of 10MB and say that you want a history of 5 log files then you will have a maximum of 50MB of logs available to you at any time. With Traditional Per-Log Rotation, all the log files are stored in the Log Directory specified on the Log Settings page. For each type of log (eg request.log) you will end up with a set of numbered log files (eg. request-0.log, request-1.log ... request-4.log). Once request-0.log is full, all the log files are renamed and a new request-0.log is started (so request-0.log would always contain the latest log messages). The oldest log file (in this example, request-4.log) is deleted and immediately replaced with the file previously named request-3.log.

The settings for the File Size and File Count of your log files can be found in the associated settings page (eg. Request Settings for the request.log). We recommend however that you switch to the new Centralized Archive and Rotation logging method as it will give you more control over your logs.

Log files available in FusionReactor

Below you will find an overview of all of the log files which are available in FusionReactor, with a short description of each file.  Click on the log file name in the table to see a detailed description of all the log columns.   You can also find a [TYPE]-headers.txt file in the log folder, for the main log files. This file contains the symbols used in the logs. 

Data Logs

These are logs that relate to captured server data, for example SQL results, memory information etc.Clicking on the log names will take you to a page dedicated to that log, it will explain each attribute in the log as well as provide you with useful additional information.





Data related to the server memory, CPU, response time etc.


Data related to a PLUGIN or the SYSTEM. The information is brief and  only covers the state of the PLUGIN or SYSTEM.


This is FusionReactor.


A plugin that is connected to FusionReactor.

Log File Format

All log spaces are space deliminated. This allows you to easily import the files into spread sheets such as Microsoft excel and openoffice as well as databases, this allows you to view the logs how you want. Below is an example of a log file as well as the table that would accompany it.

Example log file and table

Below is an example log file

SERVER1 70 5 21

This log file contains the attributes CPU, 100, 5 and 21. Below is the table that would explain the log file.

Field Name



Server Name

1 [A]

The servers name.


2 [B]

How efficient the server is.

Downtime (hours)

3 [C]

The downtime of the server.

Uptime (hours)

4 [D]

The up time of the server.

Exceptions to the rule

There are several log files which also contain a plain text message. (eg reactor.log) In this case, the normal rule applies for all the values up to the last 'message' value, but after that, everything up to the end of the line is considered to be the value of the last field.

Also See


Importing and Graphing Data in Excel

Methodology in OpenOffice, where we used the request log with standard deviation to derive a nominal page run time value.

  • No labels