Cribl Reviews

I use Cribl for optimizing Splunk data. For example, I have approximately 10 TB of daily data integrations. I route the data through Cribl, optimize it, and index it into Splunk, reducing it by 30 to 40 percent. For instance, at 10 TB of integrations, it becomes 5 TB after Cribl optimization. I use Cribl for firewall logs, event logs, Windows logs, metrics logs, and EDR logs.

The feature I appreciate is the connection between Splunk and Cribl, which is very useful for routing data and pipeline filtering. Cribl has a central management system that controls all data pipelines and configurations.

Cribl works centrally by using the main Cribl instance and managing configurations, pipelines, routing routes, and all worker nodes. The leader nodes act as a central node and manage pipelines, route packs, and configurations while distributing them to the worker nodes. The worker nodes process actual logs and send the processed logs to destinations such as Splunk, S3, and other SIEM tools.

Cribl pricing is a concern. Cribl Streams is very powerful but costly as it scales with data volumes. For large and heavy systems, it becomes pricey compared to other similar tools. While it is flexible, it is not beginner-friendly. Pipeline routes and transforms can feel complex at first.

I have been using Cribl for my business for the last 1.5 years.

Sometimes Cribl goes down, and we miss logs during that time, which is an issue. I experience downtime with Cribl, and this is the only issue I face. Otherwise, we do not have any other issues. When there is downtime, we cannot get logs into Splunk, and based on those logs, we get alerts and crypto triggering repeatedly, creating multiple incidents and sending emails to our customers, which is very problematic during downtime.

Cribl is excellent for scalability. It is good overall for pipeline maintaining, horizontal scaling, distributed architecture, parallel pipelines, and load balancing. We handle real-time data with several GB of data per day and one TB of data, which is a very high volume of observability pipelines. Multiple pipelines run at once and different data sources process independently. There are no signal bottlenecks, and managing configuration is straightforward. Overall, it is long-lasting and good for stability and scalability.

As of now, I do not use any alternative to Cribl.

The initial setup is moderate. It is not too hard and not too easy. For experienced people, it is very easy. One person is enough for a Cribl deployment if you do not have a very large environment. Otherwise, you need different types of people at a large-scale environment. For beginners, it is moderate, neither too hard nor too easy. For experienced people, it is very easy because they have experience with it.

All the nodes and components can be deployed from start to end within a certain timeframe. A quick setup following the official guide from the documentation takes approximately one hour. Normally, production setup takes one to three days. The breakdown is approximately two days for deployment and configuration, and the third and fourth days for pipelines and testing. A full enterprise deployment at a much higher level takes one to four weeks, depending on the difficulties and architecture involved.

For the current user at a small level, the pricing is good. At a large level, it is not too heavy. The main model of pricing is based on data integrations at approximately $0.32 per GB for ST enterprise estimate. This is good and not too high or too low, falling within a medium-level range.

I have used Cribl Stream for filtering service logs, reducing data volume before sending it to Splunk, and enriching logged data with custom context.

Cribl features integration support since it works with 50 plus sources and destinations, data routing and flexibility allowing me to easily route telemetry to multiple destinations such as SIEM, data lake, and cheap object storage, and data processing and reduction because it filters out unwanted fields, removes redundant data, and restructures logs before reaching systems, which is helpful in saving cost and improving performance.

We have observed a 30 to 40% reduction in log volume hitting the firewall.

Cribl Stream handles a high volume of data very efficiently as it is designed to process log metrics and data from multiple sources in real time without major performance impact. We tested Cribl Stream with different types of machine data and even with large ingestion volumes, and the platform remains stable because of its distributed and horizontally scalable architecture.

I can assess Cribl's ability to handle high volumes of different data types, as it can handle multiple formats because it supports structured and unstructured data formats such as JSON, CSV, XML, and plain text logs. It processes and transforms data in real time with low latency. In our PLM environment, we had logs coming from multiple enterprise systems and services, and Cribl helped normalize and route those diverse logs efficiently before forwarding them to Splunk.

My experience with the user interface when managing log processing tasks is quite complex for new beginners, and there is also a documentation gap that leads new beginners to take a while to get fluency over the software.

Areas that have room for improvement include the complex UI for beginners and the documentation gap. One challenge initially was configuring pipelines and understanding parsing rules because of this gap, and I think there should be more plug-and-play integration examples for common enterprise tools.

I have been using Cribl for 13 to 14 months.

Cribl is a stable solution, and overall, I give it a 10.

Cribl's architecture is quite scalable because it horizontally scales whenever required, so I give it a nine for scalability.

I would rate the technical support as nine out of ten.

This is my first time using this type of solution, and I have not used any other alternative or competitor solution, so I am not aware of other options.

My team members mentioned that it was not difficult to deploy it; it was handled by two of our IT team members.

I find the pricing of Cribl to be cost-efficient because it has helped us save costs for data storage by removing unwanted logs.

I am aware of Cribl Search and its new search in-place technology, but I have not used it.

I am pretty new to Cribl and have only used Cribl Stream, but I am looking forward to exploring other products such as Edge, Search, and Lake.

I would highly recommend Cribl because it has been very helpful in cost optimization. I give this review an overall rating of 9.

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 for log management.

Cribl has the ability to send data to different destinations, making it a vendor-agnostic tool. For log management, we can parse values or enhance fields at Cribl level and then send it to different destinations such as S3, Splunk, Elastic, or other destinations. This feature is the one I love most because it acts as an intermediate heavy forwarder which can route data to different destinations.

Cribl is intuitive and user-friendly in navigating the UI.

Some of the integrations such as SNMP need improvement, and I feel Cribl should improve on SNMP integration and also on the database monitoring space. These two areas need improvement.

I have been using it for one and a half to two years.

Cribl handles volume of logs effectively. In case of any issues, Cribl support does their job in resolving the issues. Overall, it handles the volume of logs very effectively.

I rate the technical support for Cribl as nine out of ten.

Positive

Cribl is solving these issues and bridging the gap. There is Splunk which is equivalent to Cribl, but Cribl is currently leading in this space. There may be other alternatives, but they are still in evolving phase. Cribl is a mature product.

Cribl is easy to deploy. Spinning it up does not take much time, just about a week's time. However, getting the data in and configuring those destination sources will take time.

For scalability, I would rate it as nine out of ten.

I am not aware of the data cost. However, Cribl solves the complexity of having different agents installed. If we shift from Splunk to Elastic, we would have to get a new agent installed and point our applications to Elastic. With Cribl, it solves the complexity of having multiple agents in between and forwarding data. We can forward it to Cribl and then Cribl can send it to wherever we like. This kind of complexity is something it solves.

Big businesses use Cribl.

I assess the stability of Cribl as eight out of ten. I recommend Cribl for others looking to implement this product. I would rate Cribl overall as eight out of ten.

My main use case for Cribl is to send and process logs from our AWS network and multiple other cloud networks to an S3 bucket to store the logs as well as to stream the logs to other service providers like Logz.io where we will set up a logging and alerting platform.

A quick specific example of how I'm using Cribl in this process is that we have been using different types of logs such as Python from ECS and EKS Kubernetes-based logs, and all those logs are in different formats. We add all the logs from different streams to Cribl and then from there we add specific formats and add certain tags to those logs so that it is easy to format and set alerts at the logging level.

Cribl is very useful because we have multiple clouds and it has been processing our logs from multiple different platforms into a single one, and it is processing to multiple other platforms as well. It is used as a bridge to stream and process the logs.

One of the best features Cribl offers is that it runs on Kubernetes clusters, which is easy to manage and comes with easier upgrades. It is very compatible with container-based environments and supports multiple different types of logs. It has many connectors and can send to many endpoints. The workflow features are also strong.

The compatibility with container-based environments has made my day-to-day work easier because it supports Kubernetes. In day-to-day work it is mostly useful for container-based logs because we mostly run on Kubernetes and ECS. We are a completely container-based organization, so most of our logs are container-based logs and application-based logs. All those logs are easily processed from Cribl.

Cribl has positively impacted my organization in terms of efficiency. We used to run on Lambda functions in AWS, which is an older process, and we used to drop many of our logs, which was problematic because those are necessary for future use cases. Now everything is working well.

This has impacted troubleshooting and compliance in my team because we are able to keep the logs indefinitely. There is no drop in the logs and no loss of the logs. This has impacted my team meaningfully because we have all the logs, we have very strict monitoring, and compatibility with all of our standards.

I think Cribl can be improved because I do not believe it is a mature product. It has gone down many times and when we are doing upgrades, many things break and we face a lot of issues, especially with scaling. If the logs are high volume, most of the time it is down or some connectors are down and it is not performing as well as we thought.

Moving from version 3 to version 4 became very difficult during the upgrade. The scalability issue is very problematic. We are running on Kubernetes and there are a lot of issues with respect to scaling. When we have more logs coming in, the connectors are failing.

I would like to see other improvements with Cribl beyond scaling and upgrades. The product should be more mature and the documentation can be improved.

I have been using Cribl for four years.

Cribl is not really stable, although it may become stable. It is close.

Cribl's scalability is not great.

The customer support is also not great. They are connecting with us, but they are not able to figure out solutions very quickly. They may need more knowledge.

I previously used a different solution, which was Lambda functions. It was highly costly and it used to drop many of our metrics and logs, which was problematic.

I assess Cribl's ability to handle high volumes of diverse data types such as logs and metrics. I think it is feature-rich, but the scalability and reliability are major issues.

I am using the new search in place technology feature of Cribl Search, and the search is good. However, we need to go into the particular workflow and then from there we need to do the search. It is not a global search, which is not a good sign.

I have seen a return on investment. With respect to money, the savings are not significant. With respect to time, there is a little bit of saving, but because things broke during the upgrade, we needed to go back to the older methods of using Lambda. In terms of employees, we did decrease the employee count, but I do not know if Cribl is really the reason for that.

My experience with pricing, setup cost, and licensing shows that I am not completely involved in the pricing part, but I did participate in the setup part. Cribl provided an image and we used that image. It is also publicly available and it is not difficult to set up in a Kubernetes cluster. I think it is easy.

Before choosing Cribl, I was not part of the team which explored Cribl. I was already part of the team implementing Cribl. We used to use Lambda functions and then we moved to Cribl. I am not sure which other options were explored.

My advice to others looking into using Cribl is that if you are not a billion dollar company or if you are a startup that does not want to go into reinventing the wheel by writing all the code, Cribl is a great solution for streaming logs. I would rate this review a 6 out of 10.

We are using Cribl for log trimming with a vast majority of log sources that have different log patterns or log types. Some logs come in syslog format, some are in JSON, and some are in other HTML kinds of formats. We are using Cribl to streamline all the log formats and send the logs to Splunk, and we can also filter out the logs that are not required for us for security monitoring.

If logs from one device are sending us a lot of logs but we only need some events of interest for security monitoring, we can filter out the unnecessary logs and only forward those events of interest from Cribl to our SIEM solution.

Cribl has had a very positive impact on our organization. We are also using it for our cost cutting. The first benefit is cost cutting because we can filter out the unnecessary logs from the log sources, so we are only sending the events of interest to our SIEM solution for security monitoring. Most of the logs that are not necessary are filtered out within Cribl, which positively impacts the pricing of our SIEM solution.

The second benefit is that it has improved our security monitoring because Cribl is an augmented solution that can pull any log format, convert it, and send it to the SIEM solution. There is no requirement to have a specific log type to use Cribl. The third benefit is the filter option, which allows us to filter out the unnecessary logs.

In our organization, we are keeping the logging level of the firewall up to debug and forwarding all the logs from the firewall to our SIEM solution for security monitoring, so specifically for the firewall, we do not have any filtering in place in Cribl.

We can filter out the firewall logs if we keep the logging level up to informational, which would allow us to filter out all the debug logs through Cribl, which will definitely reduce the firewall traffic.

In our environment, we are handling around TBs of logs through Cribl, and it is handling everything perfectly fine. We have not observed any issues with traffic, log stoppage, system failures, or service failures related to Cribl, so everything is working fine.

The overall pipeline and the filtering option in Cribl are very good.

The complexity aspect is impressive; Cribl is already augmented and can receive any kind of logs with any format. It can handle almost all types of logs, which include Syslog, WMI, and all kinds of complex logs. It is particularly very good for complex logs where we have multi-line logs and large sources sending a significant quantity of logs; it is very helpful in that regard. Regarding the costing part, Cribl's charges are less than what we are saving in our SIEM solution, so ultimately, it is profitable for us.

Currently, Cribl is perfectly fine for us, and we have not observed any such issues. However, if we find anything later on, we will document it and share it with you.

Cribl could respond more quickly to email notifications to make the experience a nine or ten.

We have been working with Cribl for around eight months because we recently implemented it, so it has been six to eight months.

Cribl is a very stable product, and we have not observed any platform-related or internal service-related issues. It has been working fine since six to eight months, so we can say it is pretty stable.

We have not experienced any outages or crashes.

We can scale Cribl based on the log inputs we are providing. It is pretty much scalable, depending on when we want to scale it.

It has an option for scalability, so it is not an issue.

We often communicate with the technical support of Cribl.

They are very supportive and respond timely.

This is the first time we are using Cribl; previously we were directly sending logs to a SIEM solution. This is the first time we started using Cribl for that.

We were not personally involved in the implementation because there are multiple members on our team. One of our colleagues was involved along with Cribl resources to implement it. However, later on, once it was implemented, we got a chance to work on a few changes in Cribl.

In this particular area, we think Cribl is the only good solution partner, which is why we chose Cribl. There are no other applications that have that kind of capability like Cribl, as it is the industry-leading product as of now.

We went straight to Cribl and did not consider anything else.

We can share our feedback on Cribl.

We are a customer of Cribl.

Cribl is a pretty good solution. We did not face any challenges while working on Cribl.

Cribl is deployed on the cloud in our organization.

We are happy with the pricing that they offer.

Our review rating for Cribl is 9.

I use Cribl for data integration, pipelining, data monitoring, scalability, and to check how my monitor is working. The main product we use is Cribl Stream, which we use for log routing, filtering, and transforming data before sending it to our SIEM platform. This is the core part of our log management pipeline. Through Cribl Stream, we mainly work with features such as data pipelining, routing rules, and data transformation functions to control how logs move between different systems. My hands-on experience is primarily with Stream, since that is the component we rely on most for processing and optimizing log data in our environment.

The main product we use is Cribl Stream, which we use for log routing, filtering, and transforming data before sending it to our SIEM platform. Through Cribl Stream, we mainly work with features such as data pipelining, routing rules, and data transformation functions to control how logs move between different systems. My hands-on experience is primarily with Stream, since that is the component we rely on most for processing and optimizing log data in our environment.

One of the biggest advantages for my organization is better control over log data. We can filter, transform, and route logs before they reach downstream systems such as the SIEM platform, which helps reduce noise and focus only on relevant data. Another key benefit is cost optimization. By dropping unnecessary logs and sending only important data, we significantly reduce ingestion and storage costs in tools such as Splunk. It also improves operational efficiency.

One key area is simplifying the user experience, especially for new users. Since it has multiple components such as metrics, traces, and detectors, making onboarding and navigation more intuitive would be beneficial. One area of improvement could be reducing the learning curve. Since it is a very flexible tool with powerful pipeline configuration, new users may take some time to fully understand how to design and optimize pipelines efficiently. Another improvement could be more pre-built templates or out-of-the-box integration of common data sources, which would help teams get started faster without building from scratch. I also think enhanced monitoring and troubleshooting visibility for pipelines would be helpful, especially in large environments where multiple data flows are being processed.

The main strength is its flexibility, scalability, and cost optimization benefits. It gives strong control over what data is processed and sent to downstream systems. The reason I would not give it a ten is mainly due to the learning curve and initial complexity, especially for new users. Some areas such as documentation or advanced troubleshooting could be improved.

I have been working in the cybersecurity and security operations space for around one year.

Cribl is stable and reliable. I would rate stability and reliability at eight out of ten. In my experience, it is generally performing well.

I would rate the scalability of Cribl at eight or nine out of ten. Its ability to handle a high volume of different data types would get a rating of eight or nine out of ten. It is designed to process large-scale telemetry data from multiple sources such as firewalls, cloud services, applications, and infrastructure. It can handle different formats such as JSON, syslog, and custom logs, and transform them within the pipeline with its distributed architecture. We can scale horizontally by adding worker nodes, which allows it to handle increased data volumes without major performance issues.

We faced an issue with a pipeline dropping certain log events unexpectedly. We reached out to support, and they helped us analyze the pipeline configuration and logs. Initially, the response was general, but after sharing more details such as sample logs and pipeline rules, they were able to identify that the filter condition was incorrectly configured, which was causing the data to be dropped. They guided us on how to modify the rule and validate the data flow using a live preview, and we were able to resolve the issue very quickly. Overall, the support team was very helpful and knowledgeable, especially once the issue was clearly explained, and it helped us solve the problem without major downtime.

Before Cribl, most log processing was handled directly within the SIEM platforms, mainly using tools such as Splunk native and sometimes Logstash for data processing. The limitation with that approach was that all the raw log data was first ingested into the SIEM, and then filtering or transformation were applied afterwards. This increased the data volume and cost complexity. We moved to Cribl to introduce a dedicated data pipeline layer before the SIEM, which allows us to filter, transform, and route data more efficiently before ingestion.

As I am on the technical side, I was involved in the initial setup of Cribl. My role included configuring data sources, setting up pipelines, and defining routing and filtering rules based on our different requirements. I also worked on integrating Cribl with our SIEM platform, ensuring that only relevant and optimized data is forwarded. During the setup, we focused on designing efficient pipelines, testing data flow, and validating transformations to make sure everything was working correctly. Overall, the initial setup was not very complex, but it required proper planning to design the pipelines.

Other than this platform, it is more valuable. Before adopting Cribl, we did look at a few other approaches. Some of the evaluations were around using native capabilities within SIEM platforms such as Splunk, as well as open-source log processing tools such as Logstash for handling data pipelines. Those options can work for log collection and processing, but Cribl stood out because it provides a dedicated platform specifically designed for observability and security data pipelines. It offers more flexibility in routing, filtering, and transforming logs without heavily relying on the SIEM itself. The visual pipeline management and real-time visibility into data flow were also important factors that made Cribl a better fit for managing large volumes of log data across multiple systems. We saw other options, but by way of references, we determined that Cribl is more relevant for our work. So we chose Cribl.

I would recommend starting with a few simple pipelines, then gradually expanding as you become more comfortable with the platform. I would rate Cribl eight out of ten. A few improvements in Splunk Observability Cloud could make it even better. Overall, I would give Cribl a rating of 8.5 out of ten.

My current use cases for Cribl involve how the telemetry data moves. We have instrumented our observability backend related services, which we use specifically for our business logic. Basically, how it works is there is something called Autopage where we have all the details of whatever data was just coming in terms of from the adapters of AWS. There, we have Cribl deployed even when no queue queue Kubernetes cluster exists. We have these things and we're very well organized. Most of the use cases are on Kubernetes where we have better observability because Kubernetes generates a lot of traces, and manually, it is very difficult to manage all these things. Cribl plays a good amount of role to summarize everything properly provided all the information.

What I like the most about Cribl is that it extracts the spans very well. Honeycomb does the same thing, but Cribl does it a little bit better than that. We can route one stream from too many destinations with no problem. We have configured a center table easy instance, and we have also tried with the cloud solution. When we send the data in, it just gets extracted in different telemetry solutions such as signals and data doc. It provides all those enriched data with all the details. For example, we gave user ID as one of the attributes we wanted, and it mapped email on top automatically. So it becomes very easy to identify which customer has a problem during incidents and other things.

I'm not the right person to ask this because I only configured it for providing certain specific things. If I say one negative thing, the setup is a little bit trickier because observability setups are generally trickier.

I have been using Cribl in my career for six and a half months.

Regarding stability, I don't really face any lagging or crashing, but that comes with not a lot of data being injected there. If a very high cardinal solution or high cardinal metrics goes in, there might be some issues, but I haven't faced any problem that way till now.

Scalability, stability, and reliability can only be judged when you have a huge amount of data. Our current organization doesn't deal with a huge amount of data. What we have is around two hundred to three hundred GB of data that we are moving daily. Out of that, whatever telemetry we are getting from our total collector, there's something which we are directing to this, and this is providing to our other solutions out there such as Datadog and Honeycomb. Basically, we are not facing any problem as of now in terms of stability, reliability, and scalability.

In terms of technical support, I have not had to contact them about anything. Technical solutions are shifting now. People are more identifying things on their own, and we have a lot of solutions coming, so it's very easy now.

The initial deployment setup of Cribl was relatively easy for the first time. This comes after a certain new experience that I have. For a very new person who doesn't understand much about observability, it might be a tricky solution. When you are working with an OLTP kind of solution, versioning, pipeline, learning, and coverage are important parts. Once you have that, everything works accordingly. You just have to figure out how it will work.

I really enjoyed working with the open telemetry collectors. I have tried with some AI-related implementations. We have a vector database in the backend, and it has given us a good amount of data transformation depth, which was really good. That has given us more usage context for what we are providing to the AI model. This is a service what we had in AWS Bedrock where we were running an NLM solution. That has given us good amount of insights whether this is properly working or not. The only problem was there was no token count. For that, I have to use some different solution. For a specific integration, I would be very happy if I could get some other solution which provides me the token information also. How much token I have been consuming is not there right now in any of the auxiliary tools. I have to do it via some other aspect. No complaints with Cribl. Cribl actually has sorted out our problems, but it will probably be better.

For the deployment of Cribl, I have done the complete deployment without anyone's help. I took some documentation that they have and used it for certain structural things. For our department's sake, I deploy our changes directly without any problem.

I have seen a decrease in firewall logs with Cribl. Sampling is enabled and definitely that is something which I have actually seen a good amount of reduction in. The logs are really high, so what we had previously because a lot of those kinds of things happen on the valve, followed by a lot of things that happen on our product. Because of that, the logs get filled up very fast, and we store all those logs in history. When I compared the situation after Cribl and when we actually validated whether the amount of logs in the history compared to what they were before, the growth results significantly decreased. I don't have a number in mind right now, but I have documented it somewhere.

Regarding the pricing of Cribl, I'm not the right person to talk about pricing because all these things are taken care of by our VP of engineering. I suggested them to ship also, and then we are on a pilot with them. We have not paid any money to them yet. With respect to this current Cribl implementation, I am not hundred percent sure what we have actually done. I can answer the technical aspect of it, but the financial part is something that's out of my scope right now.

When it comes to using any similar solutions to Cribl, there are not really alternatives. We have used Chip, if you have heard of it. But the use cases are a little bit different. Chip is something which provides more enhanced metrics on top of existing metrics of what we have. So we don't have to look at ten different metrics, and we can use this. They have run a pilot with us a while back, but they are focused mainly on Kubernetes clusters, whereas our solution is more tied to the instances and other things. These are not a cluster mode running. In our case, it has given us significant value.

Regarding Cribl's ability to handle high volumes of diverse data types, for logs, it is something we have used. We have used it specifically, and I'm not saying I know how to use it completely, but not that much, to be honest. It's okay what we have done.

In my experience with Cribl's new search in place technology, Cribl search, I find the user interface when managing log processing tasks to be decent. I don't have any complaints.

I would give Cribl an overall rating of eight out of ten.

I use Cribl for filtering service logs and reducing data volume before sending to Splunk to cut storage costs, and it is mostly for logs sharing while I am working in the PLM environment.

I have experience with Cribl Stream, and in that, I appreciate data routing, data processing, and reduction because it filters out unwanted fields, helps in removing redundant data, and has good integration support.

I have observed approximately 60% reduction in firewall logs.

Cribl was able to handle the volume of different data types, such as logs and metrics, and that is why I found it valuable. It is a good monitoring tool, and although there is a steep learning curve, once you gain hands-on experience, it is quite good.

I save roughly around 30 to 50% of operational time in log handling and everything.

I find it quite stable, and I would give it a nine.

Scalability is highly achievable with its distributed leader-worker architecture, so I would rate that a ten.

I would definitely recommend Cribl to other users because it has helped me reduce my log handling time by 40 to 50%, and it also reduces the log volume by 30 to 40%, which cuts storage and SIEM costs. Additionally, the good real-time data processing filters and transforms the data before sending it to the tools. I would definitely recommend it to new users or prospective users.

When I started using Cribl interface for managing log processing tasks, it was difficult for me to navigate because it took me a month or two to gain fluency with the software since I did not have hands-on experience initially, and I found that the documentation is not thorough enough to help users navigate how to use Cribl.

The areas that have room for improvement include the documentation because it can be improved, mostly the documentation. Otherwise, I appreciate Cribl Stream, and for new users, it should be easier to understand and learn how to use the tool and how it can help them.

I have been using Cribl Stream for one year, 13 to 14 months.

I find Cribl quite stable, and I would give it a nine.

Scalability is highly achievable with its distributed leader-worker architecture, so I would rate that a ten.

I would rate the technical support an eight.

I have used DataDog, and I find that Cribl is more about controlling the data before it reaches the tools, while DataDog is more about analyzing the data after it arrives, so there is a clear difference between both tools. However, it really depends on what you are using it for.

It is not on-cloud; it is a hybrid model for deployment.

Cribl does require maintenance, and that part is also maintained by one of our team members who handles the versioning, maintenance, and any new releases, so it is pretty taken care of, and I have not heard a complaint from him about anything, so it must be good.

I do not know about the pricing because I have not purchased it, as it was given to me by my organization.

I have not used Cribl Search yet, which includes the new Search in Place technology.

I have used Cribl Edge once; it is a data collection agent, but I have not used it that much as I mainly use Cribl Stream.

There are roughly three to four users using Cribl right now; it is a small team of people.

I would give this review an overall rating of nine.

I'm a SIEM engineer and we use Splunk and other SIEM tools. Since other SIEM tools are too expensive and security teams need different data to come into their SIEM tools, Cribl helps us filter out unwanted logs coming from syslog devices and other networking devices, which saves our license. We save around 2.2 TB every day using Cribl. All our logs go to Splunk, and we have Cribl positioned between our log sources and Splunk as the main function.

We also use Cribl for filtering and sending data to different outputs. One output is Splunk, and others include Kafka topics and different source sites like Pub/Subs, HEC endpoints, Google Pub/Sub, and Amazon S3 buckets for long-term retention of certain logs.

Recently, I have not yet worked with Cribl Cloud in production, but I had an opportunity to get hands-on experience with their lab environment.

I loved the way they created their cloud and their AI capabilities are good there. Another valuable feature of Cribl on-premises is the way it helps us filter out logs. It's a very easy tool to understand for someone new to these things, and it's easy for us to explain to new recruits we hire.

Firewall logs contain a lot of entries that security teams and audit teams don't require. We use filtering and regex in Cribl to remove unwanted logs that no one requires, such as entry logs and in-and-out logs that the syslog and firewall device would send anyway. We only need the threat logs and security logs. We save around 1 to 2 TB of logs every day using Cribl.

Regarding complexity, as I mentioned before, Cribl is very simple to use. When I started 2.5 years ago, it was very easy to learn. I learned Cribl within a week, and even though I was a fresher at the time, it was easy to understand and not complex enough that someone would need to spend money on labs. It's not that complex to learn.

Regarding cost efficiency, it's very good because nowadays the SIEM tools we use are too expensive on license, and SIEM tools base their license on how many logs get ingested. The unwanted logs, particularly firewall logs, represent a significant portion of unnecessary ingestion. Cribl saves our license by filtering out half of the firewall logs that are unwanted. Our main purpose for using Cribl is to save our license and save money.

Currently, everyone is moving toward AI agents. We currently use regex, and AI agents could help us create those regex patterns to drop events or add raw data to events. Currently, we sit down, review the logs, and create regex patterns manually, which can be time-consuming. An AI agent could reduce this time. I read some articles indicating that Cribl Cloud has started using AI and considering MCPs and model context, but I'm not certain how far along they are. If Cribl asked me what they could improve, that would be my suggestion. The support is very good, and I had a few issues with Cribl where I raised support cases and received good responses, which is better than the quick response I didn't get from other SIEM tools and vendor tools I use.

Compared to other SIEM tools, Cribl is cheaper than Splunk and DataDogs. However, it's still a bit expensive from my point of view, though I won't call it expensive. Overall, I think 99% of companies use Cribl before their SIEM tools, and compared to SIEM tools, Cribl is cheaper. Companies can use any SIEM tool such as Google, Splunk, or Cisco, and Cribl is cheaper than those SIEM tools. They might have a slight chance to reduce costs further, but I'm not the correct person to evaluate that since I'm more focused on the operational side.

Regarding training, it was quite easy to grasp. It took me almost a week to understand the basic functionalities and what Cribl does. Getting more expertise took additional time, but basic functionalities and understanding what Cribl does took around four to five days. One point I want to mention is that Cribl could improve their labs or training materials in their Cribl Cloud or whatever portal they have.

I have been using Cribl personally for around 2.5 to 2.8 years. My company has been using it for a longer time, but I joined the company seven months ago, so my hands-on experience with it is around 2.5 to 2.8 years.

Regarding the metric part, I haven't worked much with it, so I can't tell much more about that. However, regarding log volume, it's very good. I have personally used Cribl with 10 to 12 TB of data per day in 24 hours, and I have not found any problem with log latency or ingestion issues, or Cribl not being able to handle this volume. I have not faced such issues on the logging side. On the metric side, I'm too new to provide an answer.

Currently, I haven't seen any instability or latency issues. We tried to boost logs from 4 to 5 TB up to 7 to 10 to 12 TB, and we didn't find any lagging or Cribl going down. We found initially negligible latency, but with the help of their support team, we figured out how to improve our latency. Till now, I haven't seen any outage or severe outage that would require a serious discussion about needing a resource to maintain Cribl. I don't recall the last time we maintained Cribl or checked how it's running. Maintenance is very rare.

Cribl scales very well. I'm not entirely certain about the license aspect since it's based on how much log volume we put in. Initially, we had around 3 to 4 TB of license ingestion, and then we increased it to 8 to 10 TB. We raised a request to increase the license and got a new license with 8 to 10 TB of logs per day ingestion capacity. We were able to scale it very quickly without much effort required. That was a doubling from four to eight or 10 TB, but I have never tried scaling beyond that, and I haven't heard people complaining that Cribl cannot scale up.

The best part about Cribl from a scalability point of view is that it doesn't require much operating system configuration. Otherwise, we need to check every time those servers get patched, and we need to verify that anything changed on the operating system doesn't affect Cribl. That's not happening with Cribl. Any small issue on the operating system end also doesn't impact Cribl. Compared to other SIEM tools I use, any slight change on the operating system end impacts a lot on our SIEM tools and other things, but Cribl performs well in that regard.

The support is very good. I raised a few Cribl support cases for issues I encountered and received good support from them. This is better than the quick response I didn't receive from other SIEM tools and vendor tools I use.

Positive

We have not used license-based tools previously. We tried using Logstash and Fluentd, which are open-source tools, but only for demo purposes. Since those are open-source tools, we cannot compare open-source tools with license-based tools. I never had a chance to work on any license or vendor tool related to Cribl before.

We check the latest version of Cribl and upgrade to the latest version or whatever version we are comfortable with if a new version is available. Overall, we don't see any regular maintenance required. We are using Cribl on our virtual machines, and one good point is that Cribl doesn't require much operating system configuration. Basic operating system configuration can run Cribl. Compared to other SIEM tools that need legitimate operating system configuration and their operating system kernel versions, Cribl is quite friendly in that regard. Simple basic operating system configuration works, and Cribl doesn't need regular maintenance where we need a resource running maintenance tasks every day.

From an engineering view, I would rate Cribl nine out of ten. I'm not certain about the license and pricing aspects, which is the one thing I consider. Overall, I enjoy working with Cribl and would give it an eight to nine rating. However, I'll give it an eight because there are always points of refinement, and nothing is perfect. My overall review rating for this product is eight out of ten.