Nik-Tenzo opened a new pull request, #76305:
URL: https://github.com/apache/airflow/pull/76305

   CloudWatch remote logging always checks that the log group exists before 
writing: watchtower's
   `CloudWatchLogHandler` runs a paginated `DescribeLogGroups`, then 
`CreateLogGroup` if the group is missing, each time a
   handler is built. This adds an `[aws] 
cloudwatch_task_handler_create_log_group` option (default `True`, so nothing
   changes by default), passed through to watchtower, so a deployment that 
manages the log group itself can skip both
   calls:
   
   ```ini
   [aws]
   cloudwatch_task_handler_create_log_group = False
   ```
   
   As with `[aws] s3_task_handler_acl_policy` (#70394), the same value can also 
be set through
   `[logging] remote_task_handler_kwargs`, e.g. `{"create_log_group": false}`, 
since it's a field of
   `CloudWatchRemoteLogIO`.
   
   Why: we create the task log group with infrastructure as code, so the check 
is redundant, and on Airflow 2 it got us
   throttled. Each task try ran in a fresh process with a new handler, so every 
try made a `DescribeLogGroups` call. That
   went well over the account's `DescribeLogGroups` quota, and because the 
quota is account-wide, other callers of the
   API (our Terraform plans) slowed down too, until AWS raised it. Since then 
we've carried subclasses of the handler and
   IO that pass `create_log_group=False`, re-copied whenever the handler 
lifecycle changed. At today's ~50,000 task tries
   an hour, the per-try check would be about 14 calls a second.
   
   On Airflow 3 the exposure is much smaller: the IO keeps one handler for the 
life of the process, so the check runs once
   per process that writes task logs, not once per task. It still runs per task 
try on Airflow 2.11, which this provider
   supports, and in either case the option lets a deployment drop the call and 
the `logs:DescribeLogGroups` /
   `logs:CreateLogGroup` permissions it needs.
   
   #73004 also edits `_build_handler` (per-stream handlers that skip the check 
after the first one). The two changes are
   independent; if #73004 merges first I'll rebase this onto it, and the option 
then applies to its first handler.
   
   related: #35164, #70394, #73004
   
   ---
   
   ##### Was generative AI tooling used to co-author this PR?
   
   - [X] Yes — Claude Code (Claude Opus 5.5)
   
   Generated-by: Claude Code (Claude Opus 5.5) following [the 
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to