Cribl Reviews

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.

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

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

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

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

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

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

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

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

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

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

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

I use Cribl as our data ingestion source, with Cribl Edge agents installed across all servers. Cribl is used at the pipeline or routing level to send data to our SIEM platform.

Firewall logs are sent to Cribl, and Cribl routes specific logs to our SIEM tool while sending others to archive storage. This segregation and separation capability is not possible with any other tool, which makes me very satisfied. However, Cribl charges us for all firewall logs that it observes, not just what it processes and outputs.

Cribl performs parsing and field reduction exceptionally well, cutting down unnecessary fields and delivering only the right data. However, Cribl charges for everything it sees rather than just what it parses. We might ingest a large volume of data but only process about forty percent of it, yet we are charged for one hundred percent of the data ingested into Cribl.

The ability to bifurcate or trifurcate data and send it to multiple destinations is a feature we love. I have been a Splunk user for over eight years, and this is something Splunk did not have until Cribl introduced it specifically for this purpose.

Cribl handles logs, metrics, and various data sources really well. I have ingested up to fifty terabytes of data per day, and Cribl has never failed or caused trouble from that perspective. Cribl handles huge volumes of data exceptionally well.

A feature I would want Cribl to add in future releases is the ability to create a greater number of fleets. Currently, Cribl has a limitation on the number of fleets that can be created. In an enterprise environment, different types of servers belong to different applications and should be organized accordingly, as each has a different change management cycle and upgrade cycle. Cribl cannot be upgraded all at once, so we want to separate fleets so we can perform upgrades in batches rather than all in one shot. Increasing the number of fleets would be greatly appreciated.

Data cost is a concern, as Cribl charges for everything it sees rather than everything it processes. I do not see much cost-effectiveness from this approach. If we could do pre-processing before sending data to Cribl, then Cribl would be cheaper than other tools, but if we could do that, we would not need Cribl at all. This costing model has been concerning for a while. Better options based on user base, enterprise size, or data volume would be beneficial. More options to choose from for pricing tiers are needed, as the current offerings are very limited.

I have used Splunk previously and have been using Palo Alto XSIAM. Palo Alto XSIAM has integrated features from Cribl, Splunk, and Sentinel into one comprehensive tool, taking the best features from all three. Another concern is that there is not much default alerting available for Cribl metrics, and custom alerting is also difficult to configure. For example, backpressure monitoring has only very limited use cases available out of the box when monitoring Cribl environment health. Cribl could take steps to increase the number of use cases and add guardrails around how much volume can be ingested. Options to create custom alerting would be helpful, such as alerts when certain metrics go down or up, or when the catchall is filling up. These options exist but are very complicated to set up. Unlike users who have been using Splunk for ten years and transitioned to Cribl, I find it very difficult to navigate and create alerts in Cribl. The ease of use could be improved by providing default options that can be leveraged and customized as needed.

Cribl initial deployment was easy, but for large enterprise networks and big organizations, Cribl does not support operating systems earlier than 2012. This creates a problem, and a package should be available for anything below 2012 that works as expected. Currently, Cribl only approves packages for 2012 and above, but some organizations require applications to run on legacy servers. This option is not available, and we are unable to get Cribl installed without finding alternatives or going back to using Splunk to pull data and then stream it to Cribl. This causes significant operational challenges, and if this could be fixed with one version that supports everything below 2012, it would be greatly appreciated.

Cribl is deployed both on-premise and in the cloud. Cribl placed sample data in one of the YAML files that contained examples of personal data like social security numbers or credit card information. When this YAML file was included in Cribl package itself, vulnerability scanners detected it as a non-compliance or data loss concern, even though there was no actual personal information, API keys, or sensitive data present. These were just examples provided by Cribl. Cribl fixed this issue in the latest version after we brought it to their attention. Going forward, I would like Cribl to think about this from a bigger enterprise perspective, as endpoint security tools will detect all of these concerns. It is not just about processing data but also about the problems faced when deploying it in a large enterprise. This thought process needs to increase from Cribl's side.

I have used Cribl for over a year.

A dedicated support portal is available, and support cases are usually raised through a dedicated email. Responses are received at reasonable times, so this has not been a problem. I would give support a rating of seven out of ten.

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

I performed the entire setup of the Cribl infrastructure.

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

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

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

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

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

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

I would rate Cribl an eight out of ten.

We use Cribl for log management.

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

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

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

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

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

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

Positive

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

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

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

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

Big businesses use Cribl.

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

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

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

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

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

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

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

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

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

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

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

I have been using Cribl for four years.

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

Cribl's scalability is not great.

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

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

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

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

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

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

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

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

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

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

I have observed approximately 60% reduction in firewall logs.

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

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

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

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

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

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

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

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

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

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

I would rate the technical support an eight.

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

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

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

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

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

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

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

I would give this review an overall rating of nine.