| Chapter 5. Event Logging | ||
|---|---|---|
 |  | |
| Chapter 5. Event Logging | ||
|---|---|---|
| | | |
Table of Contents
Many events in the operation of the FireBrick create a log entry. These are a one-line string of text saying what happened. This could be normal events such as someone logging in to the web interface, or unusual events such as a wrong password used, or DHCP not being able to find any free addresses to allocate.
A log target is a named destination (initially internal to the FB2700) for log entries - you can have multiple log targets set up which you can use to separate out log event messages according to some criteria - for example, you could log all firewalling related log events to a log target specifically for that purpose. This makes it easier to locate events you are looking for, and helps you keep each log target uncluttered with un-related log events - this is particularly important when when you are logging a lot of things very quickly.
A log target is defined using a log top-level object - when using the web User Interface, these objects are in the "Setup" category,
under the heading "Log target controls".
Every log entry is put in a buffer in RAM, which only holds a certain number of log entries (typically around 1MB of text) - once the buffer is full, the oldest entries are lost as new ones arrive. Since the buffer is stored in volatile memory (RAM), buffer contents are lost on reboot or power failure.
This buffer can be viewed via the web interface or command line which can show the history in the buffer and then follow the log in real time (even when viewing via a web browser, with some exceptions - see Section 5.6.1).
In some cases it is essential to ensure logged events can be viewed even after a power failure. You can flag a log target to log to the non-volatile Flash memory within the FB2700, where it will remain stored even after a power failure. You should read Section 5.5 before deciding to log events to Flash memory.
Each log target has various attributes and child objects defining what happens to log entries to this target. However,
in the simplest case, where you do not require non-volatile storage, or external logging (see Section 5.3),
the log object will only need a name attribute, and will have no child objects. In XML this will look something like :-
<log name="my_log"/>
The internal Flash memory logging system is separate from the external logging. It applies if the log target object has flash="true".
It causes each log entry to be written to the internal non-volatile Flash log as it is created.
The flash log is intended for urgent permanent system information only, and is visible using the show flash log CLI command (see
Appendix I for details on using this command). Chapter 21 covers the CLI in general.
Flash logging slows down the system considerably - only enable Flash logging where absolutely necessary.
The flash log does have a limit on how much it can hold, but it is many thousands of entries so this is rarely an issue. Oldest entries are automatically discarded when there is no space.
The console is the command line environment described in Chapter 21.
You can cause log entries to be displayed as soon as possible on the console (assuming an active console session) by setting
console="true" on the log target.
You can stop the console logging with troff command or restart it with tron command.
| | | |
| 4.4. Boot Process |  | 5.2. Enabling logging |