I have Splunk with approximately 10 TB daily ingestion, so I route that data to Cribl. I optimize the data and then index it into Splunk, reducing storage by about 30 to 40 percent. For example, 10 TB daily ingestion becomes 5 TB ingestion after optimization.

In another scenario, I have approximately 10 TB daily ingestion in Splunk, route the data into Cribl, optimize the data, and it becomes 6 TB or 6.5 TB daily ingestion.

I route firewall logs, event logs such as Windows logs, metrics logs, and EDR logs.

The feature I appreciate the most is the connection between Splunk and Cribl, which is very useful for routing data. The pipeline and filtering logs are very helpful.

Cribl has a central management system that controls all data pipelines and configuration. Cribl works centrally by using the main Cribl instance, managing the configuration, pipelines, and routing rules for all worker nodes. The leader node acts as a central node, managing the pipelines, route packs, and configuration, distributing them to the worker nodes. The worker nodes process actual logs and send the processed logs to the destination, such as Splunk, S3, or other SIM tools.

Cribl Edge processes the data at the edge before sending it to a central system, reducing unnecessary data volume so we can drop some data, improve performance, and reduce network usage at the edge. It helps with security and observability.

Cribl Edge is a very lightweight agent for data collection and processing. It runs on the endpoints or the server and helps collect logs and metrics directly from the source and process them before sending them to a platform such as Cribl Stream, Splunk, or any other destination.

Cribl Edge has made it easier and faster to maintain endpoint telemetry collection.

Initially, it takes time to understand the pipelines and the functions, and sometimes troubleshooting certain requirements, checking multiple pipeline states, and more built-in examples for real-world use cases would help beginners learn how to work with Cribl. For a beginner, learning how it works and how to build the pipeline and the functions presents some challenges.

I think data cost is acceptable, but the main concern is availability. Sometimes Cribl is down, so we may miss some logs, and that is an issue. Availability for Cribl is needed.

We typically do not have issues with the logs, but sometimes Cribl is down, causing us to miss some of the logs, which creates a significant issue for Splunk. Customers have issues with logs when Cribl is down, leading to missed logs and triggering Splunk alerts repeatedly due to data loss, creating multiple incidents. We need availability for Cribl most of the time. If availability is acceptable, then we do not have any issues with Cribl.

Sometimes we have downtime with Cribl, which is the only issue. Otherwise, we do not have any other issues. When there is downtime, we cannot get the logs into Splunk. Based on those logs, we get alerts that keep triggering repeatedly, creating multiple incidents and sending emails to our customers, which are very problematic during downtime.

At this time, we are working in Cribl because we do not want to use the Edge Processor due to its complexity, requiring us to manually write all the functions and multiple lines of code for data reduction and dropping. Cribl has some built-in functions and a very good UI that helps significantly. It is better than the Edge Processor since we have to write the full pipeline from scratch in the Edge Processor, which can be difficult. We also cannot capture sample logs in the Edge Processor, but in Cribl, we can capture the logs.

I have been working with Cribl for approximately one and a half years.

Sometimes Cribl is down, so we may miss some logs, and that is an issue.

Sometimes we have downtime with Cribl, which is the only issue. Otherwise, we do not have any other issues. When there is downtime, we cannot get the logs into Splunk. Based on those logs, we get alerts that keep triggering repeatedly, creating multiple incidents and sending emails to our customers, which is very problematic during downtime.

We can easily scale up and manage multiple nodes, which is not a significant task and is quite easy. Scaling the Splunk agent is difficult compared to Cribl, and in the Edge Processor, managing multiple nodes is very challenging. Cribl is a better solution for scalability.

I did not contact technical support because we have senior staff in the company who help us understand how it works and everything else. They have significant experience with Cribl, so we can learn from them and apply the changes to the pipelines.

In the initial setup, for beginners, I would say it is moderate, not too easy and not too hard. For experienced people, it is very easy.

One person is enough to deploy Cribl if you do not have a very large environment. Otherwise, we need different types of people for a very large-scale environment.

I have approximately four to five years of experience in Splunk, and currently, I have approximately one and a half years with Cribl. I am using Cribl.

Cribl Edge is a very lightweight agent for data collection and processing. It runs on the endpoints or the server and helps collect logs and metrics directly from the source and process them before sending them to a platform such as Cribl Stream, Splunk, or any other destination.

I am not aware of the Search-in-Place feature, and I have to test that feature before I can provide feedback on it. At this time, I do not have any information about that feature. I can investigate it.

There are no requirements for maintenance.

Your pricing is lower than the Edge Processor or the Ingest Processor. We mostly need availability for Cribl at all times. If our customers get availability, then we do not have any issues with the cost. However, if we do not get availability, that is when we have an issue with Cribl.

I rate this review a nine out of ten.

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

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

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

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

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

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

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

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

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

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

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

Before adopting Cribl, we did evaluate a few other approaches. Some of the evaluation was around using native capabilities within SIEM platforms like Splunk, as well as open-source log processing tools like Logstash for handling data pipelines. Those options can work for log collection and processing, but Cribl stood out because it provides a dedicated platform specifically designed for observability and security data pipelines. It offers more flexibility, routing, filtering, and transforming logs without heavily relying on the SIEM itself. That is why we chose Cribl over any other platform.

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

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

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

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

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

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

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

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

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.

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.

We generally use Cribl for dropping or optimizing our logs and data. We optimize logs using Cribl pipelines, then we route it to Splunk. That was our primary use case.

Our primary goal with using Cribl was to reduce our Cisco firewall logs where we are dropping the logs which are not necessary in our traffic-related logs, or the logs which generally only show a connection status. Those types of logs we were dropping using Cribl.

What I like most about Cribl is the overall pipeline structure and easiness. It is very easy to use and it also provides all the necessary features which are required in data processing. We do not need to learn so many things to do complex tasks. That's what I really appreciate about it. It's doing a simple process where you just need to know about your logic and that thing may be pre-built on Cribl. Cribl provides packages and all the features.

I would say Cribl provides you the value of your money. It provides you a good user interface where you manage all your data. You don't need to worry about your backend. Specifically, I'm talking about Cribl Cloud, as I have mostly been working with Cribl Cloud. It's very cost-optimized, or I can say whatever I'm paying, I'm getting all out of that.

Overall, the pipelines and all the features are good with Cribl. The UI is good. Just sometimes, when I actually started using Cribl, I faced the issue where I was not able to connect the nodes. The pipeline is structured in a certain way, then the data will be routed to there, and something of that nature. I was very much confused about their whole products, such as Data Lake and pipelines. It's possible that at that time I didn't take any university courses, which is why I did not know much. But if they can give an intro on how we can connect nodes, or they can provide simple use cases showing what you can do with Cribl, it would help. If you just need to add the source and the destination and pre-build some proper workflow, then it will be easy for new customers to navigate through Cribl.

I have been working with Cribl for around one and a half years.

I don't feel Cribl has any issue with handling high volumes of diverse data types. We were ingesting around 10 TB of data daily, and we were reducing it to around six or five and a half terabytes. So it is pretty efficient. We have not faced any major issues with our ingestion or anything of that nature. It has the capability to catch up according to the data ingestion rate.

I have not seen any lagging, crashing, or downtime in Cribl at any particular time. But if I speak about lagging or anything, I faced some issue while capturing the log on the live source. Whenever I tried to capture the logs, I was a bit confused about whether logs are getting captured or if I was doing anything wrong. Because it does not show any error if my configuration is missing or something of that nature. Otherwise, I don't have any issue regarding Cribl performance or anything.

I don't think there is any issue regarding scalability with Cribl. As we were ingesting around 10 terabytes of data every day and it didn't affect or cause any issue on any day.

I would not say I have tried an alternative to Cribl properly. We tried to implement the same use case using Splunk Ingest Processor or Edge Processor, which is the recent product of Splunk. It is not that straightforward as Cribl. We must play in a restricted environment where we have limited support of the Splunk command. So I cannot say that it is actually similar to Cribl or something of that nature, and I have not used any others.

I was able to create one simple pipeline with Cribl which was just dropping the data in around eight to twelve hours total. In which I basically understood what routes and pipelines are. I was playing with the UI and how the functions are working, how the pipeline flows the data, how can I duplicate the data, how can I drop, how can I null queue, and things of that nature.

My use cases for Cribl include ETL: Extract, Transform, Load.

One thing that I like the most about Cribl is parsing data and parsing data sets for security. I would say automation use cases and detections are also great aspects.

My favorite feature of Cribl is that the UI is pretty intuitive, and they have a very good open-source platform.

One challenge that I find with Cribl is that it's nuanced, so if you're not familiar with how to do specific data transactions, it's going to be a difficult solution for someone to use. You have to be educated to a specific degree and understand data communication from beginning to end, alongside understanding the tool itself and how it operates; it can be confusing and challenging for some people if you don't understand how to use it.

I can't sit here and say that I've physically witnessed a decrease in firewall logs with Cribl, but certainly, there probably is one because of the way the redundancy is used for extracting that data. It should be something that's common-sensical or intuitive with the solution if you're utilizing it correctly, meaning you wouldn't upload gigabytes of duplicate telemetry.

My thoughts on Cribl's ability to contain data costs and complexity is that it's an accurate assessment, given that the person behind Cribl utilization is knowledgeable, but there is a steep learning curve. If you're a customer who has no idea how to use Cribl and just buy it hoping to solve your problems, it doesn't work that way. You must have some understanding of ETL in general or just source data, root data, and then what you're actually looking to transform. Just buying Cribl hoping it will solve all your problems is far from the truth. Although Cribl is a great product, you wouldn't give a Ferrari to your sixteen-year-old son right when they get their driver's license; that's the best analogy I can give. Cribl is a Ferrari for data analytics and monitoring, but you don't hand over the power or weaponize that tool for someone who doesn't know how to use it. A customer can definitely do all the things that Cribl claims, but it comes at a steep learning curve and that intuitive cost.

I have been using Cribl in my career for probably over seven years, maybe longer, and I can't recall the first time, but it's been years though. I would say close to a decade.

I haven't personally witnessed any instability with Cribl, and any instability I have seen was caused by user error. This means performing a function within Cribl and then getting error outputs because of something, such as how the data transaction was communicated. I have heard of an issue where too much data gets backed up, but I can't think of the specific term Cribl uses for it. Such issues are fairly common.

Cribl is good for scalability, making it a good product for any organization looking to do data transformation, whether small to medium businesses or large corporations.

I have contacted customer support for Cribl, but it wasn't for anything operational; it was for some knowledge base articles. Their customer support is extremely responsive and very communicative.

If I were to put their support on a scale from one to ten, I would probably give them an eight.

There are plenty of alternatives out there.

The closest one in terms of quality and tools that comes to mind for data management is BindPlane, but those two are not comparable. There are other solutions as well, but there's really nothing Cribl. Other solutions such as Axiom also come to mind, but again, you're talking about comparing Ferraris to Volkswagens or some other vehicle. Comparatively speaking, I can't really think of a solution that operates as well.

A capable engineer should be able to deploy Cribl with ease. As I stated before, the open-source knowledge base is extremely thorough, and one with an engineering background shouldn't have a problem standing up Cribl; it should be pretty easy. The nuance comes with doing data transformation within Cribl, using pipelines, packs, and their specific solutions, which might present a learning curve. However, standing up the solution operationally is pretty straightforward.

Regarding whether one person can do the deployment or if a team is needed, the answer isn't straightforward. In a small to medium business environment, I would say one person can do it. However, for organization-wide deployment, it depends on how efficient, effective, and optimized you want to be. You can't just respond with a direct answer; you have to ask what kind of outcomes and timelines you're looking to achieve. If you're asking me straightforwardly if one person can do it, I would say it's possible, but it's a very misleading answer.

For pricing, I would say that Cribl is pretty standard across any of these other organizations, and it's pretty comparative depending on the ingest. Some people have different licensing models, and you have to consider ingest, scale, and what you're taking in and putting out. For instance, a license for Cribl would be five hundred thousand plus your ingest costs for your datasets, such as all your syslog and your third-party data sources. That being said, there are other organizations that have different pricing models, so it's hard to do a straightforward comparison. Axiom, for example, might have an all-inclusive licensing model around two hundred fifty thousand to three hundred thousand. To do a proper comparison, you would have to look at all the caveats. Overall, the pricing model for Cribl is pretty standard and straightforward.

Cribl does require maintenance from the user. You need to ensure that you're updating, including comments, service versions, and that sort of regular operational maintenance. It depends on specific endpoints and end-of-life considerations, but the general answer would be that you definitely need to maintain Cribl. You can't just deploy it and say you're done.

I have been using Cribl for about a year in my career. As a consultant, my job nature involves working with clients and coming up with solutions. Many of my clients are interested in observability, so I evaluated Cribl as a potential tool for their needs. Cribl is a relatively new product, and I have been involved with it since last year.

What I appreciate most about Cribl is that it addresses a major gap in the market compared to the competition. Splunk is extremely expensive, and many of my clients are financial institutions, including big banks, insurance companies, and fintech payment companies in Canada. While they already have Splunk installed, it is costly and sometimes does not meet their needs. Cribl offers significant advantages because from the source, you can collect all the data you want and filter and transform it.

In recent years, many of my clients are focused on fraud prevention, AML compliance, and regulatory requirements. They have numerous MRAs that they need to remediate and show evidence for. Cribl provides better control over data sourcing and allows them to demonstrate good control of their data.

I appreciate that Cribl provides better control of data from the source, which translates to better control over the cost of data and complexity. Many of my clients have sources of data across different platforms, and Cribl allows them to manage data from all these different sources in one place.

One area for improvement would be the certification path for Cribl. I understand there is a need for higher-end certifications, but it would be beneficial to also create certifications that are more accessible for business people or consultants. The current engineer certification is quite rigorous and not easy to pass. While keeping that rigorous option, providing another option for business or consultant users to get certified would be valuable.

I have been using Cribl for about a year.

Regarding stability, I have not experienced any lagging, crashing, or downtime with Cribl.

I believe Cribl is suitable for both large corporations and the small and medium business market. Some of my clients are very large banks in Canada, including one of the largest banks in the country. However, I also work with smaller clients, such as smaller insurance companies. Cribl performs effectively across both market segments.

I have contacted technical support for issues and had a positive experience. I started by opening a ticket from their website. I have dealt with other vendor products in the past where support was unresponsive, but Cribl's support is very good. I was pleasantly surprised by their quality and speed of response. I would rank their support at an eight out of ten, though I acknowledge that I tend to be overly critical.

While I have not personally tried similar solutions, my clients have been using Splunk, which is the most comparable solution they have relied on for a long time.

I have not done an actual deployment myself, but my understanding is that the initial deployment is easy.

Regarding maintenance on the client's end, there is some administration required. Standard updates from Cribl, such as security fixes and bug fixes, are typical maintenance tasks. I would need to review the specific details to provide a more comprehensive answer about all required maintenance.

I do not know the exact pricing because as a consultant, I am not privy to the exact numbers my clients are paying. Pricing often includes deals and investments from vendors. However, based on feedback from my clients, Splunk is more expensive, and Cribl appears to be more affordable.

Regarding pricing for Cribl, I cannot speak to exact numbers because as a consultant, the clients handle the financial details. Deals between vendors like Splunk and Cribl often involve special investments, so the pricing varies. Based on what my clients have shared, Splunk is significantly more expensive, and Cribl appears to offer better value.

I contacted technical support for issues and had a very positive experience. I would give this review an overall rating of eight out of ten.

I recommend Cribl as a solution to customers who have a lot of telemetry data because it provides flexibility within data routing.

It saves us a lot of time because the auto-deploy and auto-updates from one central panel is much easier to manage. When managing deployments manually, it takes 10, 15, or 20 times more time compared to using a central management UI.

One advantage we've seen is that during customer presentations, we can ask customers which specific use case they want us to present, and then we can use Cribl AI to present that. This has enabled us to present use cases that aren't even security telemetry.

We had a use case where we didn't know how to proceed at all, so Cribl helped us 100 percent. We didn't have any knowledge going in on how to collect temperature data and harmonize it into one format when the customer wanted us to showcase different temperature scales such as Fahrenheit and Celsius, along with different decimal separators like commas and dots.

Cribl is very easy to get started with, and you can get going very quickly. It has an interface that is very user-friendly, so you can set it up and start connecting sources with consumers fairly quickly.

Cribl offers a lot of what they call packs, which are valuable resources. However, I do think you need to be a pretty technical person in order to make sense of the UI. The product is not easy to use for just anyone.

Cribl works well and is fairly easy to set up, especially with firewalls, which are one of the baseline use cases. As long as there are packs available, it's a really good product and easy to manage. However, if there are no packs and you need to code it yourself, the learning curve is a bit steep. Thankfully, Cribl AI is now available, so you can prompt inside the tool and get help on how to set up all of the different rules.

One thing I think is that Cribl is very dependent on the packs. If you don't have packs and you need to do things on your own, it's not trivial. You'll have to make a real investment in training and experimentation.

Cribl needs to think more broadly. The product really comes down to having a higher level of flexibility in data routing. You can send data to multiple destinations at the same time and you're not locked into anything.

I would like to see an investment in a broader range of use cases beyond security telemetry data. For instance, I know that the railway industry is very interested in finding data pipeline tools for the data that trains create when they're driving.

I have been using Cribl for about two years now.

Cribl is very stable and scales really well. Besides the fact that the worker nodes consume a lot of resources if you push them, it scales very well. It's easy to spin up new nodes, and they're very stable.

I think the Cribl team is awesome. In Sweden, they're really great. The cybersecurity market in Sweden isn't that big, so it's the same people working in the industry. The Cribl team in Sweden is really a great team, and it works really well with our organization.

I work with Logstash and Gigamon, which are the main two tools I've worked with. You can also do some things in the command line, but they're more efficient with how you integrate, so that's another way to do it.

Cribl feels a lot easier to use and more intuitive. It gives you more capability, and you don't have to work as hard to set things up.

Cribl is a little bit more pricey than Logstash, which is one disadvantage.

I strongly recommend doing a proof of concept to see Cribl in action and always do an ROI calculation. Don't be surprised if you save money in the end on investing in Cribl.

I work with Logstash and Gigamon, which are the main two tools I've worked with. You can also do some things in the command line, but they're more efficient with how you integrate, so that's another way to do it.

If you're very efficient in Splunk or in Sentinel, then you could argue that you don't need Cribl because you won't save that much money. However, they are two different products with their own pros and cons.

Cribl is very focused on security telemetry, but I feel their product has really good use cases for other things, such as the temperature example I referenced earlier.

Cribl is not a solution for the smallest customers because you need to have a certain throughput of volume. If you have just 200 users, then Cribl is not the appropriate tool to discuss.

The main product we work with is Cribl Stream. I would give Cribl a rating of 9 out of 10.

Cribl is used for log management and SIEM in terms of optimization of the data that we are collecting.

The flexibility that Cribl provides allows us to manage the data and work with the data effectively.

Implementing Cribl has optimized the infrastructure that we have and is improving the optimization of the services that we are providing.

Other than the Cribl module that we are using, Cribl Search has several modules, so there is room to improve that capability in Cribl.

In Cribl Search, the language and the flexibility in querying the data can be improved because it is not as good as other solutions.

Cribl Search does not currently help search data in place for investigative issues or answer questions across our data stores at this moment because we are not using it at that level yet, but hopefully in the future.

I would advise others looking to implement Cribl that if they are evolving Cribl Search, it would be very interesting to see more capability, more flexibility, and more ways to share the data similar to Splunk.

I have around three and a half years of experience working with Cribl.

Cribl's stability is an eight.

For scalability, I would rate it a ten.

I would rate the technical support as an eight.

I would compare Cribl with other solutions or vendors as mature. We have seen another solution similar but not as mature as Cribl at the moment.

I am talking about the Data Stream Processor from Splunk and also Omnium from Spain.

Cribl is easy to deploy; the team managing the deployment did not report any concerns about the complexity of the deployment of the solution.

The deployment is straightforward; it is just a matter of coordination with other teams, but everything was released in one day.

Regarding the firewall logs with Cribl, the digression of the data that we are experiencing thanks to Cribl is amazing. Although I cannot provide exact numbers, the reduction is significant.

I use Cribl Stream, Cribl Lake, and Cribl Search. My experience with Cribl Search and Cribl Lake is just initial; we are just starting to use them. Cribl Stream is the optimization we are using right now in terms of data collection and data management and is more mature.

Cribl Search has changed my approach to long-term log retention and historical investigation.

I would rate this review an eight overall.