(CDK watch): stream cloudwatch logs of hotswapped resources

[corymhall]

Description

It would be amazing if running cdk watch would trace the logs of the deployed Lambda Function/ECS Service/... directly into the customer's console, without the need for going to CloudWatch.

Use Case

The use case here is if I am using cdk watch to iterate on code changes to a Lambda Function (or ECS service, etc) I want to be able to view the logs from that Function directly in my terminal. This will help in debugging my application without having to navigate to the CloudWatch logs console.

Proposed Solution

There are a couple different ways we could go about implementing this feature. Should this be a watch specific feature, or a general logs feature similar to sam logs? Suppose we had a CDK application that had 10 different Lambda Functions. When we run cdk watch what do we want to happen?

Solution 1 - watch specific feature:
In this solution we only want to stream logs for the resources that are being hotswapped. So in our above example, if we had 10 Lambda functions and we make a change to 1 Function, we should only see the logs for that 1 function.

• Logs would appear as part of the same terminal output as the rest of cdk watch
• For Lambda Functions we could automatically determine the associated log group based on the function name. (i.e. /aws/lambda/function-name).
• For ECS Services we could determine the log group based on the container definition, but not all ECS services have to use CloudWatch logs.

{
  "TaskDef": {
    "Type": "AWS::ECS::TaskDefinition",
    "Properties": {
      "ContainerDefinitions": [{
        "LogConfiguration": {
          "Options": {
            "awslogs-group": {
              "Ref": "LogGroup"
            }
          }
        }
      }]
    }
  }
}

• For other things this could get more difficult. What "logs" do we want to stream for a stepfunction state machine? Should we stream the logs from individual components of the state machine (i.e. if the stepfunction calls a Lambda function)? Or should we stream back the actual state machine execution? Or both?

Other Solutions
We could also stream all logs from all hotswappable resources in the application, but this could become too verbose.

Alternatively we could ask the user for input on which CloudWatch log groups to monitor, i.e.

cdk watch --log-groups abc,xyz

Other information

No response

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change

[skinny85]

Solution 1 - watch specific feature:

I think this is definitely the way we want to go here.

If we later extract this functionality to be more generic, so that it can be used outside cdk watch - that's great. But that will be a separate issue.

For now, let's focus on making it cdk watch-specific.

In this solution we only want to stream logs for the resources that are being hotswapped. So in our above example, if we had 10 Lambda functions and we make a change to 1 Function, we should only see the logs for that 1 function.

• Logs would appear as part of the same terminal output as the rest of cdk watch
• For Lambda Functions we could automatically determine the associated log group based on the function name. (i.e. /aws/lambda/function-name).

I believe you can also set a custom Log Group for a Function, so you probably need to handle them similarly to how you suggest doing it for ECS services below:

• For ECS Services we could determine the log group based on the container definition, but not all ECS services have to use CloudWatch logs.

{
  "TaskDef": {
    "Type": "AWS::ECS::TaskDefinition",
    "Properties": {
      "ContainerDefinitions": [{
        "LogConfiguration": {
          "Options": {
            "awslogs-group": {
              "Ref": "LogGroup"
            }
          }
        }
      }]
    }
  }
}

Other Solutions We could also stream all logs from all hotswappable resources in the application, but this could become too verbose.

I think it's fine if the initial version streams logs from all resources in the application if that makes the solution simpler - remember that things generally only get logged when you call the underlying service, so there shouldn't be that many logs to trawl through (and it if turns out there are, we can always iterate on the experience later).

• For other things this could get more difficult. What "logs" do we want to stream for a stepfunction state machine? Should we stream the logs from individual components of the state machine (i.e. if the stepfunction calls a Lambda function)? Or should we stream back the actual state machine execution? Or both?

If the StateMachine logs to CloudWatch, then that would be a great start (I assume its logs also include some logs about the individual Tasks inside the machine). Logs for the individual Tasks in the State Machine would be fantastic, but I assume so complex, that it would have to be done in a separate PR.

However, I think it's fine if the initial PR for this feature included only Lambda support, and then we handled supporting other resource types (ECS Services, StepFunction State Machines, etc.) in follow-up tasks.

Alternatively we could ask the user for input on which CloudWatch log groups to monitor, i.e.

cdk watch --log-groups abc,xyz

We could, but that's a pretty "meh" experience. I would at least use the name of the resource, instead of the name of the Log Group. But I wouldn't include this option in the initial version of the feature.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.