Documentation
  • Introduction
    • How It Works
    • Architecture & Data Flow
    • Why another Agent?
    • eBPF Concepts
    • Use Cases
  • Deployment
  • Qtap
    • Getting Started
    • System Requirements
    • Installation
      • Linux Binary
      • Docker Container
      • Helm Chart
      • Kubernetes Manifest
    • Configuration
      • Storage Configuration
      • Traffic Processing with Plugins
      • Traffic Capture Settings
      • Configuration Examples
    • CLI
  • Qplane
    • Getting Started
      • Create an Account
      • Install Qtap
      • Review your Dashboards
    • Installation
      • Linux Binary
      • Docker Container
      • Helm Chart
    • Configuration
  • Security & Compliance
  • License
  • Appendix
    • Qcontrol (Beta)
    • Java
    • Object Storage
      • Google Cloud Storage
    • S3 Credentials for Qtap using Kubernetes Secrets
  • FAQ
Powered by GitBook
On this page
  • Configuration File Structure
  • Creating a Basic Configuration
  • Step 1: Set Version
  • Step 2: Configure Data Storage
  • Step 3: Set Up Processing Plugins
  • Step 4: Configure Traffic Capture
  • Example
  1. Qtap

Configuration

PreviousKubernetes ManifestNextStorage Configuration

Last updated 11 days ago

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.

Configuration File Structure

The qpoint.yaml file consists of three main sections:

  1. (Where processed data goes)

  2. (How data is processed)

  3. (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:

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

services:
  # For connection metadata (anonymized)
  event_stores:
    - id: console_stdout
      type: stdout
  
  # For actual request/response content
  object_stores:
    - id: minio
      type: s3
      endpoint: 127.0.0.1:9000
      bucket: qpoint
      region: us-east-1
      access_url: http://localhost:9000/{{BUCKET}}/{{DIGEST}}
      insecure: true
      access_key:
        type: env
        value: S3_ACCESS_KEY
      secret_key:
        type: env
        value: S3_SECRET_KEY

This configuration:

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

  • Stores objects (request/response content) in a locally running MinIO S3-compatible store

  • Uses environment variables for S3 credentials (recommended for security)

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
Storage Configurations
Stacks
Traffic Capture Rules