My primary use case for Cribl is to manage and optimize observability data before sending it to different destinations, such as routing. I deal with a very large volume of logs coming from multiple sources, including large log systems. This includes system logs, application logs, and security-related logs. Using Cribl, I can filter unnecessary logs and transform that data as required, and I can route important data to the appropriate destinations. This is very helpful to me and helps me reduce data volume and improve performance. I also use pipeline configurations to control how logs flow through the entire system. This makes it very easy for me to maintain data consistency and manage large log systems across different environments.

The most valuable thing or feature for me in Cribl is data routing and pipeline flexibility. Cribl allows me to define how data should be processed, filtered, and routed to different destinations. One of the things I also find very useful is edge processing, which allows me to process data closer to the source, which helps reduce unnecessary data and improve performance. Overall, flexibility and control over observability data are the things I appreciate most about Cribl.

Cribl handles large logs very efficiently by using its pipeline-based architecture, which I find most useful. It allows me to transform data through routing and filtering before sending it to downstream systems. When dealing with large volumes of logs, I can define pipelines that drop unnecessary fields and remove duplicate logs. There can be so many duplicates and redundancies that filtering them out significantly reduces the overall data volume. Another helpful capability is routing, which helps me route different types of logs to different destinations and prioritize fields that I want. For example, critical logs can be sent to one destination while lowering the priority of other logs, which are stored elsewhere. This helps me in large-scale log environments very effectively. Cribl also supports horizontal scaling, where I can add more worker nodes to handle increasing log volumes. This ensures my performance remains stable, even as log ingestion increases.

I have seen a decrease in logs by using pipelines, which helps me decrease logs by filtering and optimizing data before sending it downstream. For firewall logs specifically, I have seen that it helps reduce volume by filtering unnecessary or repetitive events. When a firewall device generates a large number of logs or deny logs, many of which are repetitive or not always useful, Cribl filters out the low-priority logs such as allowed traffic and routine events. I remove the unnecessary fields from firewall logs, which reduces the log size.

The main downside of Cribl is that it is not very beginner-friendly. They could include tutorials or something more interactive for beginners. For experienced users, it works well. The learning curve is significant; learning Cribl from the initial stage for someone who doesn't have any background knowledge may be difficult. Since it offers lots of flexibility with pipelines and routing, it can take time for beginners to understand how everything works properly and to complete the configuration. The initial setup is also a little complex. Additionally, Cribl has limited built-in analytics compared to dedicated monitoring tools.

I have been working with Cribl for more than one year or one and a half years.

Technical support is very helpful. My experience with Cribl support has always been positive. They do not delay responses. The documentation covers almost everything for the use case, especially all the major features they include. For any issues I encounter, I was able to resolve them by using mostly documentation and community resources without needing to contact support directly. For technical clarification, if required, the available resources including guides and examples of best practices are quite helpful. The support ecosystem around Cribl is very good, and most issues are resolved quickly.

I was previously using Splunk. Splunk was mostly used for storing, searching, and analyzing logs. Once I discovered Cribl, I found it more useful. Cribl helped me with managing, filtering, pipeline routing, and flexibility before sending data to destinations or monitoring tools. Cribl sits between a data source and an analytics tool, which helps me reduce my flow, save time, and optimize data volume. If I had to choose between Splunk and Cribl for filtering and routing, I would obviously choose Cribl. For analyzing and searching, I continue to use Splunk.

The initial deployment of Cribl is not very user-friendly for beginners. For beginners, they might find that they have to first study and get to know everything about it. Once they get used to it, they will find that it is a very useful tool. It is not very beginner-friendly, but if the user is experienced or knows the relevant terms, then it will be very easy.

For cost optimization, Cribl's pricing is moderate. I will not say it is too high or too low.

For something similar to Cribl, I have used Splunk.

The maintenance for Cribl is relatively minimal. Most of the time, I focus on monitoring pipelines, which is manual work. I check the data flow and make small adjustments as I need them. For new log sources or adding anything, that is the manual work I have to do. I also review pipeline configurations to ensure logs are being filtered and routed correctly. If there are any changes in log formats or new data sources, I update the pipelines accordingly. Monitoring system performance and ensuring the worker nodes are running properly is something I always do. If the volume of logs increases, I scale the nodes to handle the load. Overall, maintenance from my side is minimal. Once the pipelines and configurations are done, Cribl runs very smoothly with very minimal manual intervention. I would rate this review as a nine out of ten.

I use Cribl as our data ingestion source, with Cribl Edge agents installed across all servers. Cribl is used at the pipeline or routing level to send data to our SIEM platform.

Firewall logs are sent to Cribl, and Cribl routes specific logs to our SIEM tool while sending others to archive storage. This segregation and separation capability is not possible with any other tool, which makes me very satisfied. However, Cribl charges us for all firewall logs that it observes, not just what it processes and outputs.

Cribl performs parsing and field reduction exceptionally well, cutting down unnecessary fields and delivering only the right data. However, Cribl charges for everything it sees rather than just what it parses. We might ingest a large volume of data but only process about forty percent of it, yet we are charged for one hundred percent of the data ingested into Cribl.

The ability to bifurcate or trifurcate data and send it to multiple destinations is a feature we love. I have been a Splunk user for over eight years, and this is something Splunk did not have until Cribl introduced it specifically for this purpose.

Cribl handles logs, metrics, and various data sources really well. I have ingested up to fifty terabytes of data per day, and Cribl has never failed or caused trouble from that perspective. Cribl handles huge volumes of data exceptionally well.

A feature I would want Cribl to add in future releases is the ability to create a greater number of fleets. Currently, Cribl has a limitation on the number of fleets that can be created. In an enterprise environment, different types of servers belong to different applications and should be organized accordingly, as each has a different change management cycle and upgrade cycle. Cribl cannot be upgraded all at once, so we want to separate fleets so we can perform upgrades in batches rather than all in one shot. Increasing the number of fleets would be greatly appreciated.

Data cost is a concern, as Cribl charges for everything it sees rather than everything it processes. I do not see much cost-effectiveness from this approach. If we could do pre-processing before sending data to Cribl, then Cribl would be cheaper than other tools, but if we could do that, we would not need Cribl at all. This costing model has been concerning for a while. Better options based on user base, enterprise size, or data volume would be beneficial. More options to choose from for pricing tiers are needed, as the current offerings are very limited.

I have used Splunk previously and have been using Palo Alto XSIAM. Palo Alto XSIAM has integrated features from Cribl, Splunk, and Sentinel into one comprehensive tool, taking the best features from all three. Another concern is that there is not much default alerting available for Cribl metrics, and custom alerting is also difficult to configure. For example, backpressure monitoring has only very limited use cases available out of the box when monitoring Cribl environment health. Cribl could take steps to increase the number of use cases and add guardrails around how much volume can be ingested. Options to create custom alerting would be helpful, such as alerts when certain metrics go down or up, or when the catchall is filling up. These options exist but are very complicated to set up. Unlike users who have been using Splunk for ten years and transitioned to Cribl, I find it very difficult to navigate and create alerts in Cribl. The ease of use could be improved by providing default options that can be leveraged and customized as needed.

Cribl initial deployment was easy, but for large enterprise networks and big organizations, Cribl does not support operating systems earlier than 2012. This creates a problem, and a package should be available for anything below 2012 that works as expected. Currently, Cribl only approves packages for 2012 and above, but some organizations require applications to run on legacy servers. This option is not available, and we are unable to get Cribl installed without finding alternatives or going back to using Splunk to pull data and then stream it to Cribl. This causes significant operational challenges, and if this could be fixed with one version that supports everything below 2012, it would be greatly appreciated.

Cribl is deployed both on-premise and in the cloud. Cribl placed sample data in one of the YAML files that contained examples of personal data like social security numbers or credit card information. When this YAML file was included in Cribl package itself, vulnerability scanners detected it as a non-compliance or data loss concern, even though there was no actual personal information, API keys, or sensitive data present. These were just examples provided by Cribl. Cribl fixed this issue in the latest version after we brought it to their attention. Going forward, I would like Cribl to think about this from a bigger enterprise perspective, as endpoint security tools will detect all of these concerns. It is not just about processing data but also about the problems faced when deploying it in a large enterprise. This thought process needs to increase from Cribl's side.

I have used Cribl for over a year.

A dedicated support portal is available, and support cases are usually raised through a dedicated email. Responses are received at reasonable times, so this has not been a problem. I would give support a rating of seven out of ten.

We use Cribl Stream to collect logs from multiple sources, transform and enrich them, filter out unnecessary data before sending them to SIEM. We also use Cribl to route logging to data lake.

Since we started using Cribl, it’s made a huge difference for us. We spend a lot less time building and maintaining things, so the team can focus on the security work that really matters and brings value. Plus, by filtering out all the noisy data we don’t need, we’ve been able to cut costs and make our data a lot cleaner.

One of the biggest things I love about Cribl is that you can actually see the output in real time before you push anything to production. The UI makes it super easy to work with, and honestly, it saves a ton of time. Plus, it’s way easier to collaborate—everyone’s on the same page, and you’re not guessing what the data’s gonna look like once it’s live

So since we’re handling a ton of data, I think we could really benefit from a more integrated or connected way to manage it all. Like, if there is a way to better track data lineage, metadata, those can help with knowledge transfer.

A couple of months

I haven’t ran into issue yet

I can’t really speak to scalability yet. So far I don’t have any problem with it.

The technical support is good. I'm happy with that.

We have used something similar before, which was Logstash.

Not sure

I think the pricing for Cribl is reasonable. For large usage, but I heard the calculation of those credits is a bit complicated.

We did, but Cribl just felt more mature and well-established. I think that’s the reason why we selected it.

Cribl gives us way more control and flexibility than we ever had before. We deal with massive volumes of telemetry data, and honestly, a lot of it is just noise. Cribl allow us to easily filter, transform, and route that data exactly how we want. It’s made a big difference.

We use Cribl for data normalization, which involves standardizing data from various sources before sending it to a SIEM. This helps reduce costs associated with SIEM ingestion. Additionally, we use Cribl to sanitize data by removing or masking sensitive information from certain fields.

Cribl filters out unnecessary events and data, and we reduced the costs associated with SIEM ingestion.

You can use Cribl to route the same data to different destinations. For instance, if a company uses multiple SIEMs and needs data in each, Cribl makes it easy to direct that data to various destinations. Setting up API connections to get data into the platform is easy. Cribl offers a cloud version, allowing different workspaces to segregate various functions within a company or organization.

The documentation part could be better. Their documentation could be updated, as new features often outdated existing information. Additionally, there are inconsistencies between the documentation for Cribl Cloud and Cribl on-premises. This can be confusing, as features may differ, leading to potential misunderstandings if you use documentation intended for one version while working with another. Consolidating and improving the clarity of the Cribl Cloud documentation would be very helpful.

I have been using Cribl for a year and a half.

It is highly scalable. If you need more cloud worker groups, you're just a click or two away from doing that at extra cost.

Depending on the license, we usually provide a Customer Success Manager to assist with any questions or issues when onboarding Cribl. They are very responsive, and their support is quite helpful.

We employed a hybrid strategy, setting up Cribl Cloud as the head node in their environment. For data processing, we used worker nodes within the client’s environment, which are closer to the data sources. This setup allowed us to process data locally before sending it to our destination. For cloud assets, such as SaaS applications like Salesforce, we used the cloud-hosted Cribl instance to handle that information. Meanwhile, the on-premises data was processed by the hybrid worker nodes.

We encountered delays due to third-party issues, extending the timeline to six to seven months. Without these issues, it likely would have taken around three months, depending on the speed of obtaining API keys, authorizations from networking teams, and other factors. Under ideal circumstances, a three-month timeframe would be more accurate.

You need to maintain the pipeline, which includes data processing, before it reaches its destination. When onboarding new data, managing and rotating API keys as needed is important. Maintaining these aspects ensures faster and more efficient deployments.

If you want to reduce log ingestion or route data to multiple destinations, consider using an on-premises or cloud solution. Your choice will depend on your organization’s network constraints. For example, if critical assets on your network need to connect to the internet, your network team might have restrictions. Weigh the benefits of cloud versus on-premises options to determine what best fits your needs.

With less data coming into our system, we can now run queries faster since we're not processing as much data as before. The reduction has made our queries more efficient because we're working with more streamlined data.

The quick connects are great for testing and allow you to rapidly set up a proof of concept, which is very beneficial. They can also be useful in production environments. Another significant feature is the recent Sentinel integration. The provided pack simplifies the setup process, making it much easier than the previous method, where you had to manually handle tasks like finding API keys. This integration makes the setup much more efficient.

Overall, I rate the solution a seven out of ten.

I use Cribl to ingest logs from different platforms. These logs could come from sources like Mimecast, Windows, or CrowdStrike logs. It acts as a pipeline to send data to our destinations and also helps in reducing the amount of logs sent by applying different functions on them.

Cribl has helped to save thousands of dollars for our clients. It provides cost-effective solutions, particularly when you know how to use it effectively. It does require some learning to cover all aspects of it because it's not entirely intuitive. However, once you overcome the learning curve and get hands-on with the platform, it significantly contributes to cost savings.

The capability to reduce logs in a user-friendly manner is a standout feature. Cribl allows us to view logs live as they are being processed, giving us quick feedback on the changes made.

Additionally, the data routing feature is beneficial because it gives us the option to send logs through data routes or QuickConnect, facilitating quick configurations of different sources and managing them more effectively. These functionalities offer logical and useful capabilities such as deciding where logs should be sent and specifying which fields should be included within the logs.

There is room for improvement in the documentation and knowledge base, particularly regarding configurations like sources where logs are being ingested. It would be helpful to have specific guidance on configuring different data sources, such as AWS S3 buckets. Additionally, the ability to understand what type of output a function will produce is missing in Cribl, which could be improved by indicating the output type.

I have been using Cribl for more than one and a half years.

Cribl's stability has been well documented online, and we have not encountered any significant stability issues.

We have tested Cribl and found it to be sufficiently scalable for our needs.

At the time I was trying to do the course back then, I did escalate questions to tech support, but I haven't raised any recent issues.

I have experience with Splunk and CrowdStrike. I am quite familiar with Splunk.

Cribl is indeed a cost-effective solution, saving thousands of dollars for our clients. It provides value through cost savings and time efficiency once users know how to effectively use the platform.

It's important to know what source you will be using to ingest data into Cribl. Understanding how to configure the data source is key before using the platform. Once you have that figured out, Cribl becomes a powerful solution that can ingest almost anything with its Edge capability. However, having a clear understanding of the pathways you can take to ingest data is crucial before diving into it.

We've encountered several challenges, but what's most promising and encouraging is Cribl's scalability. The architecture is impressive, and it distributes work across all worker nodes and communicates with the leader.

There have been several administrative issues. Another point is that the browsing functions aren't very intuitive.

The most challenging aspect is the versioning system. Everyone can see and potentially deploy each other's changes in a team of developers. Unlike traditional versioning systems, where you work in isolated feature branches and only merge changes after reviewing conflicts, Cribl's versioning system requires careful management because everyone works on the same repository.

I work with a team that includes both experienced and less experienced developers. Though new to this technology, the two senior developers have extensive experience with various other technologies and can get up to speed relatively quickly with the available training. The less experienced developers face significant challenges. They struggle to understand the system, suggesting it may not be intuitive.

I have been using Cribl for two years.

I rate the solution’s stability a seven out of ten.

10-15 people are using this solution.

Everything works, but it required a lot of support. The setup wasn't easy, but the support team was very helpful and managed to get everything production-ready.

Setting up Cribl for basic training is straightforward and effective. You can easily configure it on your laptop by downloading the binaries and using simple command-line instructions to set it up in different modes, like leader, edge node, or single deployment. Adding a worker node is also simple; just run a script generated in the UI, and it's up and running.

The enterprise setup process is more complex, and there are significant documentation challenges. Despite the system eventually being available, the process involved many support calls and workarounds. Getting everything set up for a production-ready enterprise deployment was long and challenging.

In some of the projects I've been working on, we're still testing and exploring Cribl's capabilities. We haven't established specific business goals or fixed objectives yet. Currently, we're focused on ingesting data from various sources with minimal transformation to understand how Cribl handles different types of logs and data.

I encounter issues with the UI not accurately reflecting the current status. For example, the UI might show that a worker is still fetching the latest version of the code, but after refreshing the page, it usually updates to show that everything is up and running. Over time, I've learned to recognize when the UI is not displaying the correct information and use the refresh button to get the accurate status.

Overall, I rate the solution a six out of ten.

My primary use case for the platform was the internal management of events, parsing, and enriching events based on lookup files. It involved creating sources and destinations, managing data processing, and serializing data.

The solution has streamlined our data management and processing, making handling event data easier and forwarding it to the required destinations. It has provided a robust framework for managing data flows and event parsing, improving our overall efficiency in handling large volumes of data.

The product's most valuable features include the internal management of events, coding perspective, data processing, and serialization.

The product could be improved in terms of its logging and debugging capabilities. The sys logging could be enhanced to make it easier to identify errors, especially when dealing with multiple functions. Additionally, the user interface could be more flexible for advanced customizations.

I have been using Cribl for over one year. In my previous position, I integrated it with Broadview and socket and SNMP for event management, forwarding events to BigPanda via webhook, and writing JavaScript code for event parsing and enrichment.

I rate the stability of this solution as six out of ten. While it is generally stable, issues have affected its reliability, especially with more advanced and customized uses.

The solution is quite scalable. It allows for performance extension by distributing workloads among multiple workers via a load balancer. This architecture supports different customer needs for small-medium companies or larger enterprises.

The support team is good and willing to resolve issues. However, they could improve their understanding of customer requirements.

The initial setup can vary in complexity depending on the integration. It is straightforward for well-defined formats like JSON or XML. However, customized integrations may require significant development effort.

The solution is well-suited for quick integrations and common data processing tasks. However, highly customized integrations might require additional development efforts.

I rate it a seven out of ten.