Cribl puts your IT and Security data at the center of your data management strategy and provides a one-stop shop for analyzing, collecting, processing, and routing it all at any scale. Try the Cribl suite of products and start building your data engine today!
Learn more ›Evolving demands placed on IT and Security teams are driving a new architecture for how observability data is captured, curated, and queried. This new architecture provides flexibility and control while managing the costs of increasing data volumes.
Read white paper ›Cribl Stream is a vendor-agnostic observability pipeline that gives you the flexibility to collect, reduce, enrich, normalize, and route data from any source to any destination within your existing data infrastructure.
Learn more ›Cribl Edge provides an intelligent, highly scalable edge-based data collection system for logs, metrics, and application data.
Learn more ›Cribl Search turns the traditional search process on its head, allowing users to search data in place without having to collect/store first.
Learn more ›Cribl Lake is a turnkey data lake solution that takes just minutes to get up and running — no data expertise needed. Leverage open formats, unified security with rich access controls, and central access to all IT and security data.
Learn more ›The Cribl.Cloud platform gets you up and running fast without the hassle of running infrastructure.
Learn more ›Cribl.Cloud Solution Brief
The fastest and easiest way to realize the value of an observability ecosystem.
Read Solution Brief ›Cribl Copilot gets your deployments up and running in minutes, not weeks or months.
Learn more ›AppScope gives operators the visibility they need into application behavior, metrics and events with no configuration and no agent required.
Learn more ›Explore Cribl’s Solutions by Use Cases:
Explore Cribl’s Solutions by Integrations:
Explore Cribl’s Solutions by Industry:
September 25 | 10am PT / 1pm ET
Hold my beer: lessons from one team’s data pipeline journey
Register ›Try Your Own Cribl Sandbox
Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Get inspired by how our customers are innovating IT, security and observability. They inspire us daily!
Read Customer Stories ›Sally Beauty Holdings
Sally Beauty Swaps LogStash and Syslog-ng with Cribl.Cloud for a Resilient Security and Observability Pipeline
Read Case Study ›Experience a full version of Cribl Stream and Cribl Edge in the cloud.
Launch Now ›Transform data management with Cribl, the Data Engine for IT and Security
Learn More ›Cribl Corporate Overview
Cribl makes open observability a reality, giving you the freedom and flexibility to make choices instead of compromises.
Get the Guide ›Stay up to date on all things Cribl and observability.
Visit the Newsroom ›Cribl’s leadership team has built and launched category-defining products for some of the most innovative companies in the technology sector, and is supported by the world’s most elite investors.
Meet our Leaders ›Join the Cribl herd! The smartest, funniest, most passionate goats you’ll ever meet.
Learn More ›Whether you’re just getting started or scaling up, the Cribl for Startups program gives you the tools and resources your company needs to be successful at every stage.
Learn More ›Want to learn more about Cribl from our sales experts? Send us your contact information and we’ll be in touch.
Talk to an Expert ›December 23, 2020
As 2020 comes to a close (finally!) I have spent some time reflecting on some of our engineering achievements and, more importantly, lessons of the past few years. I am documenting them openly as much for our current Criblanians but also for those who are considering joining us.
I believe that a resource-constrained environment is a fertile ground for innovation – startups are able to disrupt incumbents that have orders of magnitude more resources. Focusing limited resources around highly leveraged engineering decisions is a proven way to build disruptive solutions. These decisions are the ones that lead to exponential results over time – a collection of such decisions can give an eng org an unfair advantage. In engineering terms this would be equivalent to coming up with an algorithm with better time and space complexity. I will list two examples of such decisions we’ve made that have accelerate building of LogStream.
These are just a few examples for key decisions that concurrently addressed 3 or more problems that we were either facing or would soon be. You’ll see this theme intertwined on all our principles below.
One of our core values is: Customers First, Always – in engineering the following two questions are key to every new feature we work on:
Building sexy features, using high leverage engineering decisions that provide value to no-one is … well, pointless. Everyone wants to work on the next shiny feature, however at Cribl we focus primarily on the impact of that feature on our customers. In enterprise software there are many mundane, boring, non-sexy features required in order for the product to be viable long term. Meaning, all those cool features driven by the latest in unbounded machine learning and AI would never have a chance to be tried or ever used. I’ll mention two examples:
In the above examples you’ll see again multiple problems addressed concurrently, with the goal of improving the experience of working with streaming data.
LogStream, once deployed, becomes a critical component in a customer’s infrastructure. As such, we need to ensure a high level of quality. Anyone who’s built distributed systems will tell you: they are hard to build, test and maintain. We have seen how the code base of such systems increases in complexity over time, as more corner cases are discovered and/or different failure scenarios are observed. I believe that once a code base reaches a certain level of complexity, its complexity would only keep increasing – the reason is simple: as more corner cases are observed, to avoid perturbing the rest of the system, one-off fixes are added – increasing the overall complexity. By design, code is a communication medium between engineers and machines, however it also plays a very important role as a communication tool between engineers (think code reviews, new team members on-boarding, or your future self). Code that is simpler to read and reason about is also simpler to get feedback and help on, simpler to test and simpler to ensure operational correctness – resulting in higher overall quality. We see complexity as a highly undesirable destination and strive to come up with the simplest, most elegant and readable solution.
The only perfect piece of software is the one that never ships! Striking a balance between shipping fast and shipping high quality is key for us. By tightly scoping a new feature, shipping it, then improving it based on actual user feedback we have managed to strike that balance. From our experience we’ve observed that new product features/components of a system will need to be modified, rewritten or even superseded over a period of 12–18 months. The key reason behind this is the fact that the feature or component is new, and therefore by definition the requirements are likely incomplete, and the testing environment or test cases may not capture all use cases. If the feature is released and gains traction then missing functionality would become apparent, new scaling requirements might surface – sometimes leading to major modifications or even rewrite. On the other hand, if there is no traction then rewrite might simply be deprecation and removal. One of the lessons we’ve learned over the past few years is patience, sometimes you can deliver features faster than what the customer base may uptake which could easily be misinterpreted as no traction. A concrete example here would be adding support for a syslog source and destination – it took ~9 months before that feature started gaining traction, during which time we had completely written that feature off as wasted time. Today syslog is one of our most popular sources and destinations – give your user base a chance to uptake your work before deprecating it.
From the early days we decided to standardise the development of LogStream on TypeScript – the backend would execute on NodeJS while the frontend would be a React web application. That initial decision was based on a few technical merits which I won’t go into, but also in a strong belief that a common language would help build a stronger team where everyone would be able to contribute to the overall team’s knowledge. Over the past few years we’ve seen the team knowledge really expand as well as easily cross the “frontend/backend” barriers.
As engineers, we are constantly required to learn, from new APIs, to updates to the runtime or new business requirements, etc. Reducing the cognitive load of a different language allows us to spend more time focusing on the problems that matter. Wait, why are we not picking “the best tool for the job” or the newest sexy language on the block (yes, yes, I’m talking about Rust)? The answer is simple: we just do not believe that such choices provide enough leverage to be worth the added complexity and friction that they introduce. Drawing parallels between building software and cooking, pro chefs choose to masterfully use very few general purpose tools (think knife) vs a ton of special purpose tools (onion slicer + avocado slicer + xyz slicer).
As engineers at Cribl, we build and ship software that allows our users to extract value out of all their machine data. We do this by making high leverage decisions, focusing on simple and elegant solutions to important customer problems and continuously learning as a team.
Michelle Zhang Sep 17, 2024
Clint Sharp Aug 27, 2024
Classic choice. Sadly, our website is designed for all modern supported browsers like Edge, Chrome, Firefox, and Safari
Got one of those handy?