On This Page

Home / Reference Architectures/About Cribl Validated Architectures

About Cribl Validated Architectures

Cribl Validated Architectures (CVAs) are opinionated reference architectures for deploying Cribl products in public cloud, on-prem, and hybrid environments.

Unlike the general Reference Architectures, which are descriptive and flexible, CVAs are highly prescriptive. They define standardized blueprints and mandate the use of specific best practices, guardrails, and operational requirements to ensure optimal reliability, performance, and maintainability across all environments.

Beginning with your needs and the baseline we define, the CVA framework is designed to move your organization beyond ad-hoc design choices. It serves as a central decision aid for selecting the right architectural pattern, offering a minimal, reproducible baseline that can be extended from a simple “vanilla” single-tenant deployment to multi-regional, multi-group, and highly available topologies.

The CVA Decision Sequence

The CVA methodology is designed to be approached in a specific sequence to map your requirements to the correct deployment pattern.

  1. Start with your requirements: You must begin by defining your technical requirements, including expected throughput, data gravity (where your data sits), isolation boundaries, and operational Service Level Agreements (SLAs). For details, see Choosing an Architecture.

  2. Select the topology baseline: Defines the architectural foundation (such as Leader placement and Worker Group composition). Review the Assumptions and Terminology and the Foundational Topology Blueprints and use the Topology Decision Tree to choose the fundamental structure that best matches your environment.

  3. Apply workload overlays (optional): Are layered on top of the baseline to meet specific non-functional requirements (such as adding Leader high availability (HA), enforcing mTLS, enabling persistent queues where needed). Review the Common Patterns (Overlays) to determine if your environment requires separation based on function or compliance.

  4. Finalize via the CVA matrix: Now that you have a baseline and any necessary Overlays, you are ready to use the CVA Matrix and confirm the exact component CVA for your chosen baseline. First, review the Cribl Validated Architectures Matrix Overview to understand the relationships between topologies, overlays, and CVA. The CVA matrix evaluates patterns along critical dimensions, including:

    • Scale and Complexity: Typical event volume, number of Sources and Destinations, and overall topology complexity.
    • Leader Placement and High Availability (HA): Recommended deployment models for the Cribl Leader (Cribl.Cloud vs. on-prem) and strategies for redundancy and failover.
    • Worker Groups and Fleets: Strategies for partitioning and sizing Worker Groups and Fleets based on data movement patterns.
  5. Implement Guardrails: Consult the subsequent CVA Operational Guardrails to implement the mandatory operational guardrails associated with your selected pattern (such as specific load balancer requirements and configuration management strategy).

This process enables you to identify the deployment archetype that fits your environment, workload size, and governance requirements.

In Scope

This CVA document set targets technical practitioners and covers:

  • A selection of reference topologies for Cribl Stream and Cribl Edge.
  • Guidance on when to use each pattern, including trade-offs and constraints.
  • Roles and responsibility models across platform, security, and application teams.
  • Data collection and delivery patterns (push, pull, Worker Group→Worker Group, Cribl Edge→Worker Group).
  • Core design principles for Leaders, Workers, and Edge tiers.
  • Recommended operational models for configuration management, monitoring, and incident response.

Out of Scope

This document set does not cover:

  • Detailed capacity planning or Node-level sizing for specific workloads (events/sec, GB/day). Use the Cribl Stream/Edge sizing tools and workload tests in your lab environment instead.
  • Vendor (or account-specific) service quotas, network limits, or granular cost modeling.