Kea Logging Configuration
  • 11 Mar 2023
  • 2 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

Kea Logging Configuration

  • Dark
    Light
  • PDF

Article summary

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.

Is it possible to use multiple output methods?

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.

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.

What about DHCPv6?

These examples all used DHCPv4, but there are similar settings for DHCPv6 that allow fine control over what is logged and where.