In this livestream, Cribl’s Ahmed Kira and I explore the challenges of scaling your Cribl Stream architecture to accommodate a large number of agents, providing valuable insights on what you need to consider when expanding your Cribl Stream deployment. Managing data flows from a high volume of agents presents a unique set of challenges that need to be addressed.
In this livestream, Cribl’s Ahmed Kira and I go into more detail about the Cribl Stream Reference Architecture, with a focus on scaling syslog. They share a few use cases, some guidelines for handling high-volume UDP and TCP syslog traffic, and talk about the pros and cons of some of the different approaches to tackling this challenge. It’s also available on our podcast feed if you want to listen on the go.
I’m launching a new Observability Series called the Observability Professor, and it is designed to cover some common topics and terms in a vendor agnostic way. That’s right, no marketing! So what’s special, what’s new, what’s it going to cover that everyone else in the industry missed? Background: There are endless amounts of blogs, papers, and books on Observability; what it is and what it offers.
Multiple Worker Groups are now live in Cribl.Cloud. Meaning, customers can add more Worker Groups to their Organization, gaining additional capabilities specific to Cribl.Cloud deployments! We offer flexibility, scalability, and cost management as part of this feature!
Cribl Stream provides a robust HTTP REST collector, with many features and options. Still, there are endless combinations that vendors can provide in their API endpoints. Sometimes you may need to take more extreme measures to unlock data stashed begin the API entry point. No worries! Cribl also allows you to run a script to collect that data, and can even help you scale it. In this blog post, we’ll cover how I completed this task for a recent interaction using Qualys.
As a wise man once said, never ask a goat to install software, they’ll just end up eating the instructions. It may appear that the pesky goats have eaten some of those instructions or eaten too many sticker bushes to keep up with recent Microsoft Sentinel changes if you’ve tried configuring the CEF and Azure Connected Machine Agents. This guide is for you whether you have spent considerable time trying to get these agents to work or just dabbling in the Sentinel waters!
This tale is based on an actual event that happened to one of our Cribl Search customers. It highlights a massive gap between the urgent needs of modern businesses and the outdated, draconian terms dictated by traditional SIEM vendors. While the events are real, a touch of dramatization was added for the fun of it. Why not?
It’s quite common for data from a Search to contain references to information that is, well, unintuitive. Error or Message Codes, Port Numbers, Reference IDs, and Customer Numbers are all useful pieces of information, but far from being human-readable. That information is often available in a collateral location, often a spreadsheet or database, where it can be looked up with a “key” field.
Scaling to collect Windows Event logs with the Windows Event Forwarding Source can be tricky. Luckily, you can use a load balancer, and with some math to scale the number of workers to collect the amount of data you expect, you can use workers to collect Windows logs from a large number of endpoints. Endpoint logs are the lifeblood of observability in an incident response program.
In a recent user group meeting, guest speaker Marc Luescher from Amazon Web Services (AWS) joined us to give an overview of Amazon Security Lake. We talked about Cribl use cases and how Cribl Stream can bring your non-AWS data into the Security Lake. Enterprises are dealing with some significant challenges with security data in 2023. Inconsistent, incomplete, poorly-formatted log data is simultaneously scattered across companies and locked up in different silos within the organization.
