Imagine the panic of a business owner who starts the day with a devastating realization: their entire database has been compromised, and the attackers demand a ransom that threatens the very survival of the business. Unfortunately, this isn’t just a nightmare what-if, it’s an all-too-common reality in today’s connected world.

Collection agents emerged to alleviate the pain of having log files distributed around your application servers. However, they brought new problems since each log analysis tool wanted its own agent, trading in its own protocols and/or formats, usually targeting only a single use case. Meaning you had to install multiple agents for different use cases. Onboarding data and managing all these agents seems to be an afterthought.

In the original post in this series, we discussed the benefits of adopting Workspaces within your Cribl Cloud organization to create isolated Cribl instances for your clients. This time around, we’re going to look at how Cribl Edge can smooth the edges of your security operations. Sorry, I had to say it. I’ll see myself out.

In today’s fast-paced digital landscape, enterprise data stands as both a critical asset and a potential liability. With data volumes expanding at an annual rate of 28% while budgets increase by only 7%, organizations face mounting challenges. The unpredictable nature of data value complicates decisions on what to store and where. Moreover, the rise of connected devices and evolving security threats further exacerbate the situation.

We hear it often—data volumes are growing at a 28% compound annual growth rate (CAGR) year over year, and organizations struggle to manage it all. With no additional money in their budgets, they can’t afford to store more and more data in their SIEM, which in most cases means being uncompliant or, worse, not having older data readily available in the case of a recently discovered breach. I’ve repeatedly heard that the data they have archived is practically inaccessible.

Remember the Tabs vs. Spaces arguments? It seems that observability has grown up enough that we are arguing over which signals are the “best” signals for observability. Often referred to as the Pillars of Observability, Metrics, Logs, and Traces (sometimes adding Events for MELT) each provide a unique perspective on a system. What happens when we change our perspective from finding the “best” telemetry format to finding the telemetry that aligns with the problems we need to solve?

In an increasingly digital world, organizations face complex challenges in managing their security data that’s growing at a relentless pace. With the rapid growth of cyber assets and the ever-present threat of sophisticated attacks, legacy security tools often struggle to keep up.

This is one of a series of blog posts that explain how the Cribl SRE team builds, optimizes, and operates a robust Observability suite using Cribl’s products. If you haven’t, we encourage you to read the previous blog about how the Cribl SRE team uses our own products to achieve scalable observability. We installed Cribl Edge on the machines we manage for our users and use it to gather metrics.

As more and more applications are delivered daily, it’s becoming increasingly difficult for teams to onboard and manage them manually. To keep up with this demand, many teams are embracing automation in application delivery and management, with Kubernetes being a popular tool of choice. While Kubernetes’ scalability helps manage application infrastructure sprawl, there is still a need to collect data from the applications directly and from Kubernetes to monitor the growing beast itself!

Last time we spoke, I told you about our (then) brand-spankin’-new OTel over HTTP implementation, in both our OpenTelemetry Source and Destination. That was a little over a year ago, also known as a lifetime in tech! I wanted to take another opportunity to speak to you and introduce some of our new OpenTelemetry features, and share how you can put them into practice!