FireBrick FB6402, Руководство пользователя

Страница: 46 / 196

29
Chapter 5. Event Logging
5.1. Overview
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.
5.1.1. Log targets
A log target is a named destination (initially internal to the FB6000) 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 FB6000, 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"/>
5.1.1.1. Logging to Flash memory
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 E for details on using this command). Chapter 16 covers the CLI in general.
Caution
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.