Configuration

Qtap can be managed locally with a yaml config file. This guide explains how to create, deploy, and maintain a local configuration file for Qtap.

New to Qtap? Follow the Complete Guide for hands-on examples progressing from basic to production-ready configurations (4 levels, 50 minutes).

Want centralized management? Check out Qplane for cloud-based configuration with visual dashboards, automatic propagation to all agents, and advanced analytics. See the POC Kick Off Guide to get started.

Configuration File Structure

The qpoint.yaml file consists of three main sections:

1. Storage Configurations (Where processed data goes)

2. Stacks (How data is processed)

3. Traffic Capture Rules (What data is processed)

Here's the basic structure:

version: 2

services:
  event_stores:
    # Event storage configuration
  object_stores:
    # Object storage configuration

stacks:
  stack_1:
    plugins:
      # First plugin configuration
  stack_2:
    plugins:
      # Second plugin configurations (optional)

tap:
  # Global traffic capture settings

Creating a Basic Configuration

Let's walk through creating a simple configuration file step by step.

Step 1: Set Version

Start by setting the configuration version:

version: 2

Step 2: Configure Data Storage

Next, define where captured data will be stored:

Stdout

services:
  # For connection metadata (anonymized)
  event_stores:
    - id: console_stdout
    - type: stdout
  # For actual request/response content
  object_stores:
    - id: console_stdout
    - type: stdout

This configuration:

• Outputs events (connection metadata) to the console for debugging

• Outputs objects (request/response content) to the console for debugging

S3 Endpoint

Step 3: Set Up Processing Plugins

Define how captured data will be processed:

stacks:
  default_stack: # Stack Name
    plugins:
      - type: access_logs
        config:
          mode: details # Default action (summary|details|full)
          format: console # (json|console)
          rules:
            - name: summary log example.com
              expr: request.host == "example.com"
              mode: summary
            - name: details log on anything above 400
              expr: response.status >= 400
              mode: full

This configuration:

• Creates a stack named "default_stack"

• The access logs plugin provides summary-level debug information with specific capture definitions for example.com, or full payload capture for traffic with a status code above 400

Step 4: Configure Traffic Capture

Finally, set up what traffic to capture and send to plugins:

tap:
  direction: egress
  ignore_loopback: false
  audit_include_dns: true
  http:
    stack: default_stack

This configuration:

• Captures all outgoing (egress) traffic

• Includes loopback traffic

• Includes DNS information in audit logs

• Applies the default_stack to HTTP traffic for processing

Example

Putting it all together:

version: 2

services:
  event_stores:
    - id: console_stdout
      type: stdout
  object_stores:
    - id: console_stdout
      type: stdout

stacks:
  default_stack: # Stack Name
    plugins:
      - type: access_logs
        config:
          mode: details # Default action (summary|details|full)
          format: console # (json|console)
          rules:
            - name: summary log example.com
              expr: request.host == "example.com"
              mode: summary
            - name: details log on anything above 400
              expr: response.status >= 400
              mode: full
          
tap:
  direction: egress
  ignore_loopback: true
  audit_include_dns: true
  http:
    stack: default_stack