ferruzzi commented on code in PR #69943:
URL: https://github.com/apache/airflow/pull/69943#discussion_r3616730959


##########
airflow-core/docs/core-concepts/multi-team.rst:
##########
@@ -1060,9 +1060,11 @@ Dags, and global components emit the same metrics 
without a ``team_name`` tag.
 
 The ``team_name`` tag is applied to metrics across the following components:
 
-- **Triggerer**: heartbeat, capacity, and trigger-outcome metrics (for 
example, ``triggerer_heartbeat``,
-  ``triggers.running``, ``triggers.succeeded``).
-- **Executors**: executor slot gauges (for example, ``executor.open_slots``, 
``executor.queued_tasks``).
+- **Triggerer**: heartbeat, capacity, blocked-main-thread, trigger-queue 
delay, and trigger-outcome
+  metrics (for example, ``triggerer_heartbeat``, ``triggers.running``, 
``triggers.succeeded``,
+  ``triggers.blocked_main_thread``, ``triggerer.trigger_queue_delay``).

Review Comment:
   While accurate, and a good catch, this should not be lumped in with this PR. 
 Can you spin this into a new PR?



##########
airflow-core/docs/core-concepts/multi-team.rst:
##########
@@ -1073,12 +1075,15 @@ The ``team_name`` tag is applied to metrics across the 
following components:
   ``dag_processing.processor_timeouts``, 
``dag_processing.callback_only_count``).
 - **Callbacks**: callback execution counters (``callback_success`` / 
``callback_failure``, optionally
   prefixed).
+- **Connection tests**: per-request worker and reaper metrics for team-owned 
connection tests (for
+  example, ``connection_test.success``, ``connection_test.failed``, 
``connection_test.hook_duration``,
+  ``connection_test.reaped``). Instance-wide connection-test queue gauges 
remain untagged.
 
 .. note::
 
-    Only metrics emitted by Airflow core carry the ``team_name`` tag in 3.3; 
provider-specific metrics
-    were not updated for this release. Provider executors are an exception: 
their ``executor.*`` slot
-    gauges are tagged because they inherit them from the core base executor.
+    Provider-specific metrics are also tagged where the provider carries a 
team identity (for example,
+    team-scoped executor and worker metrics). Provider executors additionally 
inherit core
+    ``executor.*`` slot gauges from the base executor.

Review Comment:
   Same as the above.  This is a good catch, but doesn't belong in this PR.  
You can combine this and the   Triggerer update into one, call it something 
like "Multi-team metrics doc cleanup" or something.



##########
airflow-core/docs/core-concepts/multi-team.rst:
##########
@@ -1073,12 +1075,15 @@ The ``team_name`` tag is applied to metrics across the 
following components:
   ``dag_processing.processor_timeouts``, 
``dag_processing.callback_only_count``).
 - **Callbacks**: callback execution counters (``callback_success`` / 
``callback_failure``, optionally
   prefixed).
+- **Connection tests**: per-request worker and reaper metrics for team-owned 
connection tests (for
+  example, ``connection_test.success``, ``connection_test.failed``, 
``connection_test.hook_duration``,
+  ``connection_test.reaped``). Instance-wide connection-test queue gauges 
remain untagged.
 
 .. note::
 
-    Only metrics emitted by Airflow core carry the ``team_name`` tag in 3.3; 
provider-specific metrics
-    were not updated for this release. Provider executors are an exception: 
their ``executor.*`` slot
-    gauges are tagged because they inherit them from the core base executor.
+    Provider-specific metrics are also tagged where the provider carries a 
team identity (for example,
+    team-scoped executor and worker metrics). Provider executors additionally 
inherit core
+    ``executor.*`` slot gauges from the base executor.

Review Comment:
   Also, maybe a slight rephrase here to add a sentence like: "Check individual 
provider changelogs for the minimum version that includes team_name tagging." 
since we're removing the version number.



-- 
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