In the last few years, many organizations I worked with have significantly increased their cloud footprint. I’ve also seen a large percentage of newly launched companies go with cloud services almost exclusively, limiting their on-premises infrastructure to what cannot be done in the cloud — things like WiFi access points in offices or point of sale (POS) hardware for physical stores.

Health data is notoriously difficult to collect, route, and transform. I will demonstrate how to leverage the LogStream Observability Pipeline to solve these problems and help users search their Apple Health data.

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.