You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
monitorSimpleFargateService: monitors Fargate service
monitorFargateNetworkLoadBalancer: looks similar to monitorFargateService but here the loadbalancer and target group are passed separately and not from FargateService
monitorApplicationLoadBalancer: similar to monitorFargateNetworkLoadBalancer but instead of NLB, it is for ALB
monitorQueueProcessingFargateService:
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,
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
add a module /lib/monitoring/aws-ecs, this module contains monitorFargateService, monitorEc2Service
This is my mental model. I am happy to discuss more.
The text was updated successfully, but these errors were encountered:
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.
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.
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 👊
Currently, I see the ECS monitoring has been combined with NLB, ALB. For ex:
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,
This is my mental model. I am happy to discuss more.
The text was updated successfully, but these errors were encountered: