aws / aws-toolkit-vscode

Amazon Q, CodeCatalyst, Local Lambda debug, SAM/CFN syntax, ECS Terminal, AWS resources
https://marketplace.visualstudio.com/items?itemName=AmazonWebServices.amazon-q-vscode
Apache License 2.0
1.5k stars 427 forks source link

Allow for viewing CloudFront's CloudWatch Logs #1886

Open chrisbbreuer opened 3 years ago

chrisbbreuer commented 3 years ago

Is your feature request related to a problem? Please describe.

It is not related to a problem. In fact, the plugin is working as expected but when working with Lambda@edge functions, the relating CloudWatch log files may be stored in different regions.

Describe the solution you'd like

It would be incredibly useful for debugging reasons to have "CloudFront Logs" which could be structured similarly to "CloudWatch Logs" but it simply would be an aggregation of all of the CloudFront logs through all regions that contain CloudFront logs compared to the one your AWS account has currently selected.

Describe alternatives you've considered

The only alternative at the moment is searching for those log files manually. This flow requires you to leave the editor and it would be nice if you could stay completely inside it.

Additional context

image

(just adding the screenshot for reference of what section I am addressing)

In terms of how I would structure the UI aspect, I likely would choose to nest the CloudFront logs as follows:

CloudWatch Logs > CloudFront Logs > Regions

Would love to hear if others would find this a useful and logical addition.

JadenSimon commented 3 years ago

Interesting proposal. So you're wanting a new node inside the CloudWatch Logs node that is effectively the same across regions?

I'm not too familiar with CloudFront logs, but I thought they were normally sent to an S3 bucket for standard logging. If that's the case, then maybe we could add a way to list CloudFront logs from a designated bucket.

Some more context would be very helpful in determining how we should proceed, though this initial proposal is great nonetheless.

chrisbbreuer commented 3 years ago

Thanks for your kind response. And totally, let me provide some more context.

We utilize an Origin Request Lambda@edge function to apply some business logic prior to returning the image from the "Origin server."

image

Based on the geographical location where the request came from, it is used to determine in which region to store the associated Lambda@edge logs.

For example:

My default region for my AWS account is us-east-1 which means the CloudWatch Logs I am seeing are us-east-1-logs as

Screen Shot 2021-07-26 at 12 05 41 PM

As you can see, those 2 us-east-1 log files match what there is shown inside CloudWatch.

image

Now, the tricky part when debugging these Lambda@edge functions is that you have to figure out which region has logs for that associated edge function.

As an example, CloudFront utilizes the us-west-2 location for my personal requests which means that I could not find these log files inside Code Explorer.

image

To sum this all up, it would be great if we could add the CloudFront associated logs for all regions into the "CloudWatch Logs" because it would drastically simplify and streamline the Developer's Experience because you could then fully live inside VS Code without having the mental context switch each time you are debugging your edge functions.

PS: since CloudFront is a global service, it likely could make sense to structure it in this type of way as well:

image

JadenSimon commented 3 years ago

Oh wow thank you for the background info, it's very helpful! I think I understand the feature request much better now. In effect, the goal here is to organize CloudWatch logs in a logical way.

Would it be correct to say that in your specific use case, their exists multiple log groups across multiple regions with the same name? If that's the case, perhaps the generic solution here would be to have a feature for coalescing same-named log groups from multiple regions, displaying them as a 'grouped' node (global does make sense here). Then each sub-node would be a different region just like you were describing.

Presumably this desire to organize log groups isn't unique to CloudFront, which is why I'm trying to frame this in a more abstract way.

chrisbbreuer commented 3 years ago

Would it be correct to say that in your specific use case, their exists multiple log groups across multiple regions with the same name?

Yes, you are completely right. CloudFront creates these log groups and their name is same across all regions.

displaying them as a 'grouped' node (global does make sense here). Then each sub-node would be a different region just like you were describing.

Great thinking!

Presumably this desire to organize log groups isn't unique to CloudFront, which is why I'm trying to frame this in a more abstract way.

This totally makes sense as well and you are right that this concept may be applied to other "global" services. 🙂