Logstash is a must in an ELK stack, which I am sure is going to be the #1 case. At any point when you have several sources, Logstash can be the common point to aggregate, and categorize those data. Then send this new data to its destination. Very handy. It is free and open source. It may not be appropriate to analyze data-sets dependent on each other but from a different data source. Reason being Logstash works on data at hand, and not wait for other data to arrive. It would be unwise for Logstashh to handle complicated, long-running transformations because this is injected and ejected. The faster you do it, the safer.
SumoLogic is a fantastic log aggregator and analysis tool, a fine alternative to Splunk. Searching is powerful and mostly intuitive and results come fast. If you have application logs in clusters or Kubernetes pods that lose their logs every time they're restarted, Sumo is the solution for you
Log Aggregation and uploading. The architecture for Sumo Logic makes a great deal of sense and works very well.
Automated analysis. It still impresses me how well a newly uploaded log can be broken into intelligent parts, then searched and sorted using their tools.
Dashboards. It might not be what YOU will need as an IT admin, but you can give access to these dashboards easily to business users who love that kind of stuff. Most other types of (monitoring / alerting) tools, for no apparent reason, lack this feature.
Reporting, monitoring, and graphing. Given, you need to have useful log generation for an application or service as a prerequisite for sumo logic to be able to gain use, once it has it is an amazingly powerful tool.
Memory: Logstash is a HOG, if you are deploying it on commodity (i.e. cheap and old) hardware: You will need at least 2GB, just for Logstash. So don't expect to run your entire ELK stack on one AMD Athlon machine.
Overlap: Logstash fills in an area of the ELK stack that makes the most sense: as a log file transformer / shipper. However, if you start breaking that stack, with the addition of other components- you start seeing where features of Logstash may be implemented or solved in the additional components much easier (or better, or to a higher degree of resolution)
More Overlap: Since my team employs Syslog-ng extensively- Logstash can sometimes get in the way (and this may be a problem for DevOps stacks overall): You can configure Syslog to record certain information from a source, filter that data, and even export that data in a particular format. Logstash will pick that data up, and then parse it. However, if you don't keep your Syslog-ng configuration files, and your Logstash configuration files in sync, your results will not be what you expected, and this will translate into (sometimes) hours/days of work, hunting down a line item in a configuration file.
As I said earlier, for a production-grade OpenStack Telco cloud, Logstash brings high value in flexibility, compliance, and troubleshooting efficiency. However, this brings a higher infra & ops cost on resources, but that is not a problem in big datacenters because there is no resource crunch in terms of servers or CPU/RAM
Sumo Logic is very powerful but definitely requires some configuration work to get the most out of it. You can get a certification related to this, but it is definitely not something you can just throw together.
I would give this rating because I attended a free Sumo Logic training at a WeWork in Chicago. I found the training very useful, and I learned a lot of features that I was not aware of before I went to the training. I like the idea that SumoLogic provides free training seminars. I am certified in level1, and I plan on certifying to level2.
I was satisfied with the implementation, as at the time, it was the best way to implement the product with the available feature sets in Sumo Logic. User creation and management became more of an issue during continued use, instead of it being an issue related to deploying the product in our environment.
MongoDB and Azure SQL Database are just that: Databases, and they allow you to pipe data into a database, which means that alot of the log filtering becomes a simple exercise of querying information from a DBMS. However, LogStash was chosen for it's ease of integration into our choice of using ELK Elasticsearch is an obvious inclusion: Using Logstash with it's native DevOps stack its really rational
We had used Splunk previously. Sumo Logic defeats them when it comes to cost, including the costs that would normally come with supporting/managing/patching/upgrading your own infrastructure and storage. Those were wins, but especially the real-time CDN integrations due to Sumo Logic's collaborations with other vendors. We had spoken to Logentries and discovered that many of the cons we found with Sumo Logic seemed to have been resolved in their product. Their pitfall was that, at the time, Logentries did not have the ability to get real-time log ingestion from our CDN. They said they had a solution, which was scripted, but we had not evaluated/tested. Logentries also did not have a User / RBAC REST API, and are nowhere near the level of compliance that Sumo Logic had (https://www.sumologic.com/press/2015-02-19/sumo-logic-successfully-completes-pci-data-security-stand...). In the end, I believe Logentries and Sumo Logic would be two good vendors to get involved in a bake-off
It is very difficult to give any figures on ROI, as it depends on many factors, and in a Telcocloud environment, it is much complex to find out; however, I would give some points below on ROI
ROI based on flexibility is very high, as it reduces the time to find RCA
ROI based on integration is very high because it supports multi-vendor environments, avoiding vendor lock-in & works across multi-cloud setups
ROI on resource consumption is less because Logstash in 2-3 times more resource-intensive as compared to its lightweight alternatives resulting in latency
