Cribl Reviews

My main use cases for Cribl include data reduction, sampling, aggregation, and advanced routing of data to get them to the right place with speed.

It benefits our company by not having to guess at what the data's going to look like after we've made complex manipulations to the data. We can see the data in real-time and understand what the input's going to look like and also what the output's going to look.

The feature I appreciate most about Cribl is the interface and how you're able to interact with the data, see the data both live on the ingest side as well as on the side where it goes out to the destination, which is a feature that was lacking in the previous solution I was using.

Cribl does a really great job of making sure that no matter how crazy the data set is, we're able to see that data and understand it, and then perform advanced functions against the data to make sure that it is in the ready state for whatever the end place is in which we wish to send it. It really helps us because we have thousands of different types of data which we have to run through Cribl and make sure that they get to the right place in the right amount of time.

Cribl is world-class at handling large volumes and types of of data, including metrics. Currently, for my organization, we push multiple terabytes worth of data through the solution every day. And we've been able to find out that it's easily scalable, and I feel that in the future, it's able to grow as our needs for data grow. We have been able to see reductions in firewall logs. For many organizations, firewall logs are one of the largest log sources, modernization included. And so with Cribl, we can use the aggregation functions to make sure that we're pulling out key information from those logs and sending those over to our SIEM solution.

In terms of the user interface of Cribl for managing log manipulation tasks, it is a world-class solution. It's one of the main reasons which drove us to contracting and purchasing Cribl. We were tired of using plain text files to manipulate data, especially at our large volume. It really helps us be able to see and click and have an easier interface, so administrators are able to do the same things that previously engineers weren't able to do, working with flat files.

One interesting use case I was thinking about in terms of an improvement for Cribl would be if Cribl were able to do some of the search work that we do currently inside of our SIEM solution in Cribl itself. For example, examining the data as it comes across the wire, making some of those decisions for further functions that have to happen with that data so that we don't have to have that additional workload on the search side that has some delay, albeit very small. 

It would be really nice to be able to see Cribl gain insights from the data as the data is in stream, in flight, on the way to wherever its final storage destination is.

I have been using Cribl for four years.

From my perspective of the stability and reliability of the solution, there have been times where certain releases have bugs inside of them that we have to work around in order to make the solution work as intended. 

The support team has been very responsive when we find those issues that may occur, and oftentimes there's a patch that's released in the coming weeks for that, and there's a way for a workaround where it does not impact what we need to do.

We have 45,000 employees at our company.

In terms of the ability for Cribl to scale to meet our business needs, it has been doing very well. There is an existing architecture and a model for growth, and we've been able to use that model to grow as our needs have grown over the time that we've used the application.

I would say that in terms of customer service and technical support, Cribl is top class. No matter what time, day or night, my salesperson is available for me and my support team to answer questions, or they answer emails, no matter what time it is that we have an issue. They have been very supportive in making sure that our solution can be working as best as it can.

Prior to using Cribl, I was using another solution to address the problem of data manipulation, routing, and other functions. That solution was Splunk Enterprise props and transforms. 

It can be quite painful when you have thousands upon thousands of lines of code that are required to be maintained to manipulate the data and no real way to visualize what those manipulations are doing. That was one of the main driving points that led us to searching for a solution that we needed.

In terms of my experience with deploying Cribl, I myself was not directly involved with the initial deployment of the solution.

However, I can say that in terms of the management and the upgrades and the maintenance of it, my engineers give good feedback regarding how easy it is to maintain, upgrade, and make code deployments, changes, and commits. It is working out for my needs.

From my point of view, there are two main things when it comes to the return on investment of using Cribl that I've found to be the most compelling business use cases. First of all, we're able to take the data and get the data off to multiple destinations on the fly, basically as we need to. The second thing is that data aggregation, sampling, and reduction that we're able to do of the data, lowering our overall data volume, both traversing the network as well as what's being stored inside of our final solutions.

My experience with pricing, setup cost, and licensing has been good with Cribl. The price compared to the value of the product has been found to be worthwhile and we've been able to create a business case year in and year out in terms of why we need to continue our investment in the solution.

We considered some other solutions prior to going to Cribl, such as syslog-ng. However, being that I currently work for a large enterprise, Cribl was very attractive. Cribl comes with enterprise support. That's one thing you need to be cautious of in terms of picking a solution is that if you have to go with, for example, an open-source one, and there's a critical outage, you might not have the support you need and expertise on staff to get the solution back up and running. That was a strong selling point for Cribl.

In terms of advice that I'd give to other companies considering Cribl, I'd say take a look at the business use case and at the data which you have that's flowing through it, and make sure you think about how to get the most on the other side of wherever that data is traveling to, specifically from using the Stream product. 

Make sure that you have a targeted goal in terms of data reduction, then work with your support team to make sure that you have the necessary transformations of the data in place so that you can meet those goals. That way, if you do, you can more easily justify the cost and the budget that's required in order to stand up a solution such as Cribl.

On a scale of one to ten, I rate Cribl a ten due to its reliability, scalability, and comprehensive feature set that meets all our needs.

My primary role involves transforming customer's DDI environments to newer environments, migrating things from legacy platforms to newer platforms. A couple of my clients had the challenge of log analysis. DDI or DNS DHCP and IPAM environment logs are quite large. When the logs need to be sent to SIEM, Splunk, or any other log analysis environment, the licensing cost is substantial. They were looking for options to leverage this and reduce log size while maintaining visibility. I came across Cribl, a beautiful product that fascinated me. I was also evaluating a couple of other products including DataDog, but Cribl fascinated me because you can customize your requirements. Based on your requirement, you can channelize the logs, make the logs available as needed, and deduplicate things. Many things can be done in Cribl environment. I worked along with the LogStream team with the clients and we set up Cribl environment to pass logs from the DDI environment to Splunk.

In my current field of DDI transformation as an enterprise architect, I have close to 22 years of IT experience working as an enterprise DDI architect.

Cribl handles high volumes of diverse data types such as logs and metrics very efficiently because the data volume is managed very efficiently. Cribl is primarily for reducing the data volume and log volume. Analytics is the area where they need to improve. When passing query logs or DNS logs, if certain malicious query patterns need to be identified or if fast-flux attacks are happening, Cribl can report that and those would be definitely a plus for them. Even if those features are there, or may not be there, I couldn't find those options in Cribl. That's one area where they need improvement. Out of the box integrations with different DDI platforms would be definitely a plus. I couldn't explore much into those areas.

What I like most about Cribl is basically two things. One is the data reduction. When passing syslogs, syslogs are huge, ranging from gigabytes to terabytes in size. When the syslogs need to go to the security operations team or security team for log analysis and event monitoring, it's a nightmare for them to analyze all the syslogs. Cribl intelligently formats them. It intelligently extracts the data from the syslogs and then reduces the size of the syslogs by almost 30 to 40 percent, which I have seen practically. It removes any null values that are not required. It strips down whatever is required and just discards whatever is not required.

Secondly, sometimes in the logs, you find some unnecessary information, such as just an IP, some site ID, or what we call the circuit ID. Cribl fetches GeoIP information or checks for the reputation of domains if DNS queries are going to certain domains. Based on RPG response policy zone files, it adds those additional fields to the log so that the logs can be enriched. When the traditional logs don't show the accurate values, this makes them more user-friendly and more user-readable format. Those are basically the two things that I appreciate about Cribl. It basically presents what is required out of a syslog output.

I have been using Cribl for somewhere around two to three years.

What I dislike about Cribl is that it represents my direct pain point. I basically do DDI migration, which is transforming a legacy architecture to a newer platform. My expertise is in Infoblox DDI. If a customer environment is running with Microsoft or some old bind Linux based DNS DHCP solution, I consult them and if they are willing to move to Infoblox DDI, I help them migrate. The only thing is when we are doing the integration of Cribl, Cribl doesn't have any out-of-box customization packs for Infoblox. Whatever is available is only in the community. I need to go through the community page, download each customization pack or many filters and check whether that filter applies or not. Nothing is out of the box from Cribl. I have sent a couple of requests to Cribl earlier. If these could be available, because Infoblox is a market leader in the DDI segment and if Cribl has a native integration with them, then putting out-of-the-box integration with Infoblox with some filter packs and customization packs would be great for Cribl LogStream.

Analytics is the area where they need to improve. When passing query logs or DNS logs, if certain malicious query patterns need to be identified or if fast-flux attacks are happening, Cribl can report that and those would definitely be a plus for them. Even if those features are there, or may not be there, I couldn't find those options in Cribl. That's one area where they need improvement. Out of the box integrations with different DDI platforms would definitely be a plus. I couldn't explore much into those areas.

I haven't used the new Search in Place technology feature of Cribl Search as of now because my recent engagement with a client where I deployed Cribl and the Cribl log analysis log channel was not there. If I get any chance to deploy for any other client, I will get through that feature.

Regarding Cribl's user interface when managing log processing tasks, the newer interface looks cool compared to the initially clumsy interface. However, those aspects can be improved. I have seen that when switching between dark theme and white theme, some text is not visible clearly in the dark theme and the graphs are very hard to read. If they could improve that, it would be great.

The initial deployment of Cribl is one area where it needs to be improved because the initial deployment takes some time. Specifically, for complex platforms such as an Infoblox DDI platform where there are no out-of-box customization packs available, you need to go through community portals and Cribl community blogs to find scripts and customization packages. It takes some time, but once that is set, it becomes easy. It's quite easy after that.

I have been using the solution for two to three years.

I haven't contacted technical support because we couldn't have gotten any outage or situations where it was not working. I just worked for in small stints for different clients, so that's why I didn't contact technical support on those things. The self-help things and documentation are really good. Cribl has certain videos available where you can go through them and get knowledge.

Cribl doesn't require any maintenance on my end because on the DDI side, no maintenance is required. When sending the log to Cribl, Cribl is passing the logs but storing them. Maintenance will be only required if it's hosted on a VM and the disk space becomes less, then you need to increase the disk space. Basically that is taken care of by the VM team. Ideally in every enterprise, the virtualization team or data center team is different. For the storage issues, they can take care of that. Cribl is just passing and storing the logs. If Cribl is passing on device, then they need bigger storage, and if the storage is becoming less, then they need to increase the storage. That is the kind of maintenance I see, not from the source side.

Cribl is definitely scalable because you get a platform which is kind of vendor-agnostic. Today, you have one platform, maybe a client is using Infoblox DDI, so they are sending the logs to Cribl. Tomorrow, if some other platform they are using for DDI, the log analysis channel or the log plane doesn't get affected with that. If tomorrow you need a little more processing or analysis, you add more instances of Cribl and that becomes scalable. You can scale it horizontally. Vertically also, you can add storage. Both ways it is scalable, horizontally and vertically.

I haven't contacted technical support because we couldn't have gotten any outage or situations where it was not working. I just worked for in small stints for different clients, so that's why I didn't contact technical support on those things. The self-help things and documentation are really good for them. Cribl has certain videos available where you can go through them and get knowledge on that.

Negative

The initial deployment of Cribl is one area where it needs to be improved because the initial deployment takes some time. Specifically, for when you have a complex platform such as an Infoblox DDI platform where there is no out-of-box customization packs available and you need to go through community portals, Cribl community blogs and find the scripts and customization packages, it takes some time. Once that is set, it becomes easy. It's quite easy after that.

One or two people can deploy Cribl. That's not a big deal. You don't need a big team to deploy it. At most I can tell two people, that's all.

I still have no idea about pricing because pricing and price point is basically determined by the customer with whom I work. It's taken by a very separate team, the finance team, and they decide on what price it should be. What I have seen in my implementation career with Cribl is that the licensing cost of Splunk is significant because Splunk is volume-based licensing. The more volume of data you are sending, the price also increases. Whatever they save from the Splunk side is ideally adjusted in Cribl pricing. It's a win-win situation from both ends. You save price from Splunk and you use Cribl and eventually you have a lower TCO, lower total cost of ownership at the end.

When I was looking for these kinds of solutions, I had come across DataDog and Kafka. Those are not easily available and cross-platform as Cribl. I couldn't explore more into those other alternatives. I got a good product and I stick with that. I didn't check for others.

Regarding firewall logs, I can't directly tell you the exact information because my firewall is not my area of expertise. I have definitely seen logs decrease in the Splunk logs for a DDI platform with Cribl. If Cribl forwards the logs of firewall to Splunk, then definitely there will be a decrease in the firewall log, but I can't tell exactly how that would be. I have given this product a rating of 9 out of 10.

Our main use case for Cribl is to help us reduce cost. Currently, we use the Stream and Edge products of Cribl, and it's on-premise for us. The Stream helps us with any optimization work that we have to do in terms of reduction of the data itself.

The Stream product benefits us by giving us the ability to reduce and streamline the logs flowing into our SIEM. Cribl Stream helps us optimize the data before it reaches our SIEM tools. We've performed extensive aggregation and deduplication of logs, allowing us to cut down unnecessary data before it's sent downstream. This has helped us reduce costs by controlling exactly what data gets forwarded to the SIEM.

In our case, we deal with very chatty logs, especially firewall and other network logs. Using Cribl’s aggregation and drop functions, we were able to significantly reduce the noise. We send a full copy of the raw data to S3 or another data lake, while only the reduced logs are sent to the SIEM.

Another major value we gained from Cribl was how quickly and efficiently our data pipeline became. Previously, onboarding new sources or clients was a challenge. Now, the process is semi-automated and far more streamlined compared to what we had before.

One area that could be improved is the aggregation functionality within Cribl. It's very difficult to aggregate low-volume logs because the worker processes don't share state. Since each worker process initiates separately, it becomes very challenging for aggregation to maintain a consistent state across them. As a result, aggregation becomes problematic, with different worker processes operating in different states while pulling data. A good improvement to the aggregation functionality would be if most of these events could somehow land in a central processing unit or repository, where aggregation could be applied before the data is sent downstream.

I've been using Cribl for over three years now.

I can confidently say we’re finally getting some good sleep. Before Cribl, we were constantly getting late-night calls about data flow interruptions. Migrating from those SC4S servers to Cribl worker nodes has truly been a game-changer.

In terms of scale, Cribl scales very efficiently because we do horizontal scaling. If we have a burst in data sources or an increase in data sources, all we have to do is add a new worker nodes, and usually that solves the problem.

The customer service and the technical support team at Cribl has been very helpful to us. We've had some really unique cases where sometimes they would refer us to professional services, but they would come back with solutions from someone who may have run into that similar issue and provide us with a solution without having to go through professional services. This has been very helpful.

Positive

Prior to Cribl, we were using SC4S, which had a syslog-ng engine, and we were doing a lot of manual work, especially when we had new data sources. We had to build something that didn't have a pre-built template within SC4S; it was a challenge to build out templates for it, especially with new folks joining the team sometimes who didn't have any clue about where these things were being kept. It was a huge challenge for us to build those templates for data sources that didn't have any templates at all.

We also had our heavy forwarders, which we were writing transformations and props to help us reduce data. It wasn't doing quite a very good job, and Cribl had some of these advanced functionalities such as aggregation and those drop functions, which was very easy to configure, whereas in the past with the heavy forwarders, it was very hard sometimes to even build transformations to do the same thing.

When deploying Cribl, the process went very smooth because we had a Cribl engineer on our side who helped us significantly.

In terms of pricing, we had a very good deal with Cribl. We were paying very expensive SIEM costs, and introducing Cribl into the picture was able to bring down that cost. We were able to get the setup for the whole Cribl infrastructure at little to no cost, and it definitely brought us significant value and cost savings from that direction. In terms of reduction, we were able to save almost ~40% of our total cost.

Other products that we considered throughout the process included Splunk Ingest Processor, and we did a POC on that as well. Some of the positive aspects about the Ingest Processor was that it was right at the edge of your Splunk deployment and therefore there isn't any need to deploy or reshift your infrastructure; it actually goes right into it and then feeds into your Splunk environment. In terms of the disadvantages of Splunk Ingest Processor, it has very limited functionalities compared to what we were getting from Cribl. Cribl gives us the aggregation functionality, which was a huge win for us, being able to aggregate all the events brought us huge reductions, and also the drop functionality and some really advanced functionality within the Cribl tool itself.

Based on my experience, the advice I would give to other companies considering Cribl is that your decision should be very specific to your use case but do not underestimate the amount of data you're dealing with. Data will continue to grow over time, and a tool like Cribl can significantly help reduce costs before the data is sent downstream.

Another important consideration is whether you need to send data to multiple destinations. This was a challenge for us previously, and Cribl helped simplify that process. My advice to companies is: if you're drowning in data and cost, Cribl is essential. It gives you full control over your data and makes management much easier.

As an organization, we've adopted AI heavily and integrated it into many of the tools we use today. We're actively looking to bring similar capabilities into Cribl. It's already in our pipeline, and we see strong potential in using AI to streamline how we build Packs and Pipelines. With AI integrated, we believe it could significantly reduce the time admins spend building specific pipelines for various data sources.

On a scale of one to ten, I would rate Cribl a solid nine based on what we use it for today and the value it delivers.

I am working in a PLM environment, which is product lifecycle management. We deal with lots of system logs and tool integrations. I used Cribl Search for debugging system errors quickly and searching logs stored in long-term storage. Instead of pushing all logs into expensive tools, we used Cribl Search to directly investigate issues from stored data.

I am currently using Cribl Search only. I have some experience with Cribl Stream, which we are using for our data pipeline solution.

We have just started using the Search in Place feature because one of our team members recommended it. There is a lot of room for improvement in the way we query the data and the whole data processing pipeline. We weren't using any other tool before.

I have been using Cribl Search for a long time now, and I think Search in Place is a very good feature in Cribl Search. Unify Search is also valuable, where you can search data from multiple sources in one place. Fast investigation reduces steps from multiple tools to a single workflow. Pre-built search packs save effort to configure the dashboards and write the queries. It also works well with other Cribl tools.

The traditional way for certain places is that logs are generated, then sent to SIEM tools like Splunk, and then stored again before you can search them. This has problems including data duplication and high storage costs. With Search in Place in Cribl Search, logs stay in storage such as S3, data lakes, or archives. You can directly run queries on that data without any movement, duplication, or reprocessing. Advantages include cost reduction and faster investigation.

Since we can directly query historical data where it is stored, there is an advantage of deep root cause analysis, which helps understand what happened in the past. This is useful for debugging recurring issues and is cost-efficient. It has helped me in faster troubleshooting because there is no need to reload old logs. We can investigate incidents after days, weeks, or even months. It has the ability to handle large data volumes, so there is no performance bottleneck.

We reduced unnecessary data ingestion by almost 40 to 50% using Search in Place. We could troubleshoot issues faster because data was already available for querying. It eliminates redundancy and keeps the architecture cleaner. As the data grows, we don't need to scale ingestion pipelines.

The user interface of Cribl Search can be more simplified because for non-technical users, it is quite difficult to grasp. There is a need for better beginner tutorials.

Cribl could have built-in guided queries for faster onboarding and better beginner tutorials. A more simplified UI would be better for non-technical people.

I have been working with Cribl for eight to nine months.

Until now, we haven't had any downtimes. It has been working very well.

It is pretty scalable horizontally. We started with one team member but now there are five to six people using it.

We developers ask for support from our in-house IT team, but I don't know what conversation goes on between Cribl customer service and our IT team.

We evaluated Splunk, but due to some reasons, we went with Cribl Search.

Cribl Search was set up by the IT team, but they haven't complained about any issues or complexities that arose during the setup. I think the setup is pretty simple and not that complicated.

The implementation was done by our internal IT team.

With Cribl, we have observed a 40 to 60% reduction in log volume hitting the firewall because Cribl filters unnecessary events and removes verbose fields.

There is reduced pipeline complexity and faster end-to-end workflow because data doesn't wait in ingestion queues. There is also optimized data processing cost because less data processed equals less compute plus storage cost. Other expensive tools are used only for critical data. There is a shift from processing to querying because traditional systems process first and query later, but Cribl stores data cheaply so we can query it when we need it.

Cribl has many filters to remove noise from the data and to remove verbose fields, which has been very good to work with.

Earlier, we had to process and store all logs in monitoring tools, which are very expensive, before analysis. After using Cribl Search, we streamlined the workflow by sending only critical data through pipelines and directly querying archive logs for investigation. This improved efficiency and reduced system load, which helped us indirectly optimize costs. We reduced the overall processing load by around 40%.

I'd highly recommend other organizations to use Cribl Search because it did help us a lot with data processing and everything.

Cribl Search was set up by the IT team, but they haven't complained about any issues or complexities that arose during the setup, so I think the setup is pretty simple and not that complicated. I would rate this review an 8 out of 10.

Our main use cases for Cribl are Cribl Search, which allows us to search for logs and metrics for our cloud engineering data.

The features of Cribl that I appreciate the most are the ability for in-place searching for our logs, so we don't have to move our logs outside of our cloud, which gives us privacy and compliance requirements.

Other features that we appreciate are dashboarding, alerting, and the ability to save searches so we can rerun them again on a scheduled basis. These features benefit our company in a variety of ways; mostly, our operations team can rerun their searches on a daily basis without having to rewrite the queries, and the ability to keep the data privately in our buckets is a huge requirement for us.

Cribl's ability to contain data cost and complexity is good. The complexity is very minimal. The reason for that is that the data does not move from where it lives. So there is no cost and there is no complexity in terms of moving the data and processing the data out of where it lives currently. Everything is in place, which is huge, and it makes everything so simple.

Cribl is great at handling a variety of volume logs as it is scalable and it uses scalable infrastructure behind the scenes, which allows us to constantly add more logs and it is able to handle it nicely.

Cribl search affected our data exploration practices overall. Cribl search has affected us greatly, and it has optimized our operations teams' time and efficiency. They're able to troubleshoot and find issues for our customers in a minimal amount of time. It also allows us to go back and look, for example, three months back for specific issues. With other tools, it was taking us a lot longer.

The UI is very intuitive in the sense that it gives you the chance to write your own query and customize it. And then once you figure that out, you're able to save it and rerun it on a scheduled basis so you don't have to reconfigure the query every single time.

Cribl can be improved in some ways; one of which is the ability to search multiple regions. Currently, Cribl Search is dedicated to one bucket at a time in the case of S3 buckets. The ability to search for multiple buckets would be awesome.

We have been using Cribl for a little over a year now, and we use specifically Cribl Search.

We have not experienced any downtime or crashes with Cribl; however, we have experienced some delays with some of the Cribl Search queries when the volume of data is humongous. In some parts, due to how the data is partitioned in our cloud, we were aware of those situations. Even though we did experience them, we anticipated those delays, so that was expected.

The process of expanding usage is very smooth, and Cribl Search is very scalable since it does the searches in place where the data grows, and the infrastructure behind Cribl Search is also scalable as it uses a CPU and it just spawns horizontally more instances as it demands and requires.

I would evaluate the customer service and technical support of Cribl as superb; honestly. Every time we had an issue, we created and opened a new ticket for Cribl support, and they were very responsive. Usually, within an hour, we get a response, and we are able to work with them back and forth until we resolve the issues.

Positive

Prior to Cribl, we were able to use cloud-native specific solutions which were costly and time-consuming to pinpoint and figure out problems that can happen within a time window. It was not an easy user interface, and operations complained. Because of that, we started looking into other solutions, and that's how we stumbled upon Cribl.

The biggest return on investment when using Cribl is our time minimization for our operations team. They're able to look for customer issues real quickly, as opposed to the previous tools that we had, which were more time-consuming and also more costly. The time saved using Cribl is hours per engineer - about three hours' worth.

I did not deal with pricing directly. We had a team that dealt with Cribl.

We have looked into other solutions without naming names, and we considered major tools that are in the industry that are cloud-specific, cloud-native. What stood out was that Cribl is more cost-effective, and also, the main issue for us was we wanted to keep the data in our cloud. 

We don't want to migrate it due to privacy concerns and compliance requirements. Cribl was about the only tool that actually was able to satisfy our requirements, which is mostly the reason why we chose Cribl.

I would advise someone considering Cribl to really look into Cribl products, such as we did for Cribl Search, and really examine the challenges of huge volumes of logs, as Cribl has a really nice suite of products that would satisfy these requirements. Additionally, consider the requirements of data privacy, as the data does not get moved out of your cloud. 

On a scale of one to ten, I rate this solution a nine.

My use case is log management. The problem was in Sentinel where Syslogs park in a separate table and CEF logs park in a separate table. We were planning to convert the Syslogs to CEF format, which was not easy in Sentinel. Cribl helped us accomplish that.

There were many applications working in the client environment with ingested logs that had different column names. We normalized those using Cribl.

I appreciate Cribl's overall flexibility. If I can use regex, I can write KQL things in the pipeline. The built-in functions, which are really good, are very helpful.

I value that Cribl shows the payload before conversion, after conversion, and what has been transferred to the destination. This transparency is really great.

Cribl is intuitive. A user can easily see how the payload or log looks before conversion and how it looks after conversion, and what has been transferred to the destination. This makes it very interesting and intuitive for the user.

I don't think there is much complexity because the documentation is good and Cribl University helps a lot to understand the product. Cost is sometimes a problem with customers if they don't have budgets. Otherwise, it is not that much. The value addition that Cribl provides compared to the cost is significant.

Cribl is easier to use. The only area that Cribl should focus on is cost-effectiveness. I have deployed Cribl at four clients, and the major challenge in convincing them was the cost.

I have been a user of Cribl for the last three years.

I don't think any of my customers have required maintenance or generated a ticket complaining about any problems in Cribl. It's working fine.

It is manageable. It depends on how you manage it. If you manage smartly, then there is no problem. Otherwise, sometimes one or two logs can create a problem.

I encountered technical support three times and I must rate it as eight out of ten. It was really awesome and very supportive.

I would rate it as nine out of ten. During deployment of four customers, I had to contact the support team only three times, and that was also my fault. There was not a problem in the product. Cribl is very stable and a mature product.

Positive

I have worked on Virtual Metrics, which is a Dutch solution, and Ninja, which is something else, but they also provide similar services. However, Cribl is a very mature product.

I have seen a few more tools like Virtual Metrics and others, but Cribl is on top.

If you have gone through the documentation properly and completed Cribl University's courses, then it is easy to deploy and implement. It is not a difficult thing.

Currently, I am not pursuing a partnership. Earlier, we discussed with Cribl, but then we decided to go for three to four years without any partnership, and later on, we will look into it. Maybe in 2027, we will discuss with Cribl to develop a partnership, like becoming a reseller.

If I count the total of four customers, it is almost 23 users.

I have not used it until now, but I am working on Cribl AIDI, the AI feature which has been recently given in Cribl. I am learning in that area.

I think it will reduce my workload a lot. It will manage many things on my behalf if I successfully use it in a smart way.

I have seen two other solutions which claim to be competitors to Cribl. If I compare with them, I will give ten out of ten to Cribl. It is a very detailed and very mature product.

It depends on whether your use case is strong enough and you think that Cribl is the only solution which can solve your problem. If so, then cost is nothing. Otherwise, it is a little expensive.

First, when I feel that any of my customers should deploy Cribl for their use case, I discuss it with them. If they don't have budget or any constraints, then we look around. Otherwise, my first priority is always Cribl. Going with my first customer, I was a little hesitant to deploy Cribl. However, once I deployed it at my first customer and seen the results, I had evidence. Then my first priority became recommending Cribl.

Basically, it is not my area, but if you convince the customer and the end user upon the value addition that Cribl will provide them, then cost is a secondary thing.

I give this review an overall rating of nine out of ten.

My usual use cases for Cribl involve collecting logs from many endpoints, including user activities. We collect logs into either Log Analytical Workspace or Event Hub and redirect to Cribl so that Cribl filters the required logs and redirects them to the SIEM tool.

We do not get a chance to use the user interface of Cribl because our client has access to that; we only implement and do that. They will check whether it is there, but based on my experience, it will be pretty easy to see what is in the user interface, and it will be easy to manage as well.

We have not used Cribl Search to a large extent because the client requirement was to only implement Cribl and integrate it with the SIEM. We have not used Cribl Search extensively, and I do not have any information about it.

The features of Cribl that I prefer most include the way it can easily be interfaced to SIEM and Event Hubs in Log Analytical Workspace. From Sentinel and from any other tool, it can easily be interfaced and it can send data to SIEM; those features I prefer to use most.

In assessing Cribl's ability to handle high volumes of diverse data types such as logs and metrics, as of now we have not faced any problems in collecting a large number of logs. Cribl is pretty efficient in collecting logs even when there are too many logs flowing at a time. We can collect not only server logs but also OS logs and even audit logs without any difficulty, and there has been no blockage in the system. There are no complaints, but it has been a very good experience using Cribl. Since this is a software as a service, if any problem exists, we just raise a ticket to Cribl team, and they will immediately jump into that and resolve all the questions or queries we raise.

Regarding Cribl's scalability, we did not have any problems with any cloud compatibility. The client requirement was to use Cribl, and we were checking whether it is compatible with Azure. Within a single day, we got a solution that it is easily compatible. We just needed some prerequisites, such as opening a few ports, and we wanted to ensure that everything was working regarding the reachability of the client to the agents. Once this was done, we did not have any issues.

I am not in a position to comment on how Cribl could be improved or enhanced because it is a good tool, and I have only used a small part of the entire Cribl product. As of now I am pretty happy with the entire Cribl component, but there are still a lot of things to learn.

I have been working with Cribl for the last six months.

In assessing the stability and reliability of Cribl, as of now we do not have any problems with stability. Even though we had two worker nodes in one region and a load balancer, we did not face any system issues. In case of vulnerability where we wanted to patch any one worker node, we easily did that and switched it on. We never faced a problem where some software was not there and therefore not working. Reliability-wise, Cribl is working perfectly fine.

Regarding scalability, we started with zero servers and have around 285 servers now. We did not experience any problems or slowdowns due to a lot of load. Cribl neatly managed everything.

I can rate Cribl's scalability around 9; I would say 9.5.

I have addressed the technical support team of Cribl. Every now and then, if there are servers having legacy operating systems, the latest versions of Cribl will not be supported. We have to contact them and ask which version will be supported because they have prerequisites. Based on the prerequisite, we have to downgrade to an older version of Cribl rather than use the newer version because it expects some advanced Java version. However, due to legacy systems, we do not get all those things. We manage this because those are all crown jewels of the client, and we do not want to change anything there, so we downgrade Cribl version and install it. We did not find any blockers because of this downgrading.

The skills and professionalism of the technical support team from Cribl are very good in terms of timing and skills. They understand the problem clearly, and once they understand it, they will resolve it within a day. Sometimes they resolve it within hours. Sometimes by hearing the problem itself, they will know what the solution is, and they will let us know how to resolve it, and we do it immediately.

I left the organization and I am no longer in the same organization, so I do not get a chance to work with these products (Darktrace, Microsoft Defender, and Perception Point Advanced Email Security) anymore.

For deploying or setting up Cribl, the requirements were given by the client, and we had to abide by that. Cribl was the only tool we had to use according to our requirement. We started with the deployment where they had given the requirements, and then we started with that and performed it successfully, starting with installing agents in all other servers.

The deployment and setup process of Cribl was straightforward because there are two ways to deploy. We can get an EXE, click and enter the details, or there is an automated script where we can run it and it will do it automatically. In the case of Linux, it will update and install the latest package, which is also quite easy. It is not a very tough thing to install any agent inside the system. It is pretty easy.

For support, we always raise a ticket to Cribl. We do not get the entire thing, but support activity is what we get. I have just implemented and I have just redirected the logs into Cribl for collecting all the security loggings.

I am an end user of Cribl. We manage Cribl for only implementation. As we have just implemented it, I am using it in our organization.

In sharing my thoughts on Cribl's ability to contain data cost and complexity, nowadays because of events per second, the way of SIEM billability is based on events per second. If you inject logs into Cribl, we can save a lot of data. Many logs are repeated logs. We can easily avoid repeated logging into the SIEM, which will also reduce the fatigue for the SOC engineers. This is one positive aspect of using Cribl, as we can reduce the number of events and increase flexibility and efficiency in the environment.

I'm not sure of Cribl pricing because it has been procured as a package by our client, and we are not exposed to or do not have an idea of how much they have spent to get a license from Cribl. But I understand that it is a little bit on the higher side. However, for what we have paid, the quality of service which they have provided makes us happy with that.

I do not think that if the pricing is on the higher side, it could be suitable for all types of users, such as small or medium ones. Each security component is important these days, and I feel Cribl usage always helps the product. However, it also depends on the budget they have. If they are able to use Cribl as a log monitoring tool for the SIEM according to their budget, it would be good. Again, there are pros and cons which we have to consider about their budget. If it is a very small organization, Log Analytical Workspace would be enough to collect all the logs. But if it is a big organization and budget is not a concern, I think they can go for log monitoring.

I have not seen a decrease in firewall logs with Cribl so far. What we do is use Event Hub. We actually redirect the entire thing to SIEM, so it will not come via Cribl. It will come via Cribl, but it will filter the required things based on our use case. We do not write all the packets because most of the packets would have been filtered in the firewall itself. Whatever packets are coming towards the firewall, if we want to collect the logs, we are directly interfacing with SIEM and we will collect it from there so that we do not want to lose what is the external activity on the internet towards our environment.

Based on everything I just described, I would rate Cribl overall as 10 out of 10. I have not used other parts of the feature; for whatever log monitoring I have used for Cribl, I always try to rate the maximum. However, I have not used Cribl Lake, Cribl Search, and other things they offer, so I cannot comment on those.

I was not regularly using the same tool, but there was a time when our team needed to migrate some data from one tool to another, and during that data migration phase, we used Cribl for six to seven months. We did some coding from Splunk to Elastic to send our data logs.

Our use case was majorly to migrate our data from Splunk to ELK, which are two different observability platforms that we use in our team. Because our team was switching to Elastic, we needed the same data that we use in Splunk. In Cribl, we created pipelines and data routes to share the data. The admin side clipped the IP address from Splunk into Cribl and from Cribl to ELK, whatever the scenario was for them. Majorly, we used it for the data migration.

When managing log processing tasks, I would go with the first option regarding the user interface; it was pretty simple. It took me some time to understand the logic and how to create pipelines, but with some time, I got really comfortable, and I would really recommend it. The UI was nice, easier, and faster. In the beginning, it was a bit tricky, but once you get a hold of it, it is really nice to use.

The things that you mentioned were easy to use, and since we did not have any experience in Cribl, it was easy to code. Index is equal to this and all that; that was pretty easy. Setting our pipelines, setting the data routes, and understanding those things was pretty simple. I really liked that and the interface. When I write code, I can see on the right-hand side that the events occur. Input and output, those sort of things, I really liked all of that. It made it pretty easier to understand the data and what we had filtered there.

In Cribl, I feel that maybe I am not aware of it, or maybe it is already there, but I think if there was a way to learn more about it. There are a lot of areas to explore. For example, if my work is only around creating pipelines, I am only expert in that. If I would like to learn more about the other things that Cribl can do, I feel there is not a lot of learning material. Or maybe I have not searched enough; maybe there is because I remember we learned from Cribl only. There was a Cribl course, and then we got a little idea of it. But if I want to explore particularly in one area, like a tool can do a lot of things, so if I want to learn about the 'B' section, how it does, what it does and all that, I feel there should be an easy manual or something. Maybe there is, I am not aware of it. That is what I thought; the application was nice. After some time, we were really comfortable. But if I want to learn more, can I get those manuals easily in the market and all that? I am confused on that part. Maybe there is, but maybe I am not aware of it.

Again, maybe I am not aware of it, maybe there is already. If there is, then nice. If in the future I would like to learn more, then maybe I will go there. But if not, that would be really nice because people are really interested in this tool when it comes to migrating and all that.

Six to seven months.

The tool is stable. I would rate it a nine.

There are times when the data is not present in the second tool, the output tool. People do some monitoring on Cribl's side to see if someone turned off the data set or something like that. I think it requires a little maintenance in six to seven months, or if there is a bug. But I am not sure if that is a painful task because I am not around for that. So I am not sure how much painful that is, but I think it does require some maintenance in short to long term, at least once.

Technical support, I think nine. Nine or 9.5. Whenever needed, there were Cribl experts and all that, so they were able to resolve anything. If they needed, the support team was always there. I would say 9.5.

Positive

I have only explored Cribl, and I did get a sample box for other tools from some people on LinkedIn, but I have not tested it out. Maybe if I was primarily working on this tool, I would have explored those things. But I have not, so I am only aware of Cribl. I cannot compare with others since I have not tried them.

The initial setup process was straightforward.

I would rate the return on investment a nine.

I am not aware of the pricing because I was not a part of it. We were developers. But as far as I understood, I think it is a bit expensive. I am no one to complain, but there was this person on LinkedIn who mentioned they also have a common tool like that, and they were saying that they have a cheaper way to do it. I heard that this might be expensive. Since the cost area was all on the admin side and the architect side, we were not in the loop with the costing, but I have heard that this is expensive. There are other tools which can do the same job cheaper, but I think they also might miss some of the advantages of the tool.

Many filters we use really decreased the number of events going on, but not in the firewall. I am not aware of that; I am not an expert in that area.

Regarding the ability to contain data cost and complexity, I felt it was pretty easy. Because of the routing system and all that, I can manage my data in a certain way that you have to filter out this and that. I would say it was nice.

I do not think regarding the new search and place technology feature of Cribl Search. Maybe if I have used it, I do not feel that I remember that part, or maybe I have not.

I have mostly positive feedback with no reason to say no because I am not paying or anything, so I am not aware of the cost. Mostly because of the positive reasons, I would say it is easy to use, it is sustainable. The support is nice, the coding is quite easy to understand, there are a lot of functionalities there. You can do a lot of things, and the data migration is very easy. For all these reasons, if you are stuck between two things and majorly what our team did was use it for migration, you can always rely on Cribl. My overall rating for this product is nine.

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

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

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

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

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

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

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

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

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

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

For something similar to Cribl, I have used Splunk.

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

My use case involves analyzing very large log files coming from middleware and system log files for both functional and non-functional errors. To perform this analysis effectively, we fetch these logs into tools such as Splunk or Dynatrace, but since those tools charge based on the volume of logs ingested, it is crucial to filter out unnecessary log data. Cribl helps us by trimming irrelevant logs and enriching the data as needed based on input from different teams, allowing us to streamline our log files before sending them to analytical tools.

The best features of Cribl include its ability to handle logs, allowing us to avoid redundant data input while ensuring that we send only the information we need to analytical tools for insights. This tool excels at performing tasks on the fly and lets us run different pipelines for our logs, combining data from various sources, such as application logs, intra logs, and network logs, and customizing it according to our data center or region.

I appreciate the twenty-four seven availability of Cribl, which is essential for ensuring our data is always accessible, even during downtime. This is a significant challenge, and maintaining that availability is crucial for operational continuity.

With Cribl Edge, the centralized fleet management has simplified how we deploy, upgrade, and manage agents across our environment. We automate configuration files based on regional needs and have developed a naming convention to categorize our configurations in a way that is easily manageable through the GUI.

Cribl handles high volumes of diverse data, including logs and metrics, exceptionally well, which is why we continue using it. With large amounts of data from enterprises such as Vodafone, it is essential to trim and enrich this data to achieve good results and avoid sending garbage data to analytics tools.

Managing log processing tasks through Cribl's user interface is quite intuitive, making it user-friendly.

There is room for improvement in Cribl, as managing data from around forty thousand servers can become complex. Automating the upgrading process for the Cribl agent would significantly improve usability, especially since we sometimes experience issues when using Blade Logic for updates.

I would appreciate more automation in the processes, and I have not explored the AI features that Cribl offers, such as ChatGPT.

I have been working with Cribl for three years and three and a half years to be precise.

Cribl is a scalable product. We have challenges integrating it with data from forty thousand servers across various platforms while maintaining stability and scalability, and I would rate our scalability at nine.

From my experience, I would rate Cribl's technical support as around eight or eight and a half. There is room for improvement, especially regarding urgent issues that occur in production environments.

Positive

The deployment was initially complex, but it is now stable and functional, largely because of the thorough documentation and excellent certifications provided by Cribl.

In my company, approximately twenty-five to thirty specialists work with Cribl.

The solution saves a significant amount of time and resources. I would estimate the return on investment to be double or triple the investment we made.

The unified management provided by Cribl Edge has dramatically reduced the time and effort needed for maintaining endpoint telemetry collection. Once the handshake occurs on the server side, any issues can be quickly identified from the GUI, and we only need to configure what information we want to fetch from the agent.

For firewall logs, we define and open specific firewall ports in our configurations to either collect bidirectional or unidirectional information, depending on the server's security requirements.

I have used Cribl Search primarily for our log patterns, but my involvement has largely been from an operational perspective, with limited usage of this feature.

I find Cribl to be cheaper compared to other solutions and believe it will become a leading product in the industry due to its fast performance and excellent results. When considering log ingestion, it allows us to extract only the necessary parameters from a larger dataset, which contributes to reduced data handling and effective dashboard creation.

Maintenance is necessary, especially for upgrades, but Cribl allows for these modifications on the fly without requiring system reboots, ensuring that production is not disrupted.

I would certainly recommend this product, emphasizing its effectiveness and potential to become a leader in the field, as its marketing presence is currently less than that of competitors such as Splunk and Dynatrace. I rate this product at nine overall.