What needs improvement with Cribl?

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.

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.

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.

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.

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.

There is room for improvement in Cribl, as managing data from around forty thousand servers can become complex. Automating the upgrading process for the Cribl agent would significantly improve usability, especially since we sometimes experience issues when using Blade Logic for updates. I would appreciate more automation in the processes, and I have not explored the AI features that Cribl offers, such as ChatGPT.

I would like to see improvements in the metrics and traces, as Cribl is currently more geared towards logs, making it hard to get very long traces to view in the UI when they are quite big. I have not used metrics much because I am aware of the issues Cribl has with handling proper metrics, particularly with multi-metrics when there are multiple dimensions into a single metric. We use Cribl nearly 99.9% for logs only, not for metrics and traces, but I hope to see improvements in the future. On the other hand, I would like to see improvements in pack management, which is currently a mess with no way to manage packs differently across worker groups. I also wish Cribl would introduce more functions, as sometimes we have to create more JavaScript functions ourselves. Aside from that, everything is going well, especially with recent AI integrations.

Some downsides of Cribl include that it was quite a long sales cycle for us, but that was probably partly my fault as well. There weren't really any negatives on the product itself. Cribl can do better by tightening up their Cribl packs, as I think there were numerous flavors of different configurations that weren't supported. There were a lot of unsupported Cribl packs and they probably need to get that certified or do something about that.

I think a lot of companies would benefit from a smaller starting license. Perhaps make it free till 100GB for 1st year, that way companies will adopt easier.

I don't think there is much complexity because the documentation is good and Cribl University helps a lot to understand the product. Cost is sometimes a problem with customers if they don't have budgets. Otherwise, it is not that much. The value addition that Cribl provides compared to the cost is significant. Cribl is easier to use. The only area that Cribl should focus on is cost-effectiveness. I have deployed Cribl at four clients, and the major challenge in convincing them was the cost.

To develop user skills in Cribl, it needs to improve some certifications, as the ones I have taken are not entirely helpful in the main projects for the clients. The documentation requires more improvement in the certification aspect to better develop user skills.

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

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

Cribl handles a high volume of diverse data types very well, such as logs and metrics. However, the endpoint plug-in tool can use some refinement, as it tends to hit system resources and can sometimes be detrimental to systems to the point where it must be turned off and a scan restarted when a user is offline. Outside of the endpoint issue, there may not be much that Cribl can do better in the program itself. It becomes tedious when one-off fixes are needed because a user submits a ticket complaining that their system is unusable due to Cribl performing a scan.

Cribl can improve by providing automated analytics and advanced parsing capabilities since it handles data at its core. I'm particularly interested in innovations such as Cribl Guard for automated PCI and PII masking, and a more stringent role-based access control feature would enhance security and allow granular control over what users can see and access.

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

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

There are opportunities for AI to be incorporated more tightly into Cribl to help build out those pipelines and apply some more complex logic to those transformations could be useful. Optimizing CPU utilization on the edge side is something that could be improved; we see, particularly on older hardware and older OSes, Cribl Edge service can eat up quite a bit of CPU resources compared to some other products we've used in the past, indicating there's room for improvement.

The product is very good. They could add more AI-assisted pipeline development in the future release.

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.

So since we’re handling a ton of data, I think we could really benefit from a more integrated or connected way to manage it all. Like, if there is a way to better track data lineage, metadata, those can help with knowledge transfer.

Something that Cribl could do better is processing time. There is not enough customization to improve performance. An example would be with AWS Lambda functions, the way we were doing it before. There are different strategies where the way we code it could save us more processing time and still have the same price. With Cribl, it is very much set in its ways. If you want better performance, then you have to pay for more resources. The UI is a very beneficial thing that saves us a ton of time. I mentioned the copy and paste approach and little to no code anymore, as it is all UI interface-based now. There is little to no code that we do other than regex commands. If there was still some aspect of being able to add our own code, we could potentially get better performance. I understand this is the whole use case of Cribl, to remove the technical need aspect. You do not need as many experienced developers; you will pay for software and have to hire an analyst instead of an engineer and save money on wages. For how good the tool is, it would be nice to still have that data engineering aspect.

Cribl Stream is good, but I feel they could develop more products apart from Cribl Stream for my use case. I know Search is coming and Data Lake is there, but there can be more innovations in Cribl. They had one good product, which is Cribl Stream, which appears to be the primary revenue source for the company, but there may be many other use cases. They could explore OTel and how to connect with DynaTrace. They are looking specifically for logging, but expanding into metrics and APM would also help.

At the moment, I don't have specific feedback on what can be improved as I do not work with Cribl daily. Perhaps more flexibility in terms of metrics would be helpful.

The documentation part could be better. Their documentation could be updated, as new features often outdated existing information. Additionally, there are inconsistencies between the documentation for Cribl Cloud and Cribl on-premises. This can be confusing, as features may differ, leading to potential misunderstandings if you use documentation intended for one version while working with another. Consolidating and improving the clarity of the Cribl Cloud documentation would be very helpful.

Cribl should consider adding more features that are applicable to smaller firms, allowing broader access to their data migration through Cribl. Additionally, there's room for more enhancement concerning the desktop server so tasks can be processed more directly.

There is room for improvement in the documentation and knowledge base, particularly regarding configurations like sources where logs are being ingested. It would be helpful to have specific guidance on configuring different data sources, such as AWS S3 buckets. Additionally, the ability to understand what type of output a function will produce is missing in Cribl, which could be improved by indicating the output type.

There have been several administrative issues. Another point is that the browsing functions aren't very intuitive. The most challenging aspect is the versioning system. Everyone can see and potentially deploy each other's changes in a team of developers. Unlike traditional versioning systems, where you work in isolated feature branches and only merge changes after reviewing conflicts, Cribl's versioning system requires careful management because everyone works on the same repository. I work with a team that includes both experienced and less experienced developers. Though new to this technology, the two senior developers have extensive experience with various other technologies and can get up to speed relatively quickly with the available training. The less experienced developers face significant challenges. They struggle to understand the system, suggesting it may not be intuitive.

Cribl has simplified many aspects of the onboarding process, but there's still room for improvement. Currently, no other tools in the market truly compete with Cribl in its niche. Splunk is trying to retain customers by developing ingest actions to reduce licensing costs, hoping to prevent them from switching to Cribl. There is no alerting mechanism for the leader/worker nodes status. Since Cribl plays a major role in the mid-layer between the source and destination, there's a slight risk of losing data at some points while receiving real time data. It would be helpful if Cribl could temporarily store or index the data for a specific time range. This would prevent data loss during downtime. Additionally, there's room for improvement in how Cribl handles historical data. Currently, I can't view trends beyond a week, and even then, it’s often limited to just 24 hours. Since Cribl doesn’t index the data but only forwards it, extending the period for viewing statistics and monitoring trends would be a valuable enhancement.

Cribl has a good community base, but unlike some vendors like Splunk, which has many TAs, Cribl doesn't have as many packs available. They need to focus on developing more custom packs for various vendors so that their solutions can be used more effectively. This will help users identify which logs are necessary and which are not.