News New Look, Same Vision: KrakenD’s Website Redesign

You are viewing a previous version of KrakenD Enterprise Edition (v2.5), go to the latest version

Document updated on Oct 25, 2022

Logging in KrakenD API Gateway

The logging component is an essential configuration block for any installation that lets you choose where and how to log the gateway activity. It also opens the door to integrating other components for more advanced usage.

When you add the logging component, you can customize the format of the logs and send them both to the stdout and the syslog. However, if you don’t use this component, then KrakenD uses the basic capabilities of Lura (standard output only and a DEBUG level).

The telemetry/logging has the following logging capabilities:

  • Write to the Stdout (the console)
  • Write to the Syslog (local file or remote server)
  • Add a prefix to log lines
  • Select the reporting level
  • Option to use a predefined or custom format

Types of log messages

The content that KrakenD writes in its log represents two types of logging:

  • Access logs
  • Application logs

Access logs

The access log shows users’ activity and prints: which endpoints are requested, when, the status code, the duration, the requesting IP, and the method. An example of the format is:

[GIN] yyyy/mm/dd - hh:mm:ss | 200 |       4.529µs |      172.17.0.1 | GET      "/user/foo"
[GIN] yyyy/mm/dd - hh:mm:ss | 200 |       3.647µs |      172.17.0.1 | GET      "/category/bar"

The access log content is not customizable. It can be disabled using disable_access_log (see how to remove requests from logs options).

Access logs are never written in the syslog, regardless of their configuration, and they show only in stdout.

Application logs

The application log messages are the errors, warnings, debugging information, and other messages shown by the gateway while it operates.

The application logs are customizable as you can extend the functionality, such as sending the events to the syslog, using JSON format, choosing the verbosity level, or using the Graylog Extended Log Format (GELF).

In addition to this, a lot of exporters are available to send your logs out to third parties (see Telemetry)

Application logs might look different on each application, but this is an example:

yyyy/mm/dd hh:mm:ss KRAKEND DEBUG: [SERVICE: Gin] Debug enabled
yyyy/mm/dd hh:mm:ss KRAKEND INFO: Starting the KrakenD instance
yyyy/mm/dd hh:mm:ss KRAKEND INFO: [SERVICE: Gin] Building the router
yyyy/mm/dd hh:mm:ss KRAKEND INFO: [SERVICE: Gin] Listening on port: 8080
yyyy/mm/dd hh:mm:ss KRAKEND DEBUG: [SERVICE: AsyncAgent][mkt-event] Starting the async agent
yyyy/mm/dd hh:mm:ss KRAKEND DEBUG: [ENDPOINT: mkt-event] Building the proxy pipe
yyyy/mm/dd hh:mm:ss KRAKEND DEBUG: [BACKEND: /__debug/some] Building the backend pipe
yyyy/mm/dd hh:mm:ss KRAKEND INFO: [SERVICE: AsyncAgent][AMQP][mkt-event] Starting the consumer
yyyy/mm/dd hh:mm:ss KRAKEND ERROR: [SERVICE: Asyncagent][mkt-event] building the amqp subscriber: dial tcp 192.168.2.223:5672: connect: connection refused

Logging Configuration

To add ample logging capabilities, you need to add the component at the service level of your krakend.json configuration under the extra_config key:

{
  "version": 3,
  "extra_config": {
    "telemetry/logging": {
      "level": "INFO",
      "prefix": "[KRAKEND]",
      "syslog": false,
      "stdout": true
    }
  }
}

These are the different supported configuration options:

Fields of Improved logging
* required fields

custom_format string
Lets you write a custom logging pattern using variables, e.g: %{message}.
format string
Specify the format of the logs: default, logstash, or custom.
The custom format needs an additional key “custom_format”.
The “logstash” format needs the “telemetry/logstash” component added too.
Examples: "default" , "logstash" , "custom"
Defaults to "default"
level *
What type of reporting level do you expect from the application? Use the DEBUG level in the development stages but not in production. Possible values are from more verbose to least.
Possible values are: "DEBUG" , "INFO" , "WARNING" , "ERROR" , "CRITICAL"
prefix string
Adds the defined string at the beginning of every logged line, so you can quickly filter messages with external tools later on. It’s recommended to always add a prefix [INSIDE BRACKETS] to make use of predefined dashboards.
stdout boolean
Set to true to send logs to stdout.
Defaults to false
syslog boolean
Set to true to send logs to syslog.
Defaults to false
syslog_facility
When using syslog, the facility tells KrakenD where to send the messages as set by the locals of the syslog standard.
Possible values are: "local0" , "local1" , "local2" , "local3" , "local4" , "local5" , "local6" , "local7"
Defaults to "local3"

When setting a predefined format the output is:

  • default: Uses the pattern %{time:2006/01/02 - 15:04:05.000} %{color}▶ %{level:.6s}%{color:reset} %{message}
  • logstash: Logs in JSON format using the logstash format. See Logstash for more information. E.g.: {"@timestamp":"%{time:2006-01-02T15:04:05.000+00:00}", "@version": 1, "level": "%{level}", "message": "%{message}", "module": "%{module}"}.
  • custom: You set the format using custom_format. To know more about the possible patterns see the go-logging library

Writing the log on a file

Although logging on disk might impact software performance and is discouraged in high-throughput systems, you can still store the logs in a file.

Avoid redirecting the output (e.g.: krakend run > krakend.log) and use the syslog of your machine instead.

To setup logs on disk, you should consider the following steps:

  1. Add the syslog configuration to yor krakend.json
  2. Add a specific entry for krakend under /etc/rsyslog.d/
  3. Optionally add log rotation

1. Syslog configuration

{
  "version": 3,
  "extra_config": {
    "telemetry/logging": {
      "level": "WARNING",
      "syslog": true,
      "stdout": true
    }
  }
}

You might set the stdout to false if you don’t want to check on the console but only on the logs.

2. Add an entry to rsyslog

The folder /etc/rsyslog.d/ shows the different configurations of the system. We will create a new file /etc/rsyslog.d/krakend.conf and place this content inside:

local3.*    -/var/log/krakend.log

If you are familiar with syslog, you change the syslog_facility to any other (local) value and adjust it in the file above.

3. KrakenD log rotation

The syslog will take care of populating the log and can be used conveniently with the default system tools like rotating the logs with logrotate. Add a new configuration file /logrotate.d/krakend and add the content below:

/var/log/krakend.log {
  rotate 7
  daily
  missingok
  delaycompress
  compress
  postrotate
    /usr/lib/rsyslog/rsyslog-rotate
  endscript
}
Scarf

Unresolved issues?

The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.

See all support channels