Cribl Reviews

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.

We mainly use Cribl for data optimization and log reporting to clean up the data and determine how to pass and provide this data to Splunk, which we are using. Cribl serves as a pipeline for us.

Cribl has impacted our organization very positively. Our management team was previously very concerned about costs. If we were using the traditional method, we would be giving every log to Splunk, and it became very messy and tough to handle. Because of Cribl, we have experienced very high impact in cost efficiency, data clarity, and data optimization. It has been a very big impact.

The best feature is data cleaning and data optimization, which has reduced our costs significantly. Cost optimization can be counted as one of the valuable features.

My experience with the UI is very decent compared to others, and it is very good.

Cribl handles fire logs very well because we are getting logs from many of our applications. We collect the data from APIs and everything, and it works very well with fire logs.

Cribl has handled our needs very easily and very stably. We have depended on it, and it works very well. Data costs have become very low, making it more reliable in terms of cost efficiency.

The main improvement is to provide a very clear and comprehensive user manual.

Another main improvement I would like to see is if we could get an advanced monitoring system or advanced monitoring capability, we could use Cribl in a very advanced way.

We have been using Cribl for mainly around ten months.

Cribl is very stable. Once the pipeline is configured properly, it runs consistently, even with high volume. We have not faced any major issues.

From my experience, Cribl is quite scalable and very scalable. We are using it with very high volume, and it is very scalable.

Cribl's customer service is good. We have tried contacting them one or two or three times, and it has been good.

We are using Splunk currently, but we were giving logs directly to Splunk without any clarity, without any cleaning, and without any optimization. We were giving everything to Splunk, and because of this, it became very messy. We had to make a call to Splunk's help section for assistance. Now that we are using Cribl, it is very good, and we do not have to rely on Splunk's support to help us.

Cribl's initial setup is quite complex. That is why I am recommending that they provide a very comprehensive user manual.

We integrated Cribl by ourselves.

Cribl is reliable, and while the ROI is not as significant as other metrics, we have already exceeded it because the costs are very low.

The costing part is not something I directly handle, but from what I know, the setup cost is very low.

We have not checked any other options because this option has matched our requirements.

I would like to recommend providing a very clear and comprehensive user manual so that any newcomer or new customer can understand it very easily. Our review rating for Cribl is nine.

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.

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.

Our use case for Cribl is observability from an infrastructure point of view; we use Cribl for getting the logs from our infrastructure. The metrics or logs which we require from our servers or containers, or the platforms where we have deployed our product, necessitate real-time data processing, so Cribl helps us in that regard.

I love Cribl Edge feature, which is an agent we can directly deploy at our servers; that is quite a good feature that helps in collecting data locally at the server level. Additionally, the search is good; we can search across all our data sources, and it is quite fast. Cost efficiency also helps in optimizing costs.

Cribl handles high volumes of diverse data types very well. We have around 200 to 250 in-house servers, and we require observability and visibility over those servers. We don't have a team that manages them, and we cannot hire too many people to manage 200 servers. Cribl provides visibility and helps in that regard; we get real-time metrics, allowing us to see when we need to increase the compute of our servers or when we have over-provisioned resources. It helps in optimizing costs at our infrastructure level, and Cribl is quite cost-efficient, helping in that aspect as well.

We haven't gone very deep into it, so we don't have a heavy use case, but most probably, as it helps us in optimizing costs, that is the best thing about it. Cribl's UI is quite simple and minimal, helping the developer and team get familiar with it earlier; however, it provides functionalities in a very deep way. Thus, it becomes difficult if we don't require some metrics or something for filtering, as Cribl has provided many functionalities to filter out metrics which we don't require with our lighter use case. That has created some hindrance for us; otherwise, everything is quite good.

The function section is quite messy and includes too many functionalities which are generally not required at an amateur level. If we advance at that level, then definitely it is required to get the precise logs that filter out unnecessary data when the data stream is quite big. At that time, definitely it is required, but at the initial level, it becomes quite difficult to get the proper data that is required.

I used the solution about six months ago.

We haven't faced much regarding instability such as lagging or crashing; the backend team and support staff are quite nice, and we didn't encounter any significant issues with stability.

Scaling with Cribl is very easy, both horizontally and vertically, so we don't have any hindrance in scaling the tool.

My team has contacted technical support for some tasks they were facing issues with; they reported that the staff is quite nice, and the support is very good. However, we didn't require much support, only maybe twice or thrice.

We used to utilize Node Exporter, Grafana, and Prometheus.

Cribl sits in between those tools; it does not replace any of them. Node Exporter helps collect the host metrics, Prometheus is responsible for scraping the metrics, and Grafana serves as a dashboard. Cribl assists with infrastructure observability without replacing any of the tools. We use all of them right now as well.

Cribl's initial deployment is quite easy and nice; we didn't face any difficulties in doing that. Additionally, scaling it horizontally or vertically is very good.

I lead my team; I don't set and manage deployment myself anymore. Initially, when we had a very small team, I started building it, but now my team handles all this.

I'm not from the team that handles pricing; another department deals with that. However, the pricing appears to be good because I haven't been approached with concerns about why we are spending a particular amount. I think our pricing is fair.

For our use case, I would give Cribl a score of 10 out of 10, but overall, if I rated it for a large organization that requires it, it would be fair to give an eight. I would rate this review as an 8 overall.

I use Cribl to move data and help with moving data, connecting different data sources to different destinations, which is what I mainly use it for.

I also use it to help parse the data as well.

Something that I really appreciate about Cribl is the preview feature. Whether it would be on the JavaScript I'm working on, it shows me the output in real time, which really helps with development.

I also appreciate the preview feature when it comes to data pipelines, as it shows me in real time how my pipeline would be working with the data. Additionally, I really appreciate the live capture feature as well to get an idea of how the data looks at different stages in Cribl environment.

I think Cribl is an excellent tool for helping to manage data cost and keep it down as well as manage complexity.

Cribl has come a long way. I've been using it for three years, but there are still a lot of other features that I would appreciate regarding new data sources. One example would be open WebSockets.

There's currently not a native feature for that, so that requires a lot of time in development. I would also appreciate better support for JWT tokens for a REST API collection. While sometimes it does work, it seems very janky and seems like a stitched-together solution. It would be nice if there was a more supported version to help with JWT.

I've been working with Cribl for a long time, at least three years, maybe more.

Cribl is very robust. It's not perfect, but very good stability.

Cribl is very scalable. The product itself lends itself well to being scaled. Any issues I've had with scaling have mainly just been human issues of people not wanting to scale, but the product itself is very capable of scaling.

The speed was fast. The quality, however, there wasn't a solution just because I think it was a bug and it was never fixed as far as I know. The speed was nice, but there was never a solution provided.

Negative

I use Splunk.

From what I understand, I'm mainly on the engineering side, not the sales side, but the pricing is very competitive. Although the pricing can be a little bit high, I know that Cribl as a product helps save a lot of money by reducing data storage. The pricing is offset by the money I save by using Cribl.

Cribl does require maintenance, especially if I'm deploying it on-premises. If I'm deploying on-premises on my machines, I've just got to make sure that they're being provisioned well, that they're being updated successfully, and that they're constantly balancing the worker processing across them.

I definitely prefer Cribl more, mainly for the UI and the preview feature that I mentioned about being able to see in real time my in and out for development. I think that speeds things up a lot.

However, I do like Splunk a lot too.

I think Splunk is better tailored for visualizations and presenting to clients, especially around metrics. I think I can do some visualizations and presentations of metrics in Cribl, but it's not as robust as Splunk.

Definitely for large corporations, they would see the most benefit, but I think small and medium businesses could also benefit as well.

Our main use case for Cribl was primarily data reduction, as we were spending a lot of money on data ingest, and we brought Cribl on board to reduce the amount of money we were spending on that ingest. 

Reduction in firewall logs was our primary use case for Cribl, as 80% of our data is Palo Alto firewall logs, and a lot of it we don't necessarily need in the SIEM tool, so we use Cribl to reduce that, keep only the stuff we want, drop the rest, and keep it out of the SIEM tool. The reduction in firewall logs keeps the unwanted data out so that when the security engineers are inside the SIEM tool, they only see the stuff they need to see.

The features of Cribl that I appreciate the most are the vendor agnosticism and the ability to send data almost anywhere you want, regardless of the data type, the format, or the destination; it's very flexible, and we've been able to integrate it with the tools that we have used in the past and are planning to use in the future.

The UI is very clean and super intuitive, making it very easy to bring data on via the sources, route the data to any number of destinations that you want, and create pipelines to transform and morph that data however you want. 

Cribl is great in the sense that it can handle a large amount of volume and scales with the amount of data that you want to bring on board; if you need to bring on board more data, you just increase the amount of workers that you have.

We use Cribl to reduce data cost and complexity by both dropping fields that we don't want or parts of events that we don't want while keeping the things we do want, while also keeping all of the data, the event in its full form. We're a government agency, so we ned to keep everything. With Cribl, we can have our cake and eat it too, in a sense.

I'm an engineer, so I think about logging. Improvement could be made in the logging area, as sometimes we encounter issues in a pipeline or something, and it's not immediately obvious when you look at the logs that the pipeline is failing.

I've been using Cribl for around four years.

I would give Cribl a great rating on stability and reliability, especially if you use the built-in alerting engine that they have, as you can get alerts directly if there are any problems with the worker itself or worker processes, and the built-in monitoring page makes it super easy to monitor the health of all your worker processes.

Cribl scales great with our company as we're actually bringing on a lot more data with all the AI tools rolling out, which generate a lot of logs, and Cribl scales horizontally by just adding more workers and worker processes, allowing us to tackle that data smoothly, quickly, and efficiently.

We've had a great experience with Cribl customer service, as we have dedicated PS resources that have been super helpful when we were rolling out Cribl initially, migrating sources of data from syslog over to Cribl, routing, and parsing, with the support being A+ on both the PS side and the technical support side.

Positive

Cribl is really the only tool out there that does what it does, especially when looking at Splunk, as when Cribl first came out, Splunk wasn't able to intuitively do a lot of the things that Cribl did just out of the box with a GUI, making it super easy. 

We were dabbling in data reduction, transformation using Splunk's Universal Forwarder and even the Heavy Forwarder in some instances, but it was just not as intuitive, with a lot of command line interaction and no GUI on the front end, making it harder to do, while Cribl makes it super easy.

When we deployed Cribl, we were on-prem. All of our workers are on-prem. Our leaders are on-prem. Nothing's in the cloud. The major challenges that we faced really were related to the load balancer that needs to sit in front of the workers. I would like to maybe see that rolled up into Cribl in the future. That posed a lot of challenges for us just coordinating with our infrastructure team, getting the F5 engineers involved, using F5 load balancer. That was a challenge for us. We ultimately tackled it, however.

From my point of view, the biggest return on investment is just the downstream licensing costs we save on the SIEM side; we've reduced our data by a certain amount, and it has almost paid for Cribl itself and also allowed us to chop some licensing off of the SIEM side. We've reduced our amount of ingest by about 40% overall.

I'm not really involved in the pricing and payment aspect of Cribl. I'm just the guy who implements it all once it's bought and paid for.

We're not using Cribl Search at the moment; we're only using Stream and Edge.

If you're a company out there considering Cribl, I would highly recommend at least giving it due diligence; get linked up with the sales rep, as they're going to explain everything to you, and the sales engineers are great and very knowledgeable, making it worth your time and money, so you're going to be glad you did. 

I rate Cribl nine out of ten.

Cribl is used to manage routing of different log systems and vulnerability type log scanning and retention, which is then re-routed to log retention servers. Firewall logs are sent directly from firewalls into Splunk, which is where Cribl also sends data, so Cribl is bypassed for firewalls. Cribl is primarily utilized for internal servers, systems, and endpoints.

The ability to make different variations and adjustments within Cribl to scan for specific items or to get an overall scan is valuable. Cribl's ability to contain data cost and complexity makes the system much easier to use. The cost is higher than preferred, but it is considered the cost of doing business. Data ingestion costs increase with higher ingestion levels, but by maintaining similar or lower levels and refining tuning and ingestion as it comes, costs have been maintained and remain within expectations.

Cribl's interface is user-friendly and easy to learn, making it simple to teach new users how to use it.

Cribl handles a high volume of diverse data types very well, such as logs and metrics. However, the endpoint plug-in tool can use some refinement, as it tends to hit system resources and can sometimes be detrimental to systems to the point where it must be turned off and a scan restarted when a user is offline.

Outside of the endpoint issue, there may not be much that Cribl can do better in the program itself. It becomes tedious when one-off fixes are needed because a user submits a ticket complaining that their system is unusable due to Cribl performing a scan.

Cribl has been used for approximately six years in a career, not necessarily on this job only.

No lagging, crashing, downtime, or instability has been observed in Cribl itself, only in the endpoint scanner. The system itself has been very solid.

Cribl is fairly easy to scale. If ingestion levels need to increase or decrease, adding new nodes is not an issue. Adding the endpoint scanner is not difficult and is fairly easy to use and upscale as needed.

Customer support or technical support through a ticket or email has not been contacted personally. The DevOps team, which handles maintenance updates, has contacted support when running into an issue, which may occur once a year if that, so nothing major has been cause for concern.

The initial deployment of Cribl was somewhat tedious due to the environment being specialized and restricted in an air-gapped setup, so everything had to be built on-premise. This made deployment more difficult when unable to reach the internet to get updates. It took some time, but this was strictly due to the restricted environment, as everything had to be placed on a hard drive, brought across, updated, and then troubleshot through that effort.

No alternatives to Cribl have been tried because there has been no need to.

Cribl requires routine updates, with no other real maintenance required. This review is rated an eight out of ten.