Cribl Reviews

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 the SIEM, and we use it to route data to multiple destinations. It is useful for that purpose. Whenever a customer is migrating from one SIEM tool to another, Cribl is useful there.

For me and my customers, we have used Cribl to reduce the logs and optimize the ingestion. We use it to convert the data in a very optimized form, which impacts a lot and reduces the storage and other licensing costs in the destinations.

I like the UI, as well as the live search feature which I find most valuable. It allows routing data to multiple destinations, which is also a feature that I appreciate.

The UI of Cribl is very intuitive. For most of the products I have used, it is one of the best in Cribl.

I have used Cribl with multiple other vendors such as CrowdStrike and Splunk, and Cribl is one of the best among all their competitors. That is the main USP.

I have seen a decrease in firewall logs with Cribl. My estimate is a 40% decrease.

On average, we have noticed a 40% reduction in licensing costs.

It helps to save a lot of resources because when you reduce 40% ingestion, typically if the destination is Splunk, and Splunk has a significant license cost. If we reduce 40% of the ingestion, we will totally save 40% of the amount we pay to Splunk. It allows us to move between multiple vendors. If you want to migrate from Splunk to CrowdStrike, and we are using Cribl in between, it is very easy to migrate. This will save us a lot of resources.

For most cases, Cribl is fine. I have noticed performance issues when a large scale of data ingestion happens, typically in TBs of data. Then a little bit of performance issues I have faced, but this is for very large scale customers.

If we compare Cribl's ability to handle high volumes of diverse data, such as logs and metrics with its competitors, I can say its performance at a very large scale ingestion is the best, but it can be better.

My production experience with this solution is more than two years.

Cribl's stability is a 10 on 10.

Scalability is also a 10 on 10.

For technical support, I will rate it at seven out of ten.

The knowledge base is a 10 on 10, but the response time is slow, which is why I rate it seven.

Positive

Currently, Cribl does not require any maintenance. However, for every upgrade that Cribl provides, maintenance is required at that time only, not regular maintenance. It is very easy to do that maintenance; it is just a simple click of a button.

Mostly we have worked with Cribl Stream and Edge features. It is very easy to use the fleet management in Cribl Edge. It is easy to deploy on the endpoints and connect it to Cribl Stream.

It is typically the same as what competitors' platforms provide, but if we are in the Cribl ecosystem, this Edge fleet management is a must. I am totally in favor of it. I would totally recommend this to others.

Our use case for Cribl is actually a data pipeline where we collect logs from the source and we stream it through Cribl and then to a destination. The destination is mainly the SIEM tools such as CrowdStrike or SecOps. We collect the logs from various sources, and even the Windows logs are streamed through Cribl worker nodes and data lakes. For example, if it is AWS, from the S3 bucket we stream to Cribl and then send it to Google SecOps, which is the primary SIEM we are using.

The best feature in Cribl, when getting logs from some custom application, is the ability to break up logs that pile up together and come as one event. 

Cribl has a feature called JSON Unroll or Unroll function that allows you to differentiate the events; each event will come ingested as a single log instead of piling it up with multiple events. This is critical as this generally happens in CrowdStrike. This feature helps us significantly.

When the ingestion is high from unwanted logs, logs not related to security purposes can be dropped by writing the parser function. By dropping events that are not required for security purpose monitoring, we can reduce the ingestion, which drastically reduces the cost as well. Cribl gives another option where I can store some logs, and when needed, I can pick them up from there.

The interface is very handy and not very complicated, yet there are many functions you can perform. You can play around with numerous functions, parse there, and add UDMs to SecOps, which makes it really easy.

To simplify the pipeline, when we go to the pipelines, there are vast options. We can make it specific requirements based on the customers. I would prefer a customized or simplified version. Cribl is a very good platform to work with, with lots of features that other platforms don't provide.

Cribl is a stable product, however, there are areas for improvement. Their documentation should be updated.

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

Cribl is a stable product, but there are areas for improvement. Since Cribl is on-premises, server maintenance is required, and we have an IT team specifically to look into that. We are not worried about that.

There is a similar platform by Google called BindPlane, which is not capable of handling high volumes of data as the data gets stuck in the pipeline, causing ingestion delays. 

However, Cribl does not present that problem. Since I have worked with both data pipeline tools, I can compare and say that Cribl is more mature than others.

I have not reached out to Cribl support. That said, my colleagues have.

Positive

I'm using another product called BindPlane, which does almost the same things; however, Cribl is a very mature product with many functions. You can use the Eval function, Unroll function, break events, add any particular field you want, or parse in Cribl before sending to a destination.

The initial setup involves dropping some events that are not required for security purpose monitoring. This is based on suggestions from our SOC team or customers.

The deployment itself is a bit compicated and the documentation is not very clear.

We are a partner with Cribl. We have CrowdStrike, and CrowdStrike has partnered with Cribl; they even changed the name to CrowdStream.

It has saved my cost and our customers' cost drastically since I cannot drop the logs directly in SIEM. In Cribl, I can drop the logs, and when I'm not ingesting them, their licensing cost is drastically reduced.

Cribl Search is quite handy; you can use regex where there's a function that contains, and you can search for a specific keyword, which shows everything that matches that keyword. After playing around a couple of times, it becomes easy. At first, it is complicated; you need to go to worker groups, select the data lake, select the worker node. Once you get used to it, it's quite handy. I would definitely recommend Cribl to other users. 

Based on my experience, I would rate Cribl eight out of ten.

Our main use case for Cribl was SIEM migration, where we merged multiple SIEM solutions to a single SIEM solution. SIEM migration was the most major use case we were looking for. The second use case was a manageable logging solution which could have a nice interface and would be easy to manage. Data cutoff or Log Filtering was the third biggest use case we were looking for, where we were seeking data reduction to define what we need and don't need. Additionally, we performed data masking for PII i.e. payments and medical data. These were the main use cases that were all provided by Cribl.

My previous company did a significant amount of business using Cribl, particularly in servicing customers who had a perfect fit for the solution. From a consultant's perspective, I can say that we resold licenses for Cribl, delivered services related to Cribl, and also provided maintenance services. This brought a decent amount of business to our company.

Regarding the reduction in firewall logs due to Cribl, it did influence our overall data processing and workflow. For example, the AWS VPC flow logs were greatly reduced in size, which had a substantial impact on the licensing costs for destination platforms. It did help us and the customer quite a bit. Cribl's role in its reduction of firewall logs, either cloud or on-prem, was vital.

The data cost is an important aspect. Cribl is specifically designed to reduce the data costs associated with the destination platform. This is one of its core offerings.

Regarding platform usability, the Cribl interface is quite intuitive and easy to use. The navigation and seperate sections are easily accessible, making it very user-friendly. The color scheme and palette are excellent, and there’s nothing messy or unmanaged about the user interface. Overall, I personally find the user interface to be very comforting.

The features of Cribl I have found most valuable include its SIEM migration capability. It facilitates migration quite nicely. The data reduction and preprocessing capabilities make Cribl really unique. Data masking is an important one. And as Cribl Stream can be deployed on-prem, on cloud or as a hybrid model, its support for every sort of enterprise estate is highly appreciated.  

The UI interface is very good. It's user-friendly, intuitive, not complicated, and sufficient. It's not more than what it needs to be, and it's simple without being overly complicated.

They've already done many good things with the product, but perhaps they could implement a temporary SIEM solution where we could store logs and display them as a SIEM, though I think that's not the space that Cribl is actually looking into. Based on my experience, this product is brilliant and there isn't much or anything important lacking in the product.

We encountered some occasional issues with the syslog data stream, particularly when handling large data volume, and getting it to parse and field extracted correctly, but no major alarms that would halt the days operation. There were few source vendor specific challenges, but overall, I didn't notice anything major beyond that. Most of the process went smoothly. However, we did need to carry some troubleshooting to resolve the issues we faced while connecting with other platforms and few data stream miss-behaving, which wasn't a straightforward task for us. In terms of large datasets—whether they originated from network inputs, virtual machines, or cloud instances—ingesting the data into the destination was relatively easy. In summary, aside from the usual difficulties or issues that someone could face with any project, everything else went well.

I have been working with Cribl for more than four years now.

Cribl is quite stable and doesn't crash; there's no unusual behavior. If it's stable, then it's reliable. I could see the data that goes in and how it is being processed at each stage. There are no concerns when Cribl is working in production environment.

Cribl is quite scalable, as we could add worker nodes as our data grows, so it's sufficiently scalable and able to facilitate as much data as there can be.

Their technical support has been really great, and solution architects we worked with were really knowledgeable. They had extensive expertise with the product and were able to facilitate with everything we needed. The experience with Cribl technical staff has been one of the best.

Positive

For similar use cases, different companies were using different tactical solutions i.e. custom scripting. None of the solutions were strategic and well thought through. Some were using scripting, some were not utilizing anything. Some were ingesting into the SIEM and then doing all the tasks which should be done pre-ingestion. There was a lot of disorganization, and Cribl had really found the gap where they could offer their services.

I performed the entire setup of the Cribl infrastructure.

With the Cribl Stream setup, I first had to initiate the tenant. Once the tenant was provisioned, I configured IAM setup i.e SSO, RBAC etc. I onboarded the data sources and deployed the worker nodes to the appropriate locations. These locations could be various subnets, cloud virtual machines, on-premises virtual machines, or any ready-to-use Cribl cloud workers  we needed. The process depended on the company's IT infrastructure. After the worker nodes were set up, it was simply a matter of onboarding the data stream into the platform and then directing it to the destination platforms.

As for Cribl's deployment, it operates in a hybrid environment, utilizing both cloud and on-premises solutions, tailored to meet the needs of different customers.

I delivered Cribl services as a Certified Cribl Consultant to various customers. Cribl technical support was arranged whenever there was a need for it.

We have managed to save significant money and resources for multiple customers, reducing operational complexity and the cost of destination platforms but unfortunately I cannot quote specific numbers due to NDA. 

Cribl is very inexpensive, with enterprise pricing around 30 cents per GB, which is really decent. Organizations looking to ingest terabytes or petabytes of data each day find it quite an inexpensive solution. The pricing model for Cribl Stream is one of the best values that customers would be getting, and I don't think any other solution offers this much value at this price point.

Confluent was considered, but Cribl emerged as the best solution.

I would rate Cribl an eight 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.

Cribl's main use case in our company is log routing and data optimization before sending it into our SIEM platform. In our environment, we collect logs from multiple sources like endpoints, applications, and infrastructure, and Cribl helps us process the data in the pipeline before it reaches the SIEM. We can filter unnecessary logs, transform fields when needed, drop unnecessary fields, and add necessary fields from eval functions through pipelines, then route the data to different destinations depending on the use.

In our environment, for log routing and data optimization in our pipeline using Cribl, we were receiving firewall data from different parts of the country. The issue was related to time zone differences. We had to convert the time zone of all the firewall logs into GMT format. We used Cribl's pipeline to convert all the firewall logs, which were in different time zones, to GMT time zone, and then routed it to our main SIEM platform.

The best features Cribl offers include the ability to see the data flow right away when the data is flowing. Capturing live data was a very good feature. We get pretty much different functions to transform data in the pipeline. Another feature we really like is the pipeline-based processing, where we can easily create rules for parsing, masking, or modifying log fields.

Seeing the live data flow with Cribl has definitely been helpful. It makes it much easier to see how logs are moving through the pipeline in real-time and understand where transformations or routing are happening, or where the data is breaking, or where the error is coming from—whether it is from the source only or breaking at the pipeline. There was a situation where we were not seeing certain logs reaching our SIEM platform, even though the source system was generating them. Using the live data preview in Cribl, we were able to trace the logs through the pipeline and quickly identify that a filtering rule was unintentionally dropping some events. Because of that visibility, we could adjust the pipeline rule immediately and verify the fix in real-time. Instead of spending a lot of time troubleshooting across multiple systems, the transparency in the data pipeline really speeds up debugging and operational monitoring for us.

Cribl has had a positive impact on our organization mainly in terms of better control over our log data and improved efficiency in our log management pipeline. Before using a tool like Cribl, a lot of raw logs would directly go into SIEM, which could create noise and increase ingestion volume. With Cribl, we are able to filter unnecessary events, transform logs, and route data more intelligently before it reaches the SIEM. This helps ensure that the security team is working with more relevant and structured data, which improves analysis and detection workflow.

Cribl is a very capable platform, but one area where it could improve is the learning curve for new users. Since it offers a lot of flexibility in building pipelines and transformation, it can take some time for beginners to fully understand how to design efficient pipelines. Another platform we have used provides a workflow-like UI so you can directly configure the source, the pipeline, and the destination, which we think Cribl is lacking here. We know there is a Quick Connect option also, but it is not that much efficient in our perspective. Another improvement could be building more built-in templates or pre-configured pipelines for common log sources. That could help the team get faster, especially when integrating new data sources. Also, while the platform provides good visibility into data flow and enhanced troubleshooting and monitoring, insights for pipeline performance could make debugging even easier in larger environments.

One thing that Cribl could improve is the workflow creation of source, pipeline, and the destination, which we still feel is lacking in Cribl.

Cribl is generally a stable platform, especially when it's properly deployed and monitored. It is designed to handle large volumes of telemetry data like logs and metrics, and many organizations run it as a central data pipeline without major downtime issues.

Cribl is quite scalable, especially for environments that handle large volumes of logs and telemetry data. The architecture allows you to scale both vertically and horizontally, depending on the workload. For example, you can scale up by adding more CPUs and memory to a single instance or scale out by adding more worker nodes to distribute the processing load across multiple systems. This distributed worker architecture helps handle increasing data volumes and more complex pipelines without significantly affecting performance. Another advantage is that the load can be balanced across worker nodes, which allows the platform to process very large streams of data efficiently and maintain high throughput. Cribl scales very well for enterprise environments where log volumes keep growing and multiple data sources need to be processed simultaneously.

Cribl's customer support has been quite good whenever teams run into issues or need guidance with pipeline configuration or deployments. The support team is generally responsive and knowledgeable. Based on what we have seen and heard from other users as well, support tickets are usually handled quickly, and the team tends to understand technical problems well, which helps resolve issues efficiently.

Positive

Before using Cribl, most of the log processing was handled directly within the SIEM platform itself, mainly using native parsing and filtering capabilities in tools such as Splunk. While that works, it means the raw logs first get ingested into the SIEM, and then you handle the transformation or filtering afterward. The reason for moving toward Cribl was mainly to introduce a dedicated data pipeline layer before the SIEM.

Before adopting Cribl, we did evaluate a few other approaches. Some of the evaluation was around using native capabilities within SIEM platforms like Splunk, as well as open-source log processing tools like 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, routing, filtering, and transforming logs without heavily relying on the SIEM itself. That is why we chose Cribl over any other platform.

In terms of the setup, the initial deployment was not very complicated, especially if you already have experience with log pipelines and SIEM integrations. Most of the effort usually goes into designing the pipeline and configuring the routing and transformation rather than licensing or installation itself. Overall, the model feels fairly aligned with modern observability tools, where you can scale usage based on your data volume and infrastructure needs.

We have seen a positive return on investment from using Cribl, mainly through better data control and operational efficiency. One of the biggest benefits is the reduction in unnecessary log ingestion into the SIEM. By filtering and routing logs through Cribl first, we avoid sending low-value or redundant data downstream, which helps optimize the storage and licensing costs.

One noticeable outcome from using Cribl has been better control over the volume of data being sent to the SIEM. By filtering unnecessary logs and routing only relevant events, we were able to reduce the overall log ingestion volume, which indirectly helps with storage and licensing costs. Another improvement is in operational efficiency because the data is already cleaned and structured in the pipeline, making it easier for analysts to search and investigate events in the SIEM, which can speed up investigations. The licensing cost is saved via Cribl.

Another feature that we found very useful about Cribl is the ease of integration with multiple destinations. We just have to route the main pipeline to multiple destinations, and it will go to multiple destinations. Sometimes the data needs to be routed to different platforms for security monitoring, observability, or long-term storage. Cribl makes it very easy to send the same data to multiple destinations with different processing rules. We also like the flexibility in data transformation. If log formats change or we need to mask sensitive information or normalize fields, we can handle that directly in the pipeline without modifying the source system.

The pricing and the licensing model for Cribl seem quite flexible, although the purchasing was handled by our organization rather than by us directly. Our role has been more on the technical and operational side of using the platform.

Cribl can handle high volumes of diverse data types like logs and metrics quite well. In environments where you're collecting logs from many different sources, the platform is designed to process and route that data efficiently through pipelines. We found useful its ability to apply filtering, parsing, and transformations at scale, which helps manage large data streams without overwhelming downstream systems like SIEM platforms.

Another useful approach is to leverage the documentation and built-in pipeline functions because Cribl provides many ready-to-use processing capabilities that can save time.

Our advice would be to start by clearly understanding your data pipeline requirements before implementing Cribl. Since it is a very flexible platform, it works best when you know what data you want to keep, what data you want to filter out, and where the data should be routed. We would also recommend starting with a few simple pipelines first, then gradually expanding as you become more comfortable with the platform. We give this review a rating of eight out of ten.

A few use cases for Cribl include mainly reducing the amount of data that goes into our CM solution by reducing the data that flows through and only sending the important data into our CM solution.

With Cribl, I have seen a decrease in firewall logs as we send a lot of firewall logs into Cribl, aggregating and reducing the log size by aggregation or removing unwanted data, which works smoothly. Anything with logs—firewall, network logs, DNS logs—works fine.

Cribl does a great job at containing data costs, which is our major use case to reduce data costs for the CM solution, and we do that quite efficiently with Cribl by aggregating the data, masking unnecessary parts, and changing the structure into key-value pairs, thus reducing the cost significantly.

What I like about Cribl is that it is quite easy to use because everything is via UI, so there is no coding involved, making it more like a drag and drop functionality to add your items. It is an easy tool, easy to learn, and handy, allowing a lot more to be done without requiring extensive coding.

Cribl UI feels quite intuitive based on my experience after using Cribl for four years with my team and other vendors. It is easy to use, allowing many people to work at the same time, and versioning is already integrated. The same packs can be used with different machines and different workflows, which is also a good part. Cribl provides free education, unlike other tools, allowing us to learn the necessary skills and implement them in the actual production environment.

Cribl brings significant benefits like cost-effectiveness, reducing CM costs, and making our data vendor-agnostic since data flows through Cribl. If I decide to change my CM solution later, it will be an easy switch. Complex data can be simplified into easier formats like key-value pairs, making our current use cases streamlined.

I would like to see improvements in the metrics and traces, as Cribl is currently more geared towards logs, making it hard to get very long traces to view in the UI when they are quite big. I have not used metrics much because I am aware of the issues Cribl has with handling proper metrics, particularly with multi-metrics when there are multiple dimensions into a single metric. We use Cribl nearly 99.9% for logs only, not for metrics and traces, but I hope to see improvements in the future.

On the other hand, I would like to see improvements in pack management, which is currently a mess with no way to manage packs differently across worker groups. I also wish Cribl would introduce more functions, as sometimes we have to create more JavaScript functions ourselves. Aside from that, everything is going well, especially with recent AI integrations.

I have been working with Cribl for four years.

Cribl is pretty stable, with me experiencing only minor hiccups and no major alarms. Previous data loss issues have been resolved over the past two and a half years, making it a stable option.

I consider Cribl scalable as we are using the Kubernetes version, and I have seen that scaling is manageable. We have also checked on-prem and found similar results, confirming it to be a scalable solution.

Cribl technical support is generally good, albeit sometimes inconsistent. The U.S. team is excellent once a ticket is escalated, while the support in Germany or Europe could be improved. I would rate the technical support at a seven on a scale of one to ten.

Positive

Prior to Cribl, I had not used any different product of the same kind, which is an advantage for Cribl. While there are a few products emerging now, the last time I checked, they were not equivalent to Cribl.

Cribl initial setup was not complex because Cribl is very similar to another product we used for multiple years, allowing us to extend scripts easily. I would say installation is pretty straightforward, and the documentation and education provided by Cribl greatly aids the process.

Our deployment was primarily in-house, with initial assistance from Cribl engineers. We have managed it internally for the last three and a half years.

Regarding ROI, Cribl reduces our CM cost by about twenty to twenty-five percent due to the data that is flowing in and reducing the overall amount.

I did not evaluate any other options before choosing Cribl since there was hardly anything on the market like it at that time, although I see a couple of viable options now.

My advice for organizations considering Cribl is that it is a nice tool, very effective with limited competition, but you should plan thoroughly regarding your use case to avoid wasting licenses. It is essential to implement something significant, considering the infrastructure as well. I rate Cribl at an eight overall.