Operations | Monitoring | ITSM | DevOps | Cloud

Preventing data loss for data in motion is a challenge that LogStream Persistent Queues (PQ) can help prevent when the downstream Destination is unreachable. In this blog post, we’ll talk about how to configure and calculate PQ sizing to avoid disruption while the Destination is unreachable for few minutes or a few hours. The example follows a real-world architecture, in which we have.

It is commonly believed that once data is collected and ingested into a system of analysis, the most difficult part of obtaining the data is complete. However, in many cases, this is just the first step for the infrastructure and security operations teams expected to derive insights.

Shortly before the December holidays, a vulnerability in the ubiquitous Log4J library arrived like the Grinch, Scrooge, and Krampus rolled into one monstrous bundle of Christmas misery. Log4J maintainers went to work patching the exploit, and security teams scrambled to protect millions of exposed applications before they got owned. At Cribl, we put together multiple resources to help security teams detect and prevent the Log4J vulnerability using LogStream.

Here at Cribl, we have a cloud offering of our LogStream product. In building and supporting our cloud product, we have a service-based architecture. And we want to be able to gather metrics from our services, in order to monitor those services and make sure we meet our SLAs.

While I write this blog post, I reflect on the years of being a system administrator and the task of ensuring that no sensitive data made its way past me. What a daunting task right? The idea that sensitive data can make its way through our systems and other tools and reports is terrifying! Not to mention the potential financial/contractual problems this can cause.