A Cribl LogStream installation can be scaled up within a single instance and/or scaled out across multiple instances. Scaling allows for:

• Increased data volumes of any size.
• Increased processing complexity.
• Increased deployment availability.
• Increased number of destinations.

Scale Up

---

A single-instance Cribl LogStream installation can be configured to scale up and utilize as many resources on the host as required. Allocation of resources is governed through the General Settings > Worker Processes Settings section.

Memory (MB): Amount of memory available to each worker process, in MB. Defaults to 2048.

Process count: Indicates the number of worker processes to spawn. Negative numbers can be used to tie the number of workers relative to the number of CPUs in the system. Any setting less than 1 is interpreted as {number of CPUs available minus this setting}.

📘

Throughout these guidelines, we assume that 1 physical core is equivalent to 2 virtual/hyperthreaded CPUs (vCPUs).

For example, assuming a Cribl LogStream system with 6 physical cores (12 vCPUs):

• If Process count is set to 4, then the system will spawn 4 processes, using up to 4 vCPUs, leaving 8 free.
• If Process count is set to -2, then the system will spawn 10 processes (12-2), using up to 10 vCPUs. This will leave 2 vCPUs free.

📘

LogStream incorporates guardrails that prevent spawning more processes than available vCPUs.

It's important to understand that worker processes operate in parallel, i.e., independently of each other. This means that:

1. Data coming in on a single connection will be handled by a single worker process. To get the full benefits of multiple worker processes, data should come over multiple connections..
   
   E.g., it's better to have 5 connections to TCP 514, each bringing in 200GB/day, than one at 1TB/day.

2. Each worker process will maintain and manage its own outputs. E.g., if an instance with 2 worker processes is configured with a Splunk output, then the Splunk destination will see 2 inbound connections.

Capacity and Performance Considerations

---

As with most data processing applications, Cribl LogStream's expected resource utilization will be commensurate with the type of processing that is occurring. For instance, a function that adds a static field on an event will likely perform faster than one that applies a regex to finding and replacing a string. At the time of this writing:

• A worker process will use up to 1 physical core, or 2 vCPUs.
• Processing performance is proportional to CPU clock speed.
• All processing happens in-memory.
• Processing does not require significant disk allocation.

Estimating Requirements

Current guidance for capacity planning is: Allocate 1 physical core for each 400GB/day of IN+OUT throughput. So, to estimate the number of cores needed: Sum your expected input and output volume, then divide by 400GB.

• Example 1: 100GB IN -> 100GB out to each of 3 destinations = 400GB total = 1 physical core.
• Example 2: 3TB IN -> 1TB out = 4TB total = 10 physical cores.
• Example 3: 4 TB IN -> full 4TB to Destination A, plus 2 TB to Destination B = 10TB total = 25 physical cores.

Recommended AWS, Azure, and GCP Instance Types

You could meet the requirement above with multiples of the following instances:

AWS – Compute Optimized Instances. For other options, see here.

Azure – Compute Optimized Instances

GCP – Compute Optimized Instances

Scale Out

---

When data volume, processing needs, or other requirements exceed what a single instance can sustain, a Cribl LogStream deployment can span multiple nodes. This is known as a Distributed Deployment, and it can be configured and managed centrally by a single master instance. See Distributed Deployment for more details.