Cribl.Cloud Suite

My current use cases for Cribl involve how the telemetry data moves. We have instrumented our observability backend related services, which we use specifically for our business logic. Basically, how it works is there is something called Autopage where we have all the details of whatever data was just coming in terms of from the adapters of AWS. There, we have Cribl deployed even when no queue queue Kubernetes cluster exists. We have these things and we're very well organized. Most of the use cases are on Kubernetes where we have better observability because Kubernetes generates a lot of traces, and manually, it is very difficult to manage all these things. Cribl plays a good amount of role to summarize everything properly provided all the information.

What I like the most about Cribl is that it extracts the spans very well. Honeycomb does the same thing, but Cribl does it a little bit better than that. We can route one stream from too many destinations with no problem. We have configured a center table easy instance, and we have also tried with the cloud solution. When we send the data in, it just gets extracted in different telemetry solutions such as signals and data doc. It provides all those enriched data with all the details. For example, we gave user ID as one of the attributes we wanted, and it mapped email on top automatically. So it becomes very easy to identify which customer has a problem during incidents and other things.

I'm not the right person to ask this because I only configured it for providing certain specific things. If I say one negative thing, the setup is a little bit trickier because observability setups are generally trickier.

I have been using Cribl in my career for six and a half months.

Regarding stability, I don't really face any lagging or crashing, but that comes with not a lot of data being injected there. If a very high cardinal solution or high cardinal metrics goes in, there might be some issues, but I haven't faced any problem that way till now.

Scalability, stability, and reliability can only be judged when you have a huge amount of data. Our current organization doesn't deal with a huge amount of data. What we have is around two hundred to three hundred GB of data that we are moving daily. Out of that, whatever telemetry we are getting from our total collector, there's something which we are directing to this, and this is providing to our other solutions out there such as Datadog and Honeycomb. Basically, we are not facing any problem as of now in terms of stability, reliability, and scalability.

In terms of technical support, I have not had to contact them about anything. Technical solutions are shifting now. People are more identifying things on their own, and we have a lot of solutions coming, so it's very easy now.

The initial deployment setup of Cribl was relatively easy for the first time. This comes after a certain new experience that I have. For a very new person who doesn't understand much about observability, it might be a tricky solution. When you are working with an OLTP kind of solution, versioning, pipeline, learning, and coverage are important parts. Once you have that, everything works accordingly. You just have to figure out how it will work.

I really enjoyed working with the open telemetry collectors. I have tried with some AI-related implementations. We have a vector database in the backend, and it has given us a good amount of data transformation depth, which was really good. That has given us more usage context for what we are providing to the AI model. This is a service what we had in AWS Bedrock where we were running an NLM solution. That has given us good amount of insights whether this is properly working or not. The only problem was there was no token count. For that, I have to use some different solution. For a specific integration, I would be very happy if I could get some other solution which provides me the token information also. How much token I have been consuming is not there right now in any of the auxiliary tools. I have to do it via some other aspect. No complaints with Cribl. Cribl actually has sorted out our problems, but it will probably be better.

For the deployment of Cribl, I have done the complete deployment without anyone's help. I took some documentation that they have and used it for certain structural things. For our department's sake, I deploy our changes directly without any problem.

I have seen a decrease in firewall logs with Cribl. Sampling is enabled and definitely that is something which I have actually seen a good amount of reduction in. The logs are really high, so what we had previously because a lot of those kinds of things happen on the valve, followed by a lot of things that happen on our product. Because of that, the logs get filled up very fast, and we store all those logs in history. When I compared the situation after Cribl and when we actually validated whether the amount of logs in the history compared to what they were before, the growth results significantly decreased. I don't have a number in mind right now, but I have documented it somewhere.

Regarding the pricing of Cribl, I'm not the right person to talk about pricing because all these things are taken care of by our VP of engineering. I suggested them to ship also, and then we are on a pilot with them. We have not paid any money to them yet. With respect to this current Cribl implementation, I am not hundred percent sure what we have actually done. I can answer the technical aspect of it, but the financial part is something that's out of my scope right now.

When it comes to using any similar solutions to Cribl, there are not really alternatives. We have used Chip, if you have heard of it. But the use cases are a little bit different. Chip is something which provides more enhanced metrics on top of existing metrics of what we have. So we don't have to look at ten different metrics, and we can use this. They have run a pilot with us a while back, but they are focused mainly on Kubernetes clusters, whereas our solution is more tied to the instances and other things. These are not a cluster mode running. In our case, it has given us significant value.

Regarding Cribl's ability to handle high volumes of diverse data types, for logs, it is something we have used. We have used it specifically, and I'm not saying I know how to use it completely, but not that much, to be honest. It's okay what we have done.

In my experience with Cribl's new search in place technology, Cribl search, I find the user interface when managing log processing tasks to be decent. I don't have any complaints.

I would give Cribl an overall rating of eight out of ten.

We started using Cribl one year ago for data optimization.

Currently, we are using Cribl for its one terabyte ingestion that is free, which is one significant advantage. We are using it for that purpose only at this time. We are a customer and we are planning to purchase it, with almost a deal in progress. This month or next month, we will be purchasing Cribl.

Currently, we are not using metrics; we are using Cribl only for event-type logs. We do not have much data for metrics, so we are directly flowing that to Splunk. For logs, we are using Cribl, and there is also monitoring available, which is very good. Cribl's monitoring dashboard has a lot of graphs by default, so we can use that to populate our searches and run them, which is helpful.

We are using Cribl Stream for our streaming purposes and not using Edge due to our existing Splunk agent deployment. We occasionally use Cribl Search to investigate, especially during the deployment phase, which allows us to search some internal Cribl logs. We use Cribl Lake to store the internal data.

We utilize Cribl Search only for internal purposes. For example, when we experience back pressure issues, we search that particular source in Cribl Search to check their source logs, how back pressure was created, when it occurred, and what errors arose. We only keep internal logs in Cribl Lake, enabling us to search them. Cribl Stream's monitoring dashboard shows everything, including when there is a spike, the KVP data, and all related information.

Cribl's best feature is that the UI is very simplified, so if a new person is there, they can easily understand everything. The UI is very simple and good. Other than this, data flow and data visibility are among the best features. We can directly see how our data is going from where to where and with the live data, live logs, everything we are able to see.

I find that it is very easy to describe my experience with the user interface when managing log processing tasks. It is very easy to manage all the data and all the data flows. Everything in the UI is very easy. Also, there are a lot of sources, a variety of sources, a variety of destinations available, many ports, data, and many scripts. Everything we think of is available in Cribl, so from wherever we think we can get the data and wherever we want to put it, we can put that as well.

For firewall logs, there is a default parser available in Cribl, so we are using that parser. In addition, there are many default parsers for various firewalls such as Palo Alto and Fortinet. This is very helpful to us as it will extract all the data, and we can remove the fields that are not required, which is reducing a lot. This is one reason we are purchasing Cribl for Splunk.

Cribl brings two main improvements to our organization. The first improvement is cost saving, as we can save a lot of cost by reducing the data. The second important improvement is the data quality, which is also one of the most critical aspects because it filters the data and makes it whatever we want to see. Cribl helps us manage our data quality very well. Since we are in the beginning phase of using it for one year, I believe this product will help a lot as time goes on.

One improvement Cribl could work on is Cribl's Git integration. If I want to integrate my private repository, I can do this, but there is a specific format required in Git. If I commit something to Git, Cribl won't pull it automatically. We can upload from Git to Cribl, but not the other way around, so that is an area that needs to be addressed.

We started using Cribl one year ago for data optimization.

Stability-wise, Cribl is a very stable platform with no issues.

In terms of scalability, Cribl is indeed scalable. We just need to increase the license. Currently, we pass 600 to 700 gigabytes of data through Cribl, and we plan to increase more, up to two terabytes. For that, we will need to purchase an additional license, but as time goes on, we just need to increase our license.

I rate the technical support as a nine out of ten.

There are other vendors such as Splunk, which includes its default solutions such as Splunk Edge Processor or Splunk Ingest Processor. I have heard about them, but they tend to be very technical, requiring a lot of queries. While there is a UI available, you cannot see the data flow properly. It becomes very difficult to manage your data on other platforms. In contrast, Cribl simplifies everything, with default systems and routes that allow your data to go through a pipeline to its destination. There is a straightforward flow where you check live data, can test your pipeline, and it is all very simplified compared to other platforms, which often require excessive queries to resolve issues. Fixing problems in Cribl takes thirty minutes instead of wasting a whole day in other products.

Cribl's deployment is very easy and straightforward, similar to Splunk. If you know how to install Splunk, then it is a copy-paste process. It is not complex for us since we also deploy Splunk on-premises.

For now, we are just an end-user.

Currently, we are using Cribl on-premises, and I think we have not explored it much. However, I can say that everything is good; I do not find anything needing improvement since I do not have a deep dive into this product.

Maintaining Cribl is easy; we do not see any downtime or major issues at all. Sometimes we experience back pressure issues due to source spikes, but they are acceptable as they come from the source and not from Cribl's end. Cribl effectively manages these situations, addressing spikes from sources and destinations.

As of now, we maintain five years of data, and we have not changed that. However, we plan to increase retention from five years to seven years with Cribl since we now have less data. Currently, we have 100 terabytes of data, and eventually, we aim for 700 gigabytes, which is significantly less.

I will surely recommend Cribl to everyone who has data exceeding one terabyte because it helps a lot for such customers. They can send data to multiple destinations and stream solutions, significantly enhancing data quality and reduction. Thus, purchasing Cribl is essential for them.

I give Cribl an overall rating of nine because I am not well-acquainted with Cribl Edge. I have just heard about the in-place search feature, but I have not explored that area, so I cannot comment on it. I am familiar with Cribl Stream, Lake, and Search, which is why I give it a nine instead of a ten.

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

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

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

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

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

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

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

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

We have been using Cribl for mainly around ten months.

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

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

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

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

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

We integrated Cribl by ourselves.

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

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

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

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

I have used Cribl Stream for filtering service logs, reducing data volume before sending it to Splunk, and enriching logged data with custom context.

Cribl features integration support since it works with 50 plus sources and destinations, data routing and flexibility allowing me to easily route telemetry to multiple destinations such as SIEM, data lake, and cheap object storage, and data processing and reduction because it filters out unwanted fields, removes redundant data, and restructures logs before reaching systems, which is helpful in saving cost and improving performance.

We have observed a 30 to 40% reduction in log volume hitting the firewall.

Cribl Stream handles a high volume of data very efficiently as it is designed to process log metrics and data from multiple sources in real time without major performance impact. We tested Cribl Stream with different types of machine data and even with large ingestion volumes, and the platform remains stable because of its distributed and horizontally scalable architecture.

I can assess Cribl's ability to handle high volumes of different data types, as it can handle multiple formats because it supports structured and unstructured data formats such as JSON, CSV, XML, and plain text logs. It processes and transforms data in real time with low latency. In our PLM environment, we had logs coming from multiple enterprise systems and services, and Cribl helped normalize and route those diverse logs efficiently before forwarding them to Splunk.

My experience with the user interface when managing log processing tasks is quite complex for new beginners, and there is also a documentation gap that leads new beginners to take a while to get fluency over the software.

Areas that have room for improvement include the complex UI for beginners and the documentation gap. One challenge initially was configuring pipelines and understanding parsing rules because of this gap, and I think there should be more plug-and-play integration examples for common enterprise tools.

I have been using Cribl for 13 to 14 months.

Cribl is a stable solution, and overall, I give it a 10.

Cribl's architecture is quite scalable because it horizontally scales whenever required, so I give it a nine for scalability.

I would rate the technical support as nine out of ten.

This is my first time using this type of solution, and I have not used any other alternative or competitor solution, so I am not aware of other options.

My team members mentioned that it was not difficult to deploy it; it was handled by two of our IT team members.

I find the pricing of Cribl to be cost-efficient because it has helped us save costs for data storage by removing unwanted logs.

I am aware of Cribl Search and its new search in-place technology, but I have not used it.

I am pretty new to Cribl and have only used Cribl Stream, but I am looking forward to exploring other products such as Edge, Search, and Lake.

I would highly recommend Cribl because it has been very helpful in cost optimization. I give this review an overall rating of 9.

Cribl is primarily used to reduce data volume. When large datasets arrive, such as 1 TB of data, it can be reduced by 600 GB or 400 GB while maintaining the same information. Additionally, Cribl is used to send the same data to multiple destinations. The same data can be copied and sent to different products such as Splunk and Dynatrace.

For firewall logs, there are many default parsing templates and pipelines available. Firewall logs can be easily converted using parser functions. Default parsers are available for all log types, such as Palo Alto traffic, access logs, audit logs, and Linux logs. When a parser function is chosen for Palo Alto traffic, it automatically extracts all fields from the firewall logs.

A specific use case implemented involves firewall logs, which are substantial in size. Statistics are performed on the firewall logs and sent every five minutes. The logs are summarized by state count, and during that five-minute interval, the logs are aggregated and sent to other locations such as Dynatrace and Splunk. This significantly reduces data size and saves considerable space and licensing costs in Splunk.

Cribl provides substantial help with sending data to different destinations. With three products in use—Splunk, Dynatrace, and DataDog—Cribl sends dual feeds to multiple products. For instance, firewall logs are needed by both Splunk and DataDog. Additionally, some observability logs are directed to Dynatrace while remaining logs are sent to Splunk. Cribl effectively splits data across the various products in use.

Cribl is recommended for organizations with more than 1 TB or 2 TB of data ingestion. For smaller data volumes of less than 1 TB, Splunk licensing alone is sufficient, and parsing can be done at the Splunk level. With 14 TB of data ingestion per day, Cribl provides significant benefits.

Cribl's user interface is the most valuable feature. The UI is extremely user-friendly and allows visibility into what Cribl is processing and how much time it takes. Multiple routing capabilities enable data duplication to any location.

Cribl Edge provides an agent that is very simple to install on any server. Installation requires only a one-line script that can be copied and pasted, and the connection is established immediately. The configuration part is also very good.

User management in Cribl is excellent compared to other products. There is no need to access the back-end for any task, and dependence on the back-end is eliminated. Everything is available on the UI, making it very simple to use.

Cribl Cloud has no issues with handling large data ingestion volumes. Cribl Cloud can handle any volume of data efficiently. However, before purchasing Cribl Cloud, the read and write IOPS requirements need to be discussed and agreed upon with Cribl support. If data volume increases, these parameters can be adjusted accordingly. For on-premises deployments, the server is managed internally, and with recommended workers configured, there should be no issues.

For endpoint telemetry, the agent can be deployed everywhere using scripts based on Windows, Linux, and Kubernetes. Once the edge script is obtained, it can be deployed across all endpoints to gather data.

Currently, there are no significant enhancements needed as Cribl is a reliable product.

One improvement opportunity exists with Git integration. Git is attached to Cribl, and while users can push changes from Cribl to the Git repository, pulling changes from Git back into Cribl is not automated. When changes are made directly in the Git repository, they must be manually pulled into Cribl. For example, if a source is created in Cribl, it can be pushed to the Git repository, but modifications made directly in the Git repository must be manually pulled back into Cribl. Automating this pull functionality would be a valuable enhancement.

Cribl has been used for the last six or seven years.

No stability issues have been encountered. Occasionally, back-pressure issues occur, but these are not caused by Cribl. Sometimes the source experiences issues, or destinations such as Dynatrace do not accept the data due to API hit limits when sending data via HTTP. During these times, back-pressure occurs, and when back-pressure takes a long time, the parsing queue can become full.

For scalability, the leader is configured for high availability with a standby leader. Standby workers are also maintained. Currently, there are 16 workers in total with six additional workers kept as standby. If a worker fails, Cribl can be started on these standby workers to maintain operations.

Customer service is not required as the product is managed internally. Three or four people manage the product exclusively. Technical service support is not utilized because the team consists of certified Cribl engineers who have comprehensive knowledge of the product.

Initial setup is straightforward, particularly for those familiar with Splunk. The installation is similar to Splunk—unzip the leader package and install it. The worker installation follows the same process. Installation is very simple. For cloud deployments, there are no issues as URLs are provided.

A consultant from NetScaler, an authorized partner of Cribl, was brought in to guide the implementation. This person provided guidance, but the team completed the implementation internally. Assistance from Cribl is obtained whenever needed through this consultant.

Other alternatives exist, including Splunk, Enterprise Security (ES), and Itsee. Many other products are also available.

Cribl offers several advantages over alternative solutions. Managing the infrastructure, including workers and the leader, is very simple. Patching is also straightforward and requires only one click. The user interface is user-friendly.

Alternative products have many limitations that Cribl does not have. Other products may have issues with data acceptance and compatibility. Cribl accepts data over various ports, including TCP, HTTP, and UDP, as well as HEC tokens. Cribl also supports custom sources that can be added, a feature that is missing in other platforms.

Pricing is always discussed with high-level business teams, and involvement in pricing discussions is limited. However, Cribl is very inexpensive compared to Splunk licensing, which is a significant advantage for organizations purchasing Cribl.

Upgrading is a one-click activity. The version is selected, the leader is upgraded, and then the worker is deployed with a single click to upgrade the entire infrastructure. This capability has not been seen in any other product.

Data complexity is not a concern. Although there are many fields, each field has a question mark next to it that provides a description of what needs to be entered in the checkbox or dropdown below. The UI presents all information clearly. Without prior knowledge, anyone logging into the UI and navigating through sources, destinations, and other configurations can easily understand everything.

The overall review rating for this product is 9 out of 10.

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.

I use Cribl in a data management platform for IT security teams. My use cases include Stream, Edge, Search, and Lake.

I appreciate data routing the most about Cribl. I use it for data routing, data processing, and integration support. Cribl's ability to handle high volumes of diverse data types such as logs and metrics is impressive. It can easily handle logs because it is highly scalable and built to process millions of events per second, making it very easy to use.

What I dislike about Cribl are the documentation gaps and the setup complexity.

I have been working with Cribl for one year.

Regarding stability, once the pipelines were properly set up, the ongoing maintenance was minimal and mostly involved small adjustments rather than major changes. Overall, Cribl is not maintenance heavy, but sometimes maintenance is needed.Cribl requires some maintenance on my end; it is relatively low compared to traditional log pipelines.

Cribl provides high availability through distributed architecture, so we can achieve this by developing multiple workers and using load balancing to ensure continuous data flow even during failures in the pipeline.

The initial deployment is medium because the setup is complex. It took me some time to set it up for the first time because my friend helped me, but I found it difficult.

I have not seen a significant decrease in firewall logs while working with Cribl because it is highly scalable, so that much decrease has not occurred.

I am using Cribl Stream for data routing and data processing as part of my company's IT team. We primarily use it for monitoring and collecting data.

One of the best features is integration support because it offers more than 80 to 90 sources and destinations via Cribl packs. Additionally, the security is very good because they offer encryption and access control to protect sensitive telemetry data. The data processing and reduction is also excellent because it filters unwanted fields and removes redundant data.

I have seen a decrease in my firewall logs by 50 to 60%.

Cribl allows me to handle high volumes of diverse data, such as logs and metrics, and it helps manage them effectively.

It is helpful because it handles diverse data types and can process logs, metrics, event streams, JSON, text, structured and unstructured data.

The user interface is acceptable, but I think a person who is just starting to use it will need to go through documentation because there is a steep learning curve to become familiar with Cribl Stream. The setup is also complex, and configuring integrations and pipelines for a large environment requires significant effort.

The areas that have room for improvement are the complex setup and better documentation, such as a user guide.

I have been using this product for six to eight months.

Cribl performs time-to-time updates and maintenance, and it must be managed effectively because we are using it daily and have not experienced any issues for a long time. The team maintaining it must be performing their job very well.

Horizontally, it is quite scalable, so I rate that a ten.

I rate the technical support a nine, and I rate the stability an eight.

I have used Splunk, and what Cribl does is it does not replace Splunk; it optimizes the data before sending it to Splunk, reducing cost and load. Therefore, Cribl is not a direct alternative to Splunk; they are complementary to each other.

The deployment was quite easy.

I do not know exactly how long it took to deploy because I was not the one who deployed it on the cloud, but the ones who deployed it told me that it was quite easy to deploy and there were no complaints from them.

Roughly five to six users use the solution.

I checked out Cribl Search once, and it helped me directly search from S3 data lakes, and it did help me save time and cost.

I have not analyzed the exact amount, but in ballpark terms, it saves about 10 to 20%.

I think it is cost-efficient because overall, after using Cribl, it helps users save cost and time. If you look at the big picture, it is cost-effective.

It saves me about 30 to 40% in terms of time and cost.

I would highly recommend it because it is cost-efficient, helps reduce noisy logs, and filters unnecessary fields.

I gave this review a rating of nine.

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

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

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

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

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

I used the solution about six months ago.

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

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

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

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

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

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

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

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

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

I use Cribl for data integration, pipelining, data monitoring, scalability, and to check how my monitor is working. The main product we use is Cribl Stream, which we use for log routing, filtering, and transforming data before sending it to our SIEM platform. This is the core part of our log management pipeline. Through Cribl Stream, we mainly work with features such as data pipelining, routing rules, and data transformation functions to control how logs move between different systems. My hands-on experience is primarily with Stream, since that is the component we rely on most for processing and optimizing log data in our environment.

The main product we use is Cribl Stream, which we use for log routing, filtering, and transforming data before sending it to our SIEM platform. Through Cribl Stream, we mainly work with features such as data pipelining, routing rules, and data transformation functions to control how logs move between different systems. My hands-on experience is primarily with Stream, since that is the component we rely on most for processing and optimizing log data in our environment.

One of the biggest advantages for my organization is better control over log data. We can filter, transform, and route logs before they reach downstream systems such as the SIEM platform, which helps reduce noise and focus only on relevant data. Another key benefit is cost optimization. By dropping unnecessary logs and sending only important data, we significantly reduce ingestion and storage costs in tools such as Splunk. It also improves operational efficiency.

One key area is simplifying the user experience, especially for new users. Since it has multiple components such as metrics, traces, and detectors, making onboarding and navigation more intuitive would be beneficial. One area of improvement could be reducing the learning curve. Since it is a very flexible tool with powerful pipeline configuration, new users may take some time to fully understand how to design and optimize pipelines efficiently. Another improvement could be more pre-built templates or out-of-the-box integration of common data sources, which would help teams get started faster without building from scratch. I also think enhanced monitoring and troubleshooting visibility for pipelines would be helpful, especially in large environments where multiple data flows are being processed.

The main strength is its flexibility, scalability, and cost optimization benefits. It gives strong control over what data is processed and sent to downstream systems. The reason I would not give it a ten is mainly due to the learning curve and initial complexity, especially for new users. Some areas such as documentation or advanced troubleshooting could be improved.

I have been working in the cybersecurity and security operations space for around one year.

Cribl is stable and reliable. I would rate stability and reliability at eight out of ten. In my experience, it is generally performing well.

I would rate the scalability of Cribl at eight or nine out of ten. Its ability to handle a high volume of different data types would get a rating of eight or nine out of ten. It is designed to process large-scale telemetry data from multiple sources such as firewalls, cloud services, applications, and infrastructure. It can handle different formats such as JSON, syslog, and custom logs, and transform them within the pipeline with its distributed architecture. We can scale horizontally by adding worker nodes, which allows it to handle increased data volumes without major performance issues.

We faced an issue with a pipeline dropping certain log events unexpectedly. We reached out to support, and they helped us analyze the pipeline configuration and logs. Initially, the response was general, but after sharing more details such as sample logs and pipeline rules, they were able to identify that the filter condition was incorrectly configured, which was causing the data to be dropped. They guided us on how to modify the rule and validate the data flow using a live preview, and we were able to resolve the issue very quickly. Overall, the support team was very helpful and knowledgeable, especially once the issue was clearly explained, and it helped us solve the problem without major downtime.

Before Cribl, most log processing was handled directly within the SIEM platforms, mainly using tools such as Splunk native and sometimes Logstash for data processing. The limitation with that approach was that all the raw log data was first ingested into the SIEM, and then filtering or transformation were applied afterwards. This increased the data volume and cost complexity. We moved to Cribl to introduce a dedicated data pipeline layer before the SIEM, which allows us to filter, transform, and route data more efficiently before ingestion.

As I am on the technical side, I was involved in the initial setup of Cribl. My role included configuring data sources, setting up pipelines, and defining routing and filtering rules based on our different requirements. I also worked on integrating Cribl with our SIEM platform, ensuring that only relevant and optimized data is forwarded. During the setup, we focused on designing efficient pipelines, testing data flow, and validating transformations to make sure everything was working correctly. Overall, the initial setup was not very complex, but it required proper planning to design the pipelines.

Other than this platform, it is more valuable. Before adopting Cribl, we did look at a few other approaches. Some of the evaluations were around using native capabilities within SIEM platforms such as Splunk, as well as open-source log processing tools such as Logstash for handling data pipelines. Those options can work for log collection and processing, but Cribl stood out because it provides a dedicated platform specifically designed for observability and security data pipelines. It offers more flexibility in routing, filtering, and transforming logs without heavily relying on the SIEM itself. The visual pipeline management and real-time visibility into data flow were also important factors that made Cribl a better fit for managing large volumes of log data across multiple systems. We saw other options, but by way of references, we determined that Cribl is more relevant for our work. So we chose Cribl.

I would recommend starting with a few simple pipelines, then gradually expanding as you become more comfortable with the platform. I would rate Cribl eight out of ten. A few improvements in Splunk Observability Cloud could make it even better. Overall, I would give Cribl a rating of 8.5 out of ten.