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
{{ message }}
Repository navigation
[BUG] Log Links should work with CloudWatch FluentD Out Of the Box #2635
As it stands, users wishing to enable CloudWatch logs will need to go through the AWS Process to do so here and then manually modify the fluent-bit-config configmap to alter the generated log stream to match what Flyte expects.
kubectl edit cm -n amazon-cloudwatch fluent-bit-config
[OUTPUT]
Name cloudwatch_logs
Match application.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/application
log_stream_prefix var.
auto_create_group true
extra_user_agent container-insights
We should change the default template defined here to be: https://console.aws.amazon.com/cloudwatch/home?region=%s#logsV2:log-groups/log-group/%s$3FlogStreamNameFilter=var.log.containers.{{ .podName }}_{{ .namespace }}_{{ .containerName }}
This assumes that the cluster is going to be deployed with FluentBit by-default, while FluentD is valid and recommended option, to which the older configuration is pointing to. This change will not be applicable for the all users.
I was answering to the premise of this ticket. The log link is not broken if you use FluentD out of the box, it’s only broken if you’re using FluentBit, which is a default for EKS cluster. FluentBit can be ran in FluentD compatibility mode as well. Overriding default like will inevitably break it for the other group of users.
I think this is not a bug and supporting multiple templates is better solution here. Supporting FluentBit is related to flyteorg/flyteplugins#293, as it requires node name.
Aha, I understand, I agree changing the default can break other people, do you know for a fact that FlutentBit in compatibility mode works out of the box? I vaguely recall hostname was still a requirement though, no?
Perhaps a better approach is to:
Still add support for a host name template parameter
Instead of changing the default, add another CloudWatchV2Enabled flag that default to the new version format...
Add a "Enabling Cloud Provider-Native logs" where we can elaborate on templating for URLs, StackDriver, CloudWatch, FluentD and FluentBit.
Hello 👋, this issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will engage on it to decide if it is still applicable.
Thank you for your contribution and understanding! 🙏
Hello 👋, this issue has been inactive for over 90 days and hasn't received any updates since it was marked as stale. We'll be closing this issue for now, but if you believe this issue is still relevant, please feel free to reopen it. Thank you for your contribution and understanding! 🙏
Activity
Azanul commentedon Sep 30, 2022
I'd like to work on this.
Azanul commentedon Sep 30, 2022
#take
Azanul commentedon Sep 30, 2022
#self-assign
Azanul commentedon Oct 2, 2022
@samhita-alla here
Azanul commentedon Oct 15, 2022
#self-assign
Smartmind12 commentedon Oct 22, 2022
@samhita-alla Kindly review the PR and let me know if any changes are required...Thanks!
andrusha commentedon Nov 25, 2022
This assumes that the cluster is going to be deployed with FluentBit by-default, while FluentD is valid and recommended option, to which the older configuration is pointing to. This change will not be applicable for the all users.
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-logs-FluentBit.html
EngHabu commentedon Nov 26, 2022
@andrusha do you mind elaborating on this? Are you commenting on the discussion we are having on the PR? flyteorg/flyteplugins#293 (comment)
andrusha commentedon Nov 26, 2022
EngHabu commentedon Nov 26, 2022
Aha, I understand, I agree changing the default can break other people, do you know for a fact that FlutentBit in compatibility mode works out of the box? I vaguely recall hostname was still a requirement though, no?
Perhaps a better approach is to:
github-actions commentedon Jun 19, 2024
Hello 👋, this issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will engage on it to decide if it is still applicable.
Thank you for your contribution and understanding! 🙏
github-actions commentedon May 14, 2025
Hello 👋, this issue has been inactive for over 90 days and hasn't received any updates since it was marked as stale. We'll be closing this issue for now, but if you believe this issue is still relevant, please feel free to reopen it. Thank you for your contribution and understanding! 🙏