3 ms·

I'd argue that cloudwatch is mainly an event source to drive other AWS infrastructure. Monitoring second, which might be why the experience is so sour.

QuinnyPig 8y ago
You could definitely make that argument, but the CloudWatch product page's first sentence is "Amazon CloudWatch is a monitoring and management service built for developers, system operators, site reliability engineers (SRE), and IT managers." CloudWatch Events is largely solid; I agree with you!
- derefr 8y ago
  Think of them as two separate products, and then mentally invert the branding: "CloudWatch" (and the rest of its umbrella) are really sub-products of "CloudWatch Events." How did that happen? Accident of history: First, CloudWatch Events was built for internal AWS usage. Then, CloudWatch was also built for internal AWS usage (EC2 health checks, fed by the event stream!) Then, CloudWatch was exposed, since people need to be able to configure those health checks and provision them in CloudFormation and such. So, they had this "monitoring" service—may as well slap together a logging dashboard and stuff. (And then forget about that as soon as the MVP is done, because writing their own equivalent of the Elastic-Logstash-Kibana stack was never AWS's intent.) Then, after SNS came around and there was somewhere user-controllable for the raw CloudWatch Events events to be routed to, CloudWatch Events could be exposed, too. It got the sub-name because they had exposed the higher-level CloudWatch product first. If SNS came about before CloudWatch, then probably it'd just be CloudWatch Events with a set of suggested "one-click launchable partner AMIs" for ingesting+indexing+searching/analyzing your AWS event data, and no first-party dashboard at all. And "CloudWatch" would remain an internal feature to power health checks without its own branded dashboard; just an unbranded presence under other services' dashboards/RPC endpoints/CloudFormation type hierarchies.
  - tracker1 8y ago
    I really wish they would go so far as to get a Kibana-like front end and expand CW to ElasticSearch levels of UX. In the end, I really appreciate the ELK stack, and if you can either use ElasticSearch for other things, or have enough logging to justify a cluster, it (ELK) is a great option.

QuinnyPig 8y ago

You could definitely make that argument, but the CloudWatch product page's first sentence is "Amazon CloudWatch is a monitoring and management service built for developers, system operators, site reliability engineers (SRE), and IT managers." CloudWatch Events is largely solid; I agree with you!

derefr 8y ago
Think of them as two separate products, and then mentally invert the branding: "CloudWatch" (and the rest of its umbrella) are really sub-products of "CloudWatch Events." How did that happen? Accident of history: First, CloudWatch Events was built for internal AWS usage. Then, CloudWatch was also built for internal AWS usage (EC2 health checks, fed by the event stream!) Then, CloudWatch was exposed, since people need to be able to configure those health checks and provision them in CloudFormation and such. So, they had this "monitoring" service—may as well slap together a logging dashboard and stuff. (And then forget about that as soon as the MVP is done, because writing their own equivalent of the Elastic-Logstash-Kibana stack was never AWS's intent.) Then, after SNS came around and there was somewhere user-controllable for the raw CloudWatch Events events to be routed to, CloudWatch Events could be exposed, too. It got the sub-name because they had exposed the higher-level CloudWatch product first. If SNS came about before CloudWatch, then probably it'd just be CloudWatch Events with a set of suggested "one-click launchable partner AMIs" for ingesting+indexing+searching/analyzing your AWS event data, and no first-party dashboard at all. And "CloudWatch" would remain an internal feature to power health checks without its own branded dashboard; just an unbranded presence under other services' dashboards/RPC endpoints/CloudFormation type hierarchies.
- tracker1 8y ago
  I really wish they would go so far as to get a Kibana-like front end and expand CW to ElasticSearch levels of UX. In the end, I really appreciate the ELK stack, and if you can either use ElasticSearch for other things, or have enough logging to justify a cluster, it (ELK) is a great option.