Four months into this new gig at Cribl, I wish I could bottle up that “lightbulb” moment I get when walking people through how Cribl LogStream can help them gain better control of their observability data. So I hope the scenario walkthroughs below will capture some of that magic and shed some light on how LogStream can improve your organization’s data agility – helping you do more with your data, quickly, and with less engineering resources.
All Cloud providers such as AWS, Azure, Google Cloud Platform, and Oracle Cloud offer Object Storage solutions to economically store large volumes of data and retrieve it on demand. It’s far cheaper to store one petabyte of data in object storage than in block storage. As AWS S3 has become the standard, many on-premise storage appliance vendors have incorporated S3 APIs to store and retrieve data. Oracle wisely continued that trend to OCI (Oracle Cloud Infrastructure).
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.
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.