Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Refactor] Mix-up of NLB and ECS APIs #120

Open
r0b0ji opened this issue Apr 13, 2022 · 3 comments
Open

[Refactor] Mix-up of NLB and ECS APIs #120

r0b0ji opened this issue Apr 13, 2022 · 3 comments
Labels
effort: large Large development effort enhancement Existing feature enhancement

Comments

@r0b0ji
Copy link

r0b0ji commented Apr 13, 2022

Currently, I see the ECS monitoring has been combined with NLB, ALB. For ex:

  1. monitorFargateService: monitors Fargate service, loadbalancer, targetGroup
  2. monitorSimpleFargateService: monitors Fargate service
  3. monitorFargateNetworkLoadBalancer: looks similar to monitorFargateService but here the loadbalancer and target group are passed separately and not from FargateService
  4. monitorApplicationLoadBalancer: similar to monitorFargateNetworkLoadBalancer but instead of NLB, it is for ALB
  5. monitorQueueProcessingFargateService:
  6. monitorQueueProcessingEc2Service

A better refactor and re-org in my opinion should be to split into specific parts and each part responsible for monitoring its own resource. This is my initial refactor proposal, but feel free to discuss and refactor as required.

Let's just have monitorSimpleFargateService and monitorSimpleEc2Service (we can even remove simple from name), where first monitors just FargateService and second monitors just Ec2Service. Then have monitorNetworkLoadBalancer, which monitors NetworkLoadBalancer and NetworkTarget Group, monitorApplicationLoadBalancer which monitors ApplicationLoadBalancer and ApplicationTargetGroup.

Now,

  1. remove /lib/monitoring/aws-ecs-patterns module or maybe keep it and then monitorNetworkLoadBalancedFargateService internally calls monitorFargateService, monitorNetworkLoadBalancer, monitorApplicationLoadBalancedFargateService calls monitorFargateService, monitorApplicationLoadBalancer, monitorQueueProcessingFargateService calls monitorFargateService and monitorSQS. Same for Ec2Service
  2. add a module /lib/monitoring/aws-ecs, this module contains monitorFargateService, monitorEc2Service

This is my mental model. I am happy to discuss more.

@echeung-amzn echeung-amzn added enhancement Existing feature enhancement backlog labels Apr 13, 2022
@ayush987goyal ayush987goyal added the effort: large Large development effort label Apr 13, 2022
@RichiCoder1
Copy link

Wanted to pipe in my two cents and support this. While it's nice to have the high level combined patterns, my expectation is it's ultimately instrumenting the primitives and underlying services.

@voho
Copy link
Contributor

voho commented Aug 23, 2022

I agree that this is the right way to do it. But we have to handle this in a backwards-compatible way. Internally, I believe we already have a separation for service / load balancer / target group, but the API combines them.

@mobob
Copy link

mobob commented Oct 21, 2024

Support this for sure, having a scan of the APIs and things seem a bit wonky.

Also going to pipe in as a new-ish user; the API's for Fargate seem to be somewhat incongruent with the other constructs APIs in as much as they accept a FargateService as opposed to an IFargateService... a quick pass over and my usual methods for manifesting references to my services for monitoring does not apply (storing ARNs in SSM). I understand i can pass the references directly around but CDK usually punishes me for that 👊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: large Large development effort enhancement Existing feature enhancement
Projects
None yet
Development

No branches or pull requests

6 participants