How to effectively capture Boundary Logs/Events

What?

This article demonstrates how to enable all sorts of Boundary event logging with appropriate configurations. 
 

How?

An event sink is set up in the configuration file for a controller or worker server with the help of the following stanza:

events {
 audit_enabled       = true
 sysevents_enabled   = true
 observations_enabled = true
 telemetry_enabled = true
 
  sink "stderr" {
    name = "system & error"
    description = "System & Error events sent to stderr"
    event_types = ["system", "error"]
    format = "hclog-text"
  }

  sink {
    name = "audit"
    description = "Audit logs sent to a file"
    event_types = ["audit"]
    format = "hclog-json"
    file {
      path = "/home/ubuntu/"
      file_name = "audit.ndjson"
      rotate_bytes = "536870912" 
      rotate_max_files = "7"
    }
  }

  sink {
    name = "telemetry"
    description = "Telemetry events sent to a file"
    event_types = ["telemetry", "observation"] #Observation events are mandatory to capture Telemetry events
    format = "hclog-text"
    file {
      path = "/home/ubuntu/"
      file_name = "telemetry.ndjson"
      rotate_bytes = "536870912"
      rotate_max_files = "7"
    }
  }
}

Why?

Boundary generate a lot of events, and it's important for the Boundary Support team to follow the trail of the logs to understand the root cause of the issues that are reported. Keeping the distinct events/logs separated in different files gives an advantage to the person going through them.

Every event type in boundary capture different sorts of events; hence, it is important to enable all of them because you never know what sorts of issues you may encounter.

It's a proactive approach.

Important!

• The "_enabled" parameter needs to be set to "true" for the boundary to emit the audit and telemetry events. By default, only system and observation events are emitted, even if no stanza is defined in the config file.
   
• You can also capture the system and error type events in the file, but since there will be a lot of them, it's better to capture them on "stdout/stderr" (mostly, journald).
   
• "rotate_bytes" represents the maximum size of the event file when configured, after which the file will be rotated. Basically, a new file will be created for the live events, and previous events will still be stored/persisted in the previous file.
   
• "rotate_max_files" represents the total number of event files to keep.
   
• We can also filter what sorts of events can be captured with the help of allow_filters and deny_filters.
   
• We can also define audit_filter_overrides to protect/encrypt/redact the sensitive data and secrets on the log file.

Reference Articles:

• Filter Events