-
Print
-
DarkLight
-
PDF
Kea Logging Configuration
Kea is quite flexible in many areas, including logging. There are many ways to set up logging and loggers: in fact, too many to cover all of them in just one article. All of the details are in available in the Kea ARM in the section specifically about Logging. Here are some basic guidelines which should offer enough information for most users to successfully configure logging in Kea.
Loggers
In Kea, log messages are controlled through what are known as "loggers." Basically, these are names which group together logs from specific parts of Kea. The ARM has a table of all of the available loggers. The idea here is to provide a way to funnel messages of a specific type to a specific destination (when used in conjunction with output
, detailed below).
Output methods
Kea offers three output methods for logs. These are stdout
and stderr
, syslog
, and /path/to/file.log
. These parameters alter the destination of the log info. Consider this example:
{
"Dhcp4": {
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
This will send all generated logs that are sent through the kea-dhcp4
logger to standard out (stdout
). If you are testing something and want to easily see logs, this is a great output method when starting Kea from the command line, as all logs will print directly to the terminal. syslog
in the output
setting will send the log message to the system log. You can also supply a facility example: syslog:local7
. Finally, a file may be specified in the output
setting, for example: /var/log/kea/dhcp4.log
, as described below.
Yes! Any output method can be used with any logger regardless of what output method was used with another logger.
Logging to a file
This method offers the easiest way of organizing log messages into separate locations by logger. In addition, it is possible to automatically rotate these files, which makes keeping detailed logs less burdensome.
Recommended basic logging configuration
This example loggers
configuration should meet most basic requirements:
{
"Dhcp4": {
"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "/var/log/kea/dhcp4.log",
"maxver": 10
}
]
},
{
"name": "kea-dhcp4.dhcpsrv",
"severity": "INFO",
"output_options": [
{
"output": "/var/log/kea/dhcp4-dhcpsrv.log",
"maxver": 10
}
]
},
{
"name": "kea-dhcp4.leases",
"severity": "INFO",
"output_options": [
{
"output": "/var/log/kea/dhcp4-leases.log",
"maxver": 10
}
]
}
]
}
}
Omitted here are parameters like maxsize
and pattern
, which will cause the default values for these to be used. The default pattern
should not be altered without a specific reason, as it is somewhat difficult to get right. The maxsize
parameter specifies how large the file gets before it is rotated; the default size is 10MB. You will notice in the example above that there is a maxver
of 10; this specifies the number of log files to be kept during rotation. In this example, there will be a maximum number of 10 log files of 10MB each of each logger setup. The maximum disk space that would be used for logs is 300MB with this configuration. This example is a good place to start for DHCPv4 logging as it should cover the most important things for troubleshooting and so on.
These examples all used DHCPv4, but there are similar settings for DHCPv6 that allow fine control over what is logged and where.