In today’s contemporary landscape, organizations produce more data than ever, which needs to be collected, stored, analyzed, and retained, but not necessarily in that order. Historically, most vendors’ analysis tools were also the retention point for that data. Still, while this may first appear to be the best option for performance, we have quickly seen it creates significant problems.
Are you tired of sifting through data without context? Cribl Search adds valuable depth to your data, making it much easier to understand and analyze. No more squinting at cryptic logs or puzzling over unknown IP addresses! ️ Some common examples of how Cribl Search can enrich your data are adding service names or matching to threat intelligence. Another popular data enrichment is adding geographical location to events based on IP addresses.
Cribl’s integration catalog is ever-expanding. At Cribl, we constantly collect feedback on where to integrate next and channel it to deliver more high-impact integrations into our catalog. Whether it is Sources, Collectors, or Destinations, we constantly add new integrations to expand our reach in the IT security and observability ecosystem.
When exploring data, comparing individual data points with overall statistics for a large data set is often useful. For example, you might be interested in understanding when a performance metric rises above the historical average. Or possibly knowing when the variance of that metric increases past a certain threshold. Or maybe noting a change in the distinct number of IP addresses connecting to your public web portal.
This blog post discusses utilizing Cribl Search to pull and visualize data from the AWS API without ingesting data. This will allow you to collect, analyze, and visualize data from your AWS account in real time without ingesting the data first.
Cribl.Cloud has grown substantially since its launch, and our observability practice has developed in parallel. Gone are the early days of manageable logs and metrics. As we continue to grow, that problem will become even more challenging. We used Splunk internally, a well-used internal system, as our primary event management system. With Cribl Edge nodes deployed across our entire cloud fleet, we collect logs and metrics and send them to Cribl Stream for processing and routing.
As an engineer, you know your company’s problems, and you know what to do about them. However, being heard within your organization and funding a project can be challenging. Top executives might not understand your job’s ins and outs of the tools you need to do it well. Still, you need people holding the purse strings to understand why investing in your idea is brilliant.
“Hasn’t everyone already migrated to the cloud?” is a question you might be considering now. For many businesses – sure, they’ve migrated workloads and operations to the major cloud providers like Amazon Web Service, Google Cloud Platform, and Microsoft Azure. Still, many businesses have just now worked through their due diligence and scalability concerns. While many businesses are “fully cloud,” there are just as many yet to migrate.
Understanding the expected behavior of the Splunk Load Balanced (Splunk LB) Destination when Splunk indexers are blocking involves complex logic. While existing documentation provides details into how the load-balancing algorithm works, this blog post dives into how a Splunk LB Destination sends events downstream and explains the intricacies of blocking vs. queuing when multiple targets (i.e., indexers) are involved.
While tuning isn’t strictly required, Cribl Support frequently encounters users who are having trouble getting data into Stream from Splunk forwarders. More often than not, this is a performance issue that results in the forwarders getting blocked by Stream. When they encounter this situation, customers often ask: How do I get data into Stream from my Splunk forwarders as efficiently as possible? The answer is proper tuning!
