Amazon CloudWatch vs. Elasticsearch

If you use any AWS services, CloudWatch is the natural choice to monitor & troubleshoot your workload. Thankfully, for most AWS services, CloudWatch is either built-in or very easy to set up. However, being proficient in browsing & tracking the log events would take some training & practice. Having some experienced people on the team would help immensely, especially in spreading the skill to the rest of the team.

Incentivized

Elasticsearch is really well suited for searching text (Natural Language Processing) and you can fine tune the searches and scoring very well. I like the ability to find Significant Terms in the Index, where you can find aggregations that are really relevant to a specific search. It also allows for queries to lead to new queries via aggregations which is great for navigating your data. It is less suited to doing more complex aggregations where slices of data are required to be processing using guassian normalizations. And doing searches which join different documents is very very hard, and requires serious thought on how to denormalize data.

Incentivized

• It provides lot many out of the box dashboard to observe the health and usage of your cloud deployments. Few examples are CPU usage, Disk read/write, Network in/out etc.
• It is possible to stream CloudWatch log data to Amazon Elasticsearch to process them almost real time.
• If you have setup your code pipeline and wants to see the status, CloudWatch really helps. It can trigger lambda function when certain cloudWatch event happens and lambda can store the data to S3 or Athena which Quicksight can represent.

Incentivized

• Super-fast search on millions of documents. We've got over 2 billion documents in our index and the retrieve speeds are still in the < 1-second range.
• Analytics on top of your search. If you organize your data appropriately, Elasticsearch can serve as a distributed OLAP system
• Elasticsearch is great for geographic data as well, including searching and filtering with geojson, and a variety of geospatial algorithms.

Incentivized

• Memory metrics on EC2 are not available on CloudWatch. Depending on workloads if we need visibility on memory metrics we use Solarwinds Orion with the agent installed. For scalable workloads, this involves customization of images being used.
• Visualization out of the box. But this can easily be addressed with other solutions such as Grafana.
• By design, this is only used for AWS workloads so depending on your environment cannot be used as an all in one solution for your monitoring.

Incentivized

• Setting Java memory thresholds can be a pain for those not accustomed to things like Eden Space & Old Generation which can lead to over allocation, or more likely, under allocation. Apache Solr had a similar issue. It would be nice if the program would take an extra step and dogfood it's own advice by analyzing the system & processes to return a solid recommendation for that configuration. The proper configuration information is outlined in the documentation, it would be nice if that was automated.
• The only health check that ElasticSearch reports back is a "red" status without any real solid information about what is going on, though its usually memory thresholds or disk I/O. I am currently on ElasticSearch 1.5 so that may have changed for newer versions. When the status goes "red", I as the administrator of the software, feel like I lose control of whats going on which should rarely happen. Something more verbose would eliminate that.
• This is more of a critique of the ElasticStack in general. The whole top to bottom stack is starting to get feature creep with things that are better suited in other software and increasing the barrier for entry for people to get started with setting up a robust logging infrastructure. ElasticSearch as a storage search engine, is pretty streamlined, but I can see that the tools that comprise the ELK Stack are going to require a certification with constant study at some point. During major release for Logstash a while back, it literally took a month to learn a new language because Elastic completely changed the syntax. For a medium sized organization of only a couple of admins, that is a pretty high bar where time is money. They really should work on refining/automating the tools & search engine they have, instead of shoehorning/changing things on to an already rock solid foundation.

Incentivized

We're pretty heavily invested in ElasticSearch at this point, and there aren't any obvious negatives that would make us reconsider this decision.

Incentivized

Although the tool itself is easy to integrate and is readily available for use, it has its limitations. The key limitations of cloudwatch are with respect to cost incurred on log retention and log querying. While for key use cases this is sufficient, for more advanced use cases, Amazon CloudWatch doesn't work out. Also, obviously it is tightly coupled with AWS, which makes you look away if you need a single tool for all monitoring

Incentivized

To get started with Elasticsearch, you don't have to get very involved in configuring what really is an incredibly complex system under the hood. You simply install the package, run the service, and you're immediately able to begin using it. You don't need to learn any sort of query language to add data to Elasticsearch or perform some basic searching. If you're used to any sort of RESTful API, getting started with Elasticsearch is a breeze. If you've never interacted with a RESTful API directly, the journey may be a little more bumpy. Overall, though, it's incredibly simple to use for what it's doing under the covers.

Incentivized

Support is effective, and we were able to get any problems that we couldn't get solved through community discussion forums solved for us by the AWS support team. For example, we were assisted in one instance where we were not sure about the best metrics to use in order to optimize an auto-scaling group on EC2. The support team was able to look at our metrics and give a useful recommendation on which metrics to use.

Incentivized

We've only used it as an opensource tooling. We did not purchase any additional support to roll out the elasticsearch software. When rolling out the application on our platform we've used the documentation which was available online. During our test phases we did not experience any bugs or issues so we did not rely on support at all.

Incentivized

Do not mix data and master roles. Dedicate at least 3 nodes just for Master

Incentivized

We use Cloudwatch for simpler monitoring, but these metrics and logs often feed into bigger ecosystems across our organization. The metrics and logs in Cloudwatch allow our developers quick and easy access to the data they need whilst easily integrating the same data into more prominent platforms for wider analysis, including Service desk support, SecOps, and ITOps monitoring within the organization.

Incentivized

Elasticsearch is the most well-known and supported free data platform that we identified. We are taking advantage of community knowledge and practices. In terms of flexibility and breadth of use cases no other competitor came close to Elasticsearch. We've tried Solr in the past be we encountered issues which were deal-breaking for us. MongoDB - it just did not pass our evaluation parameters as a main data platform. We still use it for smaller purposes, though.

Incentivized

• Positive for alarms and alert notifications once configured/customized.
• Has upfront learning curve, and cost can increase as does the alarm activity and monitoring details you may require.
• Cost-effective for any size organization keeping with AWS and utilizing its native tools is a savings in long-term ROI.

Incentivized

• I am not in finance and I suspect even if I was this would be hard to measure. But for sure, Elasticsearch has enabled us to have the most flexible data model in the industry for our customer's data, and in doing so we have attracted many many technical customers and got much of their $$$.
• One problem with Elasticsearch is that because it runs on the JVM, there can be some stop-the-world JVM garbage collections happening that can take down nodes and reduce indexing speed. The solution for that tends to be "let's just upgrade the CPU on that machine". And before you know it you are paying $$$ because this'll happen with 40+ machines.
• On the other hand, I do think that ES is more efficient than other systems and so it requires fewer nodes to keep it highly tolerant and available, so we probably saved some money that way.

Incentivized