Cribl Validated Architectures Matrix Overview
This is an overview of the Cribl Validated Architetures (CVA) Matrix, a quick-reference guide designed to help you select a prescriptive architectural pattern based on your technical requirements.
The matrix uses descriptive CVA archetypes (like “Vanilla Hybrid” or “Small Push/Pull”) that serve as direct mapping points to your foundational topology blueprints and overlays.
The purpose of the CVA matrix is to illustrate the mandatory components, scaling principles, and operational guardrails for each CVA configuration by showing how:
- Topology (baseline): Defines the architectural foundation (such as Leader placement and Worker Group composition).
- Overlays (additive patterns): Are layered on top of the baseline to meet specific non-functional requirements (such as adding Leader HA, enforcing mTLS, enabling persistent queues where needed).
The full CVA Matrix in the following section will present the complete data set, including all 8 dimensions of evaluation for each archetype.
How to Use the Matrix
- Select the baseline: Select the row that matches your environment (Cribl.Cloud, on-prem, hybrid) and data-flow style (push or pull).
- Apply overlays: Layer on the relevant overlays from the row’s guardrails to meet your non-functional requirements (such as add Leader HA, enforce mTLS, enable persistent queues where needed).
- Validate operational guardrails: Ensure compliance with mandatory rules (for example, Worker to Worker Group bridging is limited to a single hop with TLS/mTLS, explicit allow-lists for hybrid paths, non-sticky load balancers for push listeners).
CVA Matrix: Mapping Archetypes to Topologies and Overlays
This mapping connects the descriptive names in the CVA matrix to the formal, structured topologies and overlays.
I. Foundational Topologies (Baselines)
These three archetypes correspond to your most basic deployment scenarios, built on the Distributed (Single Worker Group) Topology foundational topology.
| CVA Matrix Archetype (Row Name) | Corresponding Formal Topology / Blueprint | Key Design Principle |
|---|---|---|
| Vanilla Cribl.Cloud | Distributed: Single Worker Group (Cribl-managed flavor) | Focuses on using Cribl-managed Worker Groups and adhering to Cribl.Cloud constraints. |
| Vanilla On-Prem | Distributed: Single Worker Group (customer-managed flavor) | Focuses on the necessity of local Leader HA and configuration backup. |
| Vanilla Hybrid | Distributed: Single Worker Group (hybrid flavor) | Focuses on networking (allow-listing Leader IPs) for connectivity. |
II. Multi-Worker Group Baselines & Functional Overlays
These rows represent scenarios that require you to move from the Single Worker Group to the Distributed (Multi-Worker Group/Fleet) topology, primarily applying the Functional Split overlay.
| CVA Matrix Archetype (Row Name) | Corresponding Formal Topology / Overlay | Key Design Principle |
|---|---|---|
| Small Push/Pull | Distributed (Multi-Worker Group/Fleet) with the Functional Split overlay | Requires two Worker Groups/Fleets (one Push, one Pull) to separate different workload types for optimization. |
| Medium Push/Pull | Distributed (Multi-Worker Group/Fleet) with the Functional Split overlay (More complex) | Requires 2 Worker Groups/Fleets, potentially splitting by function and regional/destination family. |
| Large Push/Pull (multi-push) | Distributed (Multi-Worker Group/Fleet) with the Functional Split overlay (Specialized) | Demands dedicated Worker Groups for high-volume push (like Syslog) to mitigate connection pinning risks. |
| Many SQS/Event Hub | Distributed (Multi-Worker Group/Fleet) with the Functional Split overlay (Specialized) | Dedicates Worker Groups to pull-heavy collectors, tuned for job concurrency and partition management. |
| All-Cloud, Large Worker Group | Distributed (Single Worker Group) Topology (nearing limits) with Functional Split overlay | The guidance defines the trigger to transition from a Single Worker Group to a Multi-Worker Group structure (splitting when job/CPU limits are hit). |
III. Geographic, Bridging, and Strategic Overlays
These rows map directly to the advanced overlays you defined that address geography, trust boundaries, and strategic goals.
| CVA Matrix Archetype (Row Name) | Corresponding Formal Topology / Overlay | Key Design Principle |
|---|---|---|
| Cribl.Cloud/Hybrid (not Vanilla) | Distributed (Multi-Worker Group/Fleet) with Regional/Geo split overlay | Focuses on using Worker Groups for different regions/functions across environments. |
| Hybrid feed to Cloud | Distributed (Multi-Worker Group/Fleet) with Worker Group to Worker Group Bridging overlay. | A specific use case of bridging where an on-prem Worker Group acts as the Source for a Cribl.Cloud Worker Group destination. |
| Worker Group to Worker Group Bridging | Worker Group to Worker Group bridging overlay (General Pattern) | Defines the rules for crossing explicit boundaries (mTLS, single hop, schema contracts). |
| Fleets to Worker Groups | Cribl Edge and Stream Overlay | Defines the operational relationship between Edge Fleets (local collection) and Stream Worker Groups (central processing). |
How to Use This Connection
When you selects an archetype from the matrix (such as Small Push/Pull), you now know:
- The Blueprint: They must use the Distributed: Multi-Worker Group topology.
- The Overlays: They must apply the Functional Split Overlay.
- The Rules: They must follow the Small / Medium Push-Pull Mix guidance (such as tune the Worker Processes separately for push vs. pull).
This mapping should serve as your internal guide for connecting the descriptive language of the matrix rows to the formal titles of your documented topologies and overlays.