AWS EKS Fargate日志无法写入CloudWatch：日志组未创建

I’ve run into similar issues with EKS Fargate logging before, so let’s break down what might be going wrong here and walk through actionable fixes. You’ve got the basics set up correctly—your ConfigMap aligns with AWS docs, pods show LoggingEnabled, and you can pull logs via kubectl—so let’s dig into the less obvious culprits.

1. First, Check the Fluent Bit Pods Themselves #

AWS runs managed Fluent Bit pods in the aws-observability namespace to handle Fargate logging. If these pods are misbehaving, logs won’t make it to CloudWatch. Let’s check their status:

kubectl get pods -n aws-observability

If any are crashing, stuck in pending, or restarting constantly, describe the pod to uncover errors:

kubectl describe pod <your-fluent-bit-pod-name> -n aws-observability

Also, peek at the Fluent Bit logs directly—this is where you’ll catch config typos or format mismatches:

kubectl logs <your-fluent-bit-pod-name> -n aws-observability

Common red flags here: region mismatches, parser failures, or permission gaps (even though you could create a log group manually, the Fluent Bit service account might have different permissions).

2. Validate Your aws-logging ConfigMap #

Let’s double-check a few critical parts of your ConfigMap:

• Region Match: Confirm your EKS cluster and CloudWatch are both in us-east-1 (as set in your output.conf). Mismatched regions are a super common silent failure.
• CRI-O Parser Compatibility: Your parser assumes logs follow the standard CRI-O format, but some workloads output logs that don’t match this regex. Try temporarily disabling the parser filter to test if logs flow through without parsing:
  Update your filters.conf section like this:

  filters.conf: |
     #[FILTER]
     #   Name parser
     #   Match *
     #   Key_name log
     #   Parser crio
  

  Apply the updated ConfigMap and wait 5-10 minutes to see if the log group gets created.

3. Confirm Your Target Namespace Is Labeled Correctly #

Fargate logging only applies to namespaces with the aws-observability: enabled label. Check if your dev-fargate namespace has this label:

kubectl get namespace dev-fargate --show-labels

If not, add it with:

kubectl label namespace dev-fargate aws-observability=enabled

Note: Existing pods won’t pick up the label change—you’ll need to restart them for the logging config to take effect.

4. Double-Check IAM Permissions (Even If Manual Creation Works) #

While you can create log groups from the pod, ensure the Fargate execution role attached to your pods has the full set of required CloudWatch Logs permissions. The role should have a policy like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": "*"
        }
    ]
}

Double-check that this policy is attached to the execution role used by your Fargate pods.

5. Verify Log Group Details and Timing #

Sometimes logs end up in unexpected places or take time to show up:

• Make sure you’re checking CloudWatch in the correct region (us-east-1)
• Confirm you’re looking for the exact log group name fluent-bit-cloudwatch (it’s case-sensitive)
• Even with auto_create_group true, log group creation can take a few minutes—wait 10 minutes after applying changes before rechecking.

6. Test with a Simple Workload #

To rule out issues with your existing workload, deploy a simple test pod in dev-fargate and see if its logs appear in CloudWatch:

apiVersion: v1
kind: Pod
metadata:
  name: test-logging
  namespace: dev-fargate
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "while true; do echo 'Hello from test pod'; sleep 5; done"]

Wait a few minutes, then check CloudWatch for the log group and streams.

If none of these steps resolve the issue, check CloudTrail for API calls related to CloudWatch Logs from your Fargate pods—this will show if there are denied requests or other errors that aren’t visible in pod logs.

内容的提问来源于stack exchange，提问作者Dmytro Melnychenko