Cribl puts your IT and Security data at the center of your data management strategy and provides a one-stop shop for analyzing, collecting, processing, and routing it all at any scale. Try the Cribl suite of products and start building your data engine today!
Learn more ›Evolving demands placed on IT and Security teams are driving a new architecture for how observability data is captured, curated, and queried. This new architecture provides flexibility and control while managing the costs of increasing data volumes.
Read white paper ›Cribl Stream is a vendor-agnostic observability pipeline that gives you the flexibility to collect, reduce, enrich, normalize, and route data from any source to any destination within your existing data infrastructure.
Learn more ›Cribl Edge provides an intelligent, highly scalable edge-based data collection system for logs, metrics, and application data.
Learn more ›Cribl Search turns the traditional search process on its head, allowing users to search data in place without having to collect/store first.
Learn more ›Cribl Lake is a turnkey data lake solution that takes just minutes to get up and running — no data expertise needed. Leverage open formats, unified security with rich access controls, and centralize access to all IT and security data.
Learn more ›The Cribl.Cloud platform gets you up and running fast without the hassle of running infrastructure.
Learn more ›Cribl.Cloud Solution Brief
The fastest and easiest way to realize the value of an observability ecosystem.
Read Solution Brief ›AppScope gives operators the visibility they need into application behavior, metrics and events with no configuration and no agent required.
Learn more ›Explore Cribl’s Solutions by Use Cases:
Explore Cribl’s Solutions by Integrations:
Explore Cribl’s Solutions by Industry:
April 24 | 10am PT / 1pm ET
3 ways to fast-track your data lake strategy without being a data expert
REGISTER ›Try Your Own Cribl Sandbox
Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Get inspired by how our customers are innovating IT, security and observability. They inspire us daily!
Read Customer Stories ›Sally Beauty Holdings
Sally Beauty Swaps LogStash and Syslog-ng with Cribl.Cloud for a Resilient Security and Observability Pipeline
Read Case Study ›Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Transform data management with Cribl, the Data Engine for IT and Security
Learn More ›Cribl Corporate Overview
Cribl makes open observability a reality, giving you the freedom and flexibility to make choices instead of compromises.
Get the Guide ›Stay up to date on all things Cribl and observability.
Visit the Newsroom ›Cribl’s leadership team has built and launched category-defining products for some of the most innovative companies in the technology sector, and is supported by the world’s most elite investors.
Meet our Leaders ›Join the Cribl herd! The smartest, funniest, most passionate goats you’ll ever meet.
Learn More ›Whether you’re just getting started or scaling up, the Cribl for Startups program gives you the tools and resources your company needs to be successful at every stage.
Learn More ›Want to learn more about Cribl from our sales experts? Send us your contact information and we’ll be in touch.
Talk to an Expert ›The main purpose of load balancing is to prevent any single server from getting overloaded and possibly breaking down. In other words, load balancing improves service availability and helps prevent downtimes. This blog will talk about how Stream can load balance the data coming in and out of it.
The example follows a real-world architecture in which we have the following configuration:
First, we need to set up and Load Balanced the traffic coming from 5,000 Splunk UF to the 25 Worker Nodes. To do this, we were able to take advantage of Splunk UF’s built-in Load Balance.
Configuration example of Splunk Forwarder outputs.conf showing Load Balancing among Stream Worker Nodes: splunkforwarder/etc/system/local/outputs.conf:
[tcpout] disabled = false defaultGroup = cribl [tcpout:cribl] server = workernode1:9997, workernode2:9997, .., workernode25:9997 sendCookedData = true negotiateProtocolLevel = 0
For the next step, we load balance the traffic among the available 34 Worker Processes in each of our 25 Worker Nodes. Using the Stream sizing guide, we estimate 200GB per day for each Worker Processes. In our case, we needed to process 50TB per day incoming + 35TB per day outgoing. Therefore, we calculated that 14 nodes with 34 Worker Processes could handle the load. However, to count for the spike in load and to allow us to restart some of the workers with new configurations, we decided to increase our total number of nodes to 25.
Under the hood, Stream uses the Node.JS Cluster Module. The worker processes are spawned and communicate with the parent API Process via IPC. As a Splunk UF sends a TCP connection to the Worker Node, the Worker Node parent API Process distributes the incoming connections to the Worker Processes.
The primary process (Stream API Process) listens to the configured ports (e.g. ports 9997, 9200, and 10080), accepts new connections, and distributes them across the workers. The first connection for a specific port is distributed in a round-robin fashion. Each additional connection for that specific port will be allocated to the next worker process in an incrementing fashion.
Example for port 9997: In our case, we have 34 Worker Processes in each one of our 25 Worker Nodes. The first connection for port 9997 will be allocated (as we mentioned) using a round-robin, for example, to Worker Process (WP) 17. Then, the next connection will be incremented and allocated to WP 18, then WP 19, etc. At that same time, if we get a new connection for port 10080, the first connection will be allocated, again using a round-robin, to WP 8, the next connection will be allocated to WP 9, then to 10, etc.
25 Worker Nodes, each with 34 Worker Processes.
25 Worker Nodes, each with 34 Worker Processes Processing TCP Connections, Port 9997.
The Worker Nodes and Worker Processes are stateless. Therefore, if one of them died, the Splunk Forwarder will be notified that the TCP connection died, and it will resubmit the request to the next available one. Furthermore, to increase the system’s resiliency, the leader process also acts as a watchdog for worker processes, restarting any that exit or crash.
For the third step, we load balanced the traffic from the 25 Worker Nodes and 34 Worker Processes in each Worker node among the available 120 Splunk Indexers.
Using Stream Destination Splunk Load Balance, Cribl Stream’s approach to Load Balancing is much better compared to the Splunk UF’s approach. Stream uses a combo of Time + Volume to make sure all indexers get an even distribution of load. Data is sent by all worker processes to all receivers simultaneously, and the amount sent to each receiver depends on these parameters:
Stream uses this data to influence the traffic sent to each destination, to ensure that differences decay over time, and to verify that those total ratios converge towards configured weights. Over the subsequent intervals, the difference becomes exponentially less pronounced and eventually insignificant. Thus, the load gets balanced fairly.
25 Worker Nodes, each with 34 Worker Processes Sending to 120 Splunk Indexers in Parallel
If at any given point, out of our available 34 Worker Processes, 4 Worker Processes are handling TCP traffic and configured with a Splunk output, then the Splunk Destination will see 4 inbound connections.
In our case, we used Splunk Indexer Discovery to obtain the 120 unique IPs. This option allows Stream to get the list of all the Splunk Indexer IPs from the Splunk Cluster Manager and it uses load balancing to forward to all Indexers in the list.
To configure this option, we first logged into Splunk Cluster Manager and generated a new Token. In Splunk, this option is available under Settings -> Tokens.
Once we generated the Splunk Token, in Stream Leader Node under Destinations we created a Splunk Load Balanced destination with these configurations:
Stream’s persistent queuing (PQ) feature helps minimize data loss if a downstream receiver is unreachable. PQ provides durability by writing data to disk for the duration of the outage and forwarding it upon recovery. When a Splunk Indexer goes offline, Stream automatically gets the updated list of Splunk Indexers from the Splunk Cluster Manager node.
In this post, we showed how Stream can take advantage of Load Balancing end to end to prevent any single server from getting overloaded and possibly breaking down.
The example follows a real-world architecture in which we have 5,000 Splunk UF, sending a 50TB daily stream of data to 25 Cribl Stream Worker Nodes, and finally going to 120 Splunk Indexers. If you want to try out a free, hosted instance of Cribl Stream with canned data, check out the LogStream Sandbox.
The fastest way to get started with Cribl Stream is to sign-up at Cribl.Cloud. You can process up to 1 TB of throughput per day at no cost. Sign-up and start using Stream within a few minutes.
Experience a full version of Cribl Stream and Cribl Edge in the cloud with pre-made sources and destinations.