aws / aws-app-mesh-roadmap

AWS App Mesh is a service mesh that you can use with your microservices to manage service to service communication
Apache License 2.0
347 stars 25 forks source link

Feature Request: Support App Mesh CloudWatch Events #169

Open tomaszdudek7 opened 4 years ago

tomaszdudek7 commented 4 years ago

Tell us about your request I'd love to have an easy option to catch and react on various App Mesh events in CloudWatch, for example VirtualRouterChangedEvent, VirtualServiceAddedEvent, MeshChangedEvent etc

Which integration(s) is this request for? ECS, Fargate, EC2 and EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? I am building a gateway to my mesh using Spring Cloud Gateway(framework is irrelevant though). If I had the CW Events available, I could for example dynamically add and remove routes on my gateway based on the App Mesh configuration. I'd just to listen to SNS/SQS for relevant App Mesh events and update gateway's configuration based on that. Initial routes configuration on gateway startup would be just created using AWS API by describing all the routers and routes.

Are you currently working around this issue? I am not sure yet - looking into possibilities with CloudTrail to SNS, as every AppMesh call is indeed saved to CloudTrail. But it may be hard/pricey.

Additional context

Attachments

bcelenza commented 4 years ago

Hey @spaszek, great idea!

CloudTrail is certainly a viable workaround today, but there can be a short delay (in minutes) for entries showing up there, which may be too long for how you'd want to react to these changes.

A couple early questions come to mind:

  1. What would you want to see in the payload for these kinds of events? The current 256KB limit is probably enough to plug the whole resource spec, but not sure how useful that would be.
  2. Would you also want events for things occurring on the Envoy / data plane side? For example, we could emit events for when Envoys connect, disconnect due to error states, NACK configurations, etc.
tomaszdudek7 commented 4 years ago
  1. In "MVP" of this feature, the information that given mesh/router/node changed would be enough for me - application would handle the event logic by itself. In the future, the information what has actually changed could be useful.
  2. This could be great to implement custom monitoring/statistics. I don't need it in the potential MVP though, just the Virtual Node/Router/Mesh/Routes Events are sufficient.