Storage Configuration

Understanding Qtap Storage Components

Qtap captures two distinct types of data, each with different storage requirements:

  1. Events (Connection Metadata): Anonymized information about connections, including timestamps, endpoints, and performance metrics

  2. Objects (Payload Content): Actual request and response data including headers and bodies, which may contain sensitive information

Each type has its own dedicated storage configuration in the services section of your qpoint.yaml file.

Objects (Payload Content) are selectively captured based on the plugin configuration. See Traffic Processing with Plugins

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

Event Stores

Event stores handle anonymized metadata about network connections. This data is generally not sensitive but is useful for analytics, troubleshooting, and monitoring.

Console Output (stdout)

The simplest option for development and debugging:

This configuration sends all event data to the console where Qtap is running, making it immediately visible but not persistent.

Axiom

For sending events to Axiom for analytics and monitoring:

This configuration sends event data to an Axiom dataset for advanced analytics and visualization.

Axiom Configuration Parameters

Parameter
Description

dataset

The name of the Axiom dataset to send events to

token

Axiom API token

OpenTelemetry (OTLP)

Send events to any OpenTelemetry-compatible backend using the OTLP protocol. Qtap exports events as OpenTelemetry Logs with rich structured attributes.

This configuration works with any OTLP-compatible backend including:

  • OpenTelemetry Collector

  • Datadog (OTLP ingestion)

  • Honeycomb (OTLP API)

  • New Relic (OTLP endpoint)

  • Grafana Cloud (OTLP)

  • Elastic (OTLP)

OpenTelemetry Configuration Parameters

Parameter
Description

endpoint

OTLP endpoint address (e.g., "localhost:4317" for gRPC, "localhost:4318" for HTTP). Required for grpc and http protocols. Not needed for stdout protocol.

protocol

Protocol to use: "grpc" (default port 4317), "http" (default port 4318), or "stdout" for debugging

service_name

Service name added to resource attributes (default: "qtap")

environment

Environment name for filtering/grouping (e.g., "production", "staging")

headers

Custom headers for authentication (e.g., API keys). Each header can use type: env to load from environment variables or type: text for direct values

tls.enabled

Enable TLS for secure connections (default: false)

Event Types Sent

Qtap sends two types of OpenTelemetry log events:

  1. Connection Events (event.type: connection) - TCP connection lifecycle and metadata including TLS version, protocol detection, bytes transferred

  2. Artifact Records (event.type: artifact_record) - HTTP transaction summaries with method, URL, status, duration, bytes, and links to full request/response data in object stores

See the OpenTelemetry Integration Guide for detailed setup instructions.

Qpoint Pulse Service (Coming Soon)

For self-hosted environments with a Pulse instance:

This connects to a Pulse service for advanced analytics and visualization.

Object Stores

Object stores contain the actual content of requests and responses, which often includes sensitive information. This data requires more careful handling and secure storage.

Console Output (stdout)

For development and debugging:

Sends all object data to the console.

S3-Compatible Storage

For secure, persistent storage:

This configuration:

  • Stores objects in an S3-compatible storage service

  • Uses HTTPS for secure transmission (insecure: false)

  • Retrieves credentials from environment variables

  • Provides a template URL for accessing stored objects

S3 Configuration Parameters

Parameter
Description
Example

endpoint

S3 server hostname and port

minio.example.com:9000

bucket

S3 bucket name

qpoint-objects

region

S3 region name

us-east-1

access_url

URL template for object access

https://storage.example.com/{{BUCKET}}/{{DIGEST}}

insecure

Allow HTTP instead of HTTPS

false (recommended)

access_key

S3 access key configuration

See credential management

secret_key

S3 secret key configuration

See credential management

URL Template Variables

The access_url parameter supports these template variables:

  • {{ENDPOINT}}: The S3 endpoint

  • {{BUCKET}}: The bucket name

  • {{DIGEST}}: The unique file identifier

Credential Management

For security, Qtap supports retrieving credentials from environment variables or using direct text values.

Environment Variable Configuration

Direct Text Configuration

For S3 credentials, when running Qtap, ensure these environment variables are set:

For Docker:

For Kubernetes, use secrets:

And reference them in your Helm values:

Object Storage Configuration Examples

MinIO Configuration

MinIO is a popular self-hosted, S3-compatible object store:

AWS S3 Configuration

For AWS S3:

Google Cloud Storage Configuration

For Google Cloud Storage:

Security Best Practices

When configuring storage, especially for production environments:

  1. Use HTTPS: Always set insecure: false to enforce encrypted connections

  2. Environment Variables: Never store credentials in the configuration file

  3. Bucket Policies: Restrict access to your storage bucket with appropriate IAM policies

  4. Encryption: Enable server-side encryption for stored objects

  5. Lifecycle Rules: Configure automatic deletion of old data to comply with retention policies

  6. Audit Logging: Enable access logging for your storage service

Complete Storage Configuration Example

This configuration sends connection metadata to the console for easy monitoring while securely storing the actual request and response content in MinIO.

Last updated