vincbeck commented on code in PR #73222:
URL: https://github.com/apache/airflow/pull/73222#discussion_r4038529321
##########
airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst:
##########
@@ -100,11 +91,28 @@ including per-instance details when multiple schedulers,
triggerers, or Dag proc
* ``status`` (legacy aggregate): ``"healthy"`` if **any** running instance
is alive, otherwise ``"unhealthy"``
(including when no running jobs exist for that component).
- * ``detailed_status``: reflects the full set of running instances:
-
- * ``"healthy"`` — every running instance is alive
- * ``"degraded"`` — some instances are alive and some are not
- * ``"down"`` — no running instance is alive (including when no jobs exist)
+ * ``detailed_status``: whether every part of that component's work is being
covered by a live instance.
+ What counts as "every part" differs per component, because only some of
them divide their work up:
+
+ * **Dag processor** — the parts are the Dag bundles in ``[dag_processor]
dag_bundle_config_list``.
+ A processor started without ``--bundle-name`` covers every configured
bundle;
+ one started with it covers only the bundles it was given.
+ ``"healthy"`` when every configured bundle has a live processor,
``"degraded"`` when only some do,
+ ``"down"`` when none do.
+ * **Triggerer** — with ``[core] multi_team`` enabled, the parts are the
teams those bundles are scoped to
+ (plus the unscoped bundles), because a triggerer only picks up triggers
for its own team.
+ ``"healthy"`` when every team scope has a live triggerer, ``"degraded"``
when only some do,
+ ``"down"`` when none do. With multi-team disabled, no team filtering
applies, so any live triggerer
+ covers everything: ``"healthy"`` if one is alive, ``"down"`` if none is.
+ * **Scheduler** — schedulers are symmetric and share no partitioned work,
so there is nothing partial
+ to report: ``"healthy"`` if at least one is alive, ``"down"`` if none
is. ``"degraded"`` is never
+ returned for the scheduler. Use ``instances`` to see how many replicas
are up, and your orchestrator
+ or the ``scheduler_heartbeat`` metric to alert on reduced scheduling
throughput.
Review Comment:
Exactly. We do not have the information "how many schedule do I expect", so
we can only rely on the hearbeat returned by the schedulers. But knowing that
one scheduler no longer respond does not tell us whether this is normal this
scheduler is dead.
--
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]
