Уведомления и алертинг в Apache Airflow: теория, архитектура и производственная практика
Введение: роль уведомлений в эксплуатации Apache Airflow
Эксплуатация конвейеров данных редко проходит без отклонений: задержки, сбои внешних зависимостей, истощение квот облачных сервисов и человеческие ошибки - повседневная реальность. В таких условиях уведомления и алертыстановятся не дополнением, а системообразующей частью платформы оркестрации. Для Apache Airflow - де-факто стандарта для пакетной обработки - правильная стратегия оповещений определяет скорость реакции (MTTA), время восстановления (MTTR), а следовательно, и выполнение обязательств по сервисным уровням (SLA/SLO) перед бизнесом.
Цель статьи - дать целостную картину теории событийной модели Airflow, архитектуры нотификаций, производственных паттернов и практик безопасности. Мы разберем каналы уведомлений, конфигурацию, обратные вызовы и слушатели, интеграцию с наблюдаемостью, эскалации и тестирование; сопоставим возможности Airflow с альтернативными оркестраторами; завершим экономической оценкой и рекомендациями.
Теоретическая основа: модель событий, состояния задач и жизненный цикл DAG
Airflow управляет выполнением работ посредством Directed Acyclic Graph (DAG). Каждая вершина - задача (Task), экземпляр выполнения - TaskInstance (TI). Жизненный цикл TI проходит через набор состояний: queued, scheduled, running, success, failed, up_for_retry, skipped, upstream_failed, deferred и др. Триггерами событий служат:
- Смена состояния TI (например, success→failed).
- Достижение временных порогов (тайм-ауты, SLA).
- События планировщика (Scheduler) и диспетчера исполнителей (Executor).
- Системные события на уровне DAGRun (success/failed), датасетов, sensor’ов.
Уведомления - это реакция на эти события. Их задача - доставить контекст инцидента нужной аудитории, в нужный канал, с нужной критичностью и ссылкой на действие (runbook). Важные свойства хорошей системы уведомлений: релевантность (точность сигналов), своевременность (задержка доставки), устойчивость (надёжность канала), трассируемость (аудит).
Архитектура и взаимодействие компонентов уведомлений в Airflow
Архитектура нотификаций распределена по нескольким уровням:
- Конфигурация ядра (airflow.cfg, env-переменные), включая SMTP, шаблоны писем и политику SLA.
- Параметры задач и DAG: email, _callback, SLA.
- Классы уведомителей (BaseNotifier) из провайдеров и кастомные реализации.
- Инфраструктура плагинов и слушателей (Pluggy), перехватывающих глобальные события.
- Интеграция со стеком наблюдаемости (StatsD/Prometheus/Alertmanager, логирование).
- Подсистема секретов и подключений (Airflow Connections, Secrets Backend).
При наступлении события Airflow формирует контекст (Context) - словарь с деталями о DAG, задаче, логах, времени старта/окончания, попытках. Этот контекст передаётся в обратные вызовы и уведомители, а также доступен в шаблонах Jinja при генерации письма.
Каналы уведомлений: классификация и области применения
Канал следует выбирать из задачи скорости реакции, регуляторных ограничений и культуры взаимодействия команд.
- Электронная почта: универсальна, удобна для отчётов и SLA-уведомлений средней срочности. Минусы - задержки и «шум».
- ChatOps (Slack, MS Teams, Telegram): быстрые алерты, ссылочные карточки, кнопки-акции, удобная маршрутизация по каналам.
- Инцидент-менеджмент (PagerDuty, Opsgenie, VictorOps): круглосуточная эскалация, расписания дежурств, подтверждение (ack).
- Webhook/REST: универсальный шлюз в собственные шины событий и SIEM/SOAR.
- SMS/голос: лишь для критических S1-событий из-за стоимости и навязчивости.
- Тикет-системы (Jira/YouTrack/ServiceNow): фиксация инцидентов и хода расследования.
Хорошая практика - комбинировать каналы по уровням важности: информационные - email/дашборды; предупреждения - ChatOps; критика - инцидент-платформы с эскалацией.
Уведомления по электронной почте: конфигурация SMTP и шаблоны Jinja
Airflow отправляет email при наличии корректной SMTP-конфигурации и соответствующих параметров задач/DAG.
Ключевые шаги:
- Настроить SMTP в airflow.cfg или через переменные окружения с префиксом AIRFLOWSMTP (например, AIRFLOWSMTPSMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD, SMTP_MAIL_FROM, SMTP_SSL/TLS).
- Задать на уровне задач параметры email, email_on_failure, email_on_retry, email_on_success (при необходимости).
- Настроить шаблоны Jinja для темы и тела письма через конфигурационные ключи subject_template и html_content_template, указывая путь к шаблонам. Контекст шаблонов включает поля DAG, task_id, run_id, ti.try_number, log_url и др.
Пример фрагмента конфигурации и задачи:
## airflow.cfg (фрагмент)
[smtp]
smtp_host = smtp.example.org
smtp_port = 587
smtp_starttls = True
smtp_user = airflow-notify
smtp_password = ${SMTP_PASSWORD}
smtp_mail_from = airflow@example.org
subject_template = /opt/airflow/include/email_subject.jinja2
html_content_template = /opt/airflow/include/email_body.jinja2
with DAG(
dag_id="billing_etl",
schedule="0 * * * *",
default_args={
"email": ["dataops@example.org"],
"email_on_failure": True,
"retries": 2,
"retry_delay": timedelta(minutes=10),
},
) as dag:
extract = PythonOperator(
task_id="extract",
python_callable=do_extract,
email_on_retry=True,
)
Важно: при включенном SMTP и определённых SLA для задач письма о нарушениях SLA будут отправляться автоматически; это поведение нельзя избирательно отключить, если активирован общий механизм отправки.
Обратные вызовы *_callback на уровнях задачи и DAG
Airflow поддерживает обратные вызовы (callbacks), которые вызываются в ответ на события жизненного цикла.
Ключевые параметры:
- on_success_callback (задача и DAG) - при успешном завершении.
- on_failure_callback (задача и DAG) - при ошибке.
- on_retry_callback (задача) - при повторной попытке.
- on_execute_callback (задача) - непосредственно перед запуском.
- on_skipped_callback (задача, с Airflow 2.9) - при пропуске по исключению AirflowSkipException.
- sla_miss_callback (DAG) - при нарушении SLA.
В параметр можно передать любой вызываемый объект Python или список вызываемых объектов. Порядок вызова важен для побочных эффектов (логирование → отправка → эскалация).
Типовой шаблон обратного вызова:
def notify_failure(context):
ti = context["ti"]
msg = f"DAG {ti.dag_id} task {ti.task_id} failed on try {ti.try_number}"
send_to_slack(msg, context["log_url"])
Обратные вызовы уровня задачи переопределяют значения из default_args, если они заданы непосредственно в конструкторе оператора. Обратные вызовы уровня DAG применяются к состоянию всего DAGRun (а не отдельных задач).
Пользовательские уведомители (BaseNotifier) и провайдерские интеграции
С Airflow 2.x доступна абстракция уведомителей - BaseNotifier, позволяющая стандартизовать интеграции и повторно использовать их в разных DAG.
- Провайдеры поставляют готовые нотификаторы: SlackNotifier, TeamsNotifier, PagerdutyNotifier и др. Они обычно принимают conn_id, шаблоны сообщений, настройки маршрутизации.
- Кастомный уведомитель создают наследованием от BaseNotifier и реализацией метода notify(context). Внутри используют Airflow Connections/Secrets Backend для секретов.
Пример объявление и использование:
from airflow.notifications.base import BaseNotifier
class RunbookSlackNotifier(BaseNotifier):
def __init__(self, conn_id="slack_alerts", severity="warning"):
super().__init__()
self.conn_id = conn_id
self.severity = severity
def notify(self, context):
ti = context["ti"]
text = (
f"[{self.severity.upper()}] {ti.dag_id}.{ti.task_id} "
f"state={ti.state} run_id={context['run_id']} log={context['log_url']}"
)
self._send_slack(self.conn_id, text)
## Привязка к обратному вызову
on_failure = RunbookSlackNotifier(severity="critical")
Такой подход облегчает аудит и снижение «зоопарка» кастомного кода: единые стандарты форматирования, ссылки на логи, включение runbook’ов, единая политика маршрутизации.
Соглашения об уровне обслуживания (SLA) и sla_miss_callback
SLA (Service Level Agreement) в Airflow - целевое время завершения задачи, выраженное как timedelta. Важно понимать специфику механизма:
- SLA относится к дате выполнения (execution_date, ныне data_interval) планового запуска, а не к моменту фактического старта.
- SLA оценивается только для запланированных (scheduled) запусков, не для ручных.
- SLA задаётся на уровне задачи; в DAG с несколькими SLA все они оцениваются индивидуально.
- При нарушении SLA Airflow может отправлять email и вызывает sla_miss_callback на уровне DAG.
- Проверка SLA управляется флагом check_slas (airflow.cfg); её можно полностью отключить, если SLA пока не введены в эксплуатацию.
Пример:
def sla_breach_handler(dag, task_list, blocking_task_list, slas, **kwargs):
## dag: объект DAG; task_list — список задач с SLA
## slas: сведения о нарушенных SLA (SlaMiss)
for miss in slas:
notify_sre(f"SLA missed: {miss.task_id} in DAG {miss.dag_id}")
with DAG(
"dwh_loading",
schedule="@hourly",
sla_miss_callback=sla_breach_handler,
) as dag:
transform = PythonOperator(
task_id="transform",
python_callable=do_transform,
sla=timedelta(minutes=40),
)
SLA - это информационный контроль: задачи, превысившие SLA, продолжают выполняться. Если нужен принудительный разрыв выполнения - используйте тайм-ауты задач.
Тайм-ауты задач и их соотнесение с SLA
Тайм-ауты - механизм завершения задачи по времени:
- execution_timeout - общий лимит на выполнение.
- retry_delay и retries - стратегия повторных запусков.
- timeout на уровне конкретных операторов (например, сенсоров).
Отличия от SLA:
- SLA не прерывает выполнение; тайм-аут - прерывает.
- SLA измеряется относительно расписания; тайм-аут - относительно старта задачи.
- SLA генерирует sla_miss_callback; тайм-аут ведёт к ошибке задачи (failed) и запуску on_failure_callback.
Композиция обоих механизмов позволяет удерживать баланс между «выполнить любой ценой» и «быстро освободить ресурсы, если задача зависла» - ключевая инженерная дилемма при проектировании пакетных конвейеров.
Слушатели (Listeners) и плагинная модель Pluggy
Для поперечного (cross-cutting) слежения за событиями во всей установке Airflow используются слушателина основе Pluggy. Они позволяют перехватывать события без модификации DAG’ов:
- Реализация: модуль с функциями, помеченными декоратором hookimpl из airflow.listeners.hookimpl.
- Сигнатуры функций согласованы с hookspec фреймворка: например, on_task_instance_running, on_task_instance_success, on_dag_run_failed и др.
- Слушатели подключаются как плагин, действуют глобально для всех DAG и задач. Это удобно для централизации алертов и аудита.
Пример (сокращённо):
from airflow.listeners import hookimpl
@hookimpl
def on_task_instance_failed(previous_state, task_instance, session):
ctx = task_instance.get_template_context()
post_to_alertmanager(
dag_id=task_instance.dag_id,
task_id=task_instance.task_id,
try_number=task_instance.try_number,
log_url=ctx["log_url"],
)
Слушатели не должны содержать тяжёлой синхронной логики: выносите I/O в неблокирующие очереди или используйте вебхуки во внешние системы, чтобы не тормозить внутренние процессы Airflow.
Параметры конфигурации и практики задания default_args
Практики конфигурирования:
- Инициализируйте типовые коллбэки и нотификаторы в default_args DAG, чтобы упростить масштабирование. При необходимости переопределяйте их на уровне задачи.
- Храните адреса получателей и маршруты каналов во внешних переменных/подключениях (Airflow Variables/Connections), а не в коде DAG.
- Задавайте единые форматированные subject/body шаблоны для email, чтобы стандартизовать внешний вид и облегчить парсинг алертов SIEM.
- Явно определяйте политики retries и retry_delay, чтобы ограничить «шторма» алертов при временных сбоях.
Пример default_args:
DEFAULT_ARGS = {
"depends_on_past": False,
"email": ["dataops@corp.local"],
"email_on_failure": True,
"on_failure_callback": RunbookSlackNotifier(severity="critical"),
"execution_timeout": timedelta(hours=2),
"retries": 1,
"retry_delay": timedelta(minutes=15),
}
Интеграция со стеком наблюдаемости и инцидент-менеджментом
Производственный контур уведомлений тесно связан с наблюдаемостью:
- Метрики: экспорт через StatsD/Prometheus (экспортер Airflow) - длительности задач, количество сбоев, sla_miss, размер очередей, лаг планировщика.
- Логи: централизуйте в Elasticsearch/OpenSearch или Loki; в алертах всегда давайте ссылку на соответствующий лог.
- Alertmanager/или эквиваленты: настраивайте правила дедупликации и подавления (silencing), чтобы не создавать «шторм» оповещений.
- Инцидент-платформы: привязывайте эскалационные политики к severities из нотификаторов и размечайте инциденты тегами DAG/owner.
Хорошая практика - включать в уведомление ссылку на дашборд производительности соответствующего DAG и готовый runbook со «шагами первых действий».
Управление секретами и безопасностью каналов уведомлений
Безопасность уведомлений - это защита подключений и содержимого:
- Используйте Airflow Secrets Backend (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) для SMTP, Slack, PagerDuty токенов. Не храните секреты в переменных окружения без шифрования.
- Включите Fernet-шифрование для Connection метаданных.
- Применяйте TLS/STARTTLS для SMTP; ограничивайте доступ по IP-спискам и используйте сервисные аккаунты с минимальными правами.
- Для вебхуков - подпись и верификация запросов (HMAC, секреты провайдера), ограничение исходящих egress.
- Не пересылайте в уведомлениях персональные данные и чувствительные бизнес-метрики без классификации и редактирования (DLP).
- Логи ошибок нотификаторов не должны утекать ключи (редактируйте/маскируйте).
Производственные паттерны проектирования алертов и эскалаций
- Слои важности: info → warning → critical, с разными каналами и расписаниями.
- Корреляция и дедупликация: агрегируйте пачку одинаковых ошибок задачи в один инцидент с инкрементом счётчика.
- Окна подавления: подавляйте «флаппинг» (частые переходы состояния) через дебаунс-таймеры.
- Маршрутизация по владельцам: поля owner/email из DAG плюс карта критичности.
- Обогащение контекстом: ссылки на логи, конфигурацию и runbook; последние коммиты DAG; upstream зависимостей.
- Автоматические действия: для известных отказов** - немедленное открытие тикета, пересоздание пула соединений, очистка кэшей.
Кейсы применения: пакетные ETL, DWH, ML-конвейеры, аналитика
- Пакетные ETL: SLA на оконные задания, критические - загрузка реестров и отчётность. Тайм-ауты сенсоров внешних файлов и API. Эскалация в SRE при истощении квот.
- DWH: строгие SLA на слои дзеркалирования/витрин; алерты при сдвиге схем (schema drift), росте времени мёрджей. Интеграция с дашбордами нагрузок СУБД.
- ML-конвейеры: отдельные алерты на дрейф данных/метрик обученности; уведомления о неуспехе деплоя модели; ChatOps-кнопки для rollback.
- Аналитика: инфо-уведомления о завершении витрин, публикация статуса датасетов; предупреждения о пропусках партиций.
Применимость в экономических секторах и регуляторные требования
- Финансы и телеком: требования к RTO/RPO и отчётности по инцидентам, логи и уведомления должны храниться и аудироваться. Шифрование трафика и хранение артефактов.
- Ритейл и логистика: пики сезонности** - динамическое усиление каналов оповещений и расписаний дежурств.
- Госсектор и здравоохранение: контроль ПДн и медицинской тайны; строгая сегментация сетей, закрытые SMTP/вебхуки, внутренние ChatOps.
- Промышленность: интеграция с OT/SIEM, повышенные требования к устойчивости каналов (дублирование через SMS/голос).
Метрики эффективности: задержка доставки, MTTA/MTTR, точность сигналов
Оцените систему алертов по метрикам:
- Задержка доставки (end-to-end от события до экрана оператора).
- MTTA (Mean Time To Acknowledge) - среднее время подтверждения инцидента.
- MTTR (Mean Time To Restore) - среднее время восстановления.
- Precision/Recall сигналов - точность и полнота алертов (ложноположительные/ложноотрицательные).
- Коэффициент эскалаций - доля инцидентов, потребовавших перехода на следующий уровень.
- Аудит покрытия - процент критических DAG с определёнными SLA и коллбэками.
Риски, уязвимости и ограничения реализации уведомлений в Airflow
- Зависимость от внешних каналов (SMTP/ChatOps API): сетевые сбои и лимиты. Минимизируйте синхронные вызовы в критическом пути.
- «Шумовые» алерты: отсутствие дедупликации и контекстной маршрутизации повышает MTTA и приводит к выгоранию дежурных.
- Рекурсивные ошибки коллбэков: неудачные уведомления порождают дополнительные ошибки. Оборачивайте обработчики в try/except и логируйте аккуратно.
- Непреднамеренная утечка данных в уведомлениях.
- Ошибочное смешение SLA и тайм-аутов: SLA не прерывает, что иногда интерпретируют как «не сработало».
- Совместимость провайдеров: обновления пакетов могут менять интерфейсы нотификаторов.
Антипаттерны и рекомендации по надёжной реализации колбэков
Антипаттерны:
- Синхронные HTTP-запросы с длительным тайм-аутом прямо в on_failure_callback.
- Хранение токенов/паролей в коде DAG.
- Отправка больших payload’ов в письмах или ChatOps.
- Многоступенчатые условия в шаблонах Jinja без тестов.
Рекомендации:
- Лёгкие коллбэки: собирайте краткий контекст и публикуйте в очередь/вебхук с коротким тайм-аутом (<=2-3 сек).
- Единые нотификаторы на базе BaseNotifier; версионируйте их как библиотеку.
- Централизованные слушатели для сквозных политик и аудита.
- Строгие ретраи/экспоненциальная задержка для нестабильных каналов.
- Идемпотентность: дублирующие вызовы не должны создавать лавину тикетов.
- Обязательный рунбук в каждом критическом уведомлении.
Тестирование и верификация уведомлений (юнит, интеграция, симуляции)
Стратегия проверки:
- Юнит-тесты нотификаторов: изоляция от сети (pytest + responses/httpx_mock), проверка форматирования сообщения и маршрутизации.
- Интеграционные тесты DAG: airflow dags test с подменой Connections и локальным SMTP-сервером (aiosmtpd) в CI.
- Контрактные тесты шаблонов Jinja: snapshot-тестирование тем и тел сообщений, проверка переменных контекста.
- Симуляции инцидентов: «игровые» DAG, которые намеренно падают/превышают SLA в нефункциональные окна; проверка цепочек эскалации.
- Нагрузочные: серия искусственных сбоев для оценки дедупликации и пропускной способности каналов.
Наблюдаемость за контуром уведомлений: метрики и дашборды
Минимальный набор витрин:
- Количество уведомлений по типу события и каналу.
- Успешность доставки (HTTP 2xx, SMTP accepted) и ошибки по кодам.
- Время формирования уведомления и end-to-end задержка.
- Доля задублированных/подавленных алертов.
- Распределение MTTA/MTTR по DAG и владельцам.
Эти метрики собирайте в Prometheus/Grafana; для SMTP полезно снимать метрики из MTA и сверять с количеством сгенерированных писем.
Управление конфигурациями и версиями: инфраструктура как код
- Описывайте уведомители и конвейеры доставки как код: Helm/Ansible/Terraform + переменные окружения.
- Версионируйте шаблоны писем и сообщений вместе с DAG; используйте семантическое версионирование библиотек нотификаторов.
- Среды (dev/stage/prod): изолированные Connections и секреты, флаги «dry-run» для тестирования алертов.
- Проводите Change Advisory Board (CAB) для изменений эскалаций на критичных потоках.
Совместимость между версиями Airflow (1.10→2.x) и новшества 2.9+
Переходные моменты:
- Airflow 1.10: callbacks и email-параметры существуют, но отсутствуют современные слушатели Pluggy и унифицированные нотификаторы.
- Airflow 2.x: добавлены BaseNotifier, обновлена модель контекста, расширена конфигурируемость, упрощена интеграция провайдеров.
- Начиная с 2.7-2.8: введён Listener API (Pluggy), расширены события для задач и DAGRun.
- Airflow 2.9+: добавлен on_skipped_callback на уровне задач для явных AirflowSkipException; уточнены политики коллбэков и улучшены шаблоны уведомлений.
При миграции проверяйте:
- Сигнатуры пользовательских коллбэков.
- Поведение SLA и автоматической рассылки email.
- Совместимость провайдеров нотификаторов (pin версий в requirements).
Конкурентный анализ: Prefect, Dagster, Luigi, Argo и отличия Airflow
- Prefect: сильные встроенные уведомления и оркестрация через внешнюю облачную/самостоятельную Prefect UI; гибкая маршрутизация и блоки. Минус - иной рантайм-модель, миграционные усилия.
- Dagster: концепция опса/графа, богатая телеметрия и «software-defined assets» с нативными алертами. Сильная типизация и дев-опыт, выше порог входа.
- Luigi: базовый функционал, слаба интеграция с современными каналами уведомлений.
- Argo Workflows: Kubernetes-native, удобен для событийных пайплайнов и CI/CD; уведомления - через K8s экосистему (Argo Events, Alertmanager).
Отличие Airflow - широчайшая экосистема провайдеров, зрелый планировщик пакетных задач, гибкость кастомизаций (callbacks, listeners, notifiers) и предсказуемость для DWH/ETL-ландшафтов.
Экономическая оценка и TCO систем уведомлений
На совокупную стоимость владения (TCO) влияют:
- Разработка и поддержка: создание общих нотификаторов/шаблонов, тесты, документация и обучение.
- Инфраструктура: SMTP, ChatOps, инцидент-платформы (лицензии, трафик).
- Наблюдаемость: хранение логов/метрик, поддержка дашбордов.
- Операционка: дежурства, эскалации, ретро по инцидентам и их автоматизация.
Снижение TCO достигается за счёт стандартизации (BaseNotifier+Listeners), Infrastructure-as-Code, повторного использования шаблонов и автоматизации рутины (тикеты, runbook ссылки, автокоррекции).
Заключение и направления дальнейшей практики
Система уведомлений в Airflow - это не набор «галочек» в параметрах задач, а производственная дисциплина, сочетающая модель событий, технические интеграции, правила эскалации и эксплуатационную аналитику. Правильное проектирование и тестирование оповещений уменьшает «шум», ускоряет реакцию, снижает MTTR и повышает доверие бизнеса к платформе данных.
Дальнейшие шаги: внедрить стандартизованные уведомители, слушатели для сквозной политики, метрики эффективности контуров, а также провести ревизию SLA и тайм-аутов для критичных DAG. В перспективе - обогащение алертов автодиагностикой, интеграция с генеративными подсказками по устранению инцидентов и полная трассировка от первопричины до восстановления.
Таблицы соответствия и справочные материалы
Таблица
- События и коллбэки
| Событие | Уровень | Коллбэк/механизм | Прерывает задачу | Типичное применение |
|---|---|---|---|---|
| Успешное завершение задачи | Task | on_success_callback | Нет | Информирование, публикация артефактов |
| Сбой задачи | Task | on_failure_callback | Да (состояние) | Алертинг, эскалация |
| Повторная попытка | Task | on_retry_callback | Нет | Предупреждение о деградации |
| Старт выполнения | Task | on_execute_callback | Нет | Аудит, метки трассировки |
| Пропуск по Skip | Task | on_skipped_callback 2.9+ | Нет | Аналитика маршрутизации |
| Нарушение SLA | DAG | sla_miss_callback | Нет | Раннее обнаружение задержек |
| Изменение состояния DAGRun | DAG | коллбэки DAG/Listeners | Зависит | Сводные уведомления |
Таблица
2. Сопоставление SLA и тайм-аутов
| Критерий | SLA | Тайм-аут задачи |
|---|---|---|
| База отсчёта | Плановый запуск (data interval) | Фактический старт |
| Действие | Уведомление, не прерывает | Прерывает, приводит к failed |
| Конфигурация | task.sla, sla_miss_callback (DAG) | execution_timeout, retries, delay |
| Область применения | Контроль ожиданий | Защита от зависаний |
Таблица
3. Классы каналов и применение
| Канал | Скорость | Надёжность | Область |
|---|---|---|---|
| Средняя | Высокая | Отчёты, SLA, инфо | |
| ChatOps | Высокая | Средняя | Оперативные алерты |
| PagerDuty/инц. | Очень высокая | Высокая | Критика, дежурства |
| Webhook/REST | Зависит | Зависит | Интеграция/автоматизация |
| SMS/Voice | Высокая | Высокая | S1 аварии |
Вопрос-Ответ:
-
Вопрос: В чём ключевое различие между SLA и тайм-аутом задачи?
Ответ: SLA - информационный контроль относительно планового запуска и не прерывает задачу; тайм-аут - техническое ограничение времени выполнения, прерывает задачу и ведёт к failed. -
Вопрос: Когда использовать слушатели (Listeners), а когда коллбэки?
Ответ: Слушатели - для глобальной политики и аудита во всех DAG; коллбэки - для локальной логики конкретных задач/DAG и детального контекста. -
Вопрос: Как минимизировать «шум» уведомлений?
Ответ: Вводите уровни важности, дедупликацию и подавление флаппинга, маршрутизацию по владельцам, ретраи с экспоненциальной задержкой и стандартизованные шаблоны. -
Вопрос: Можно ли отключить письма о нарушениях SLA?
Ответ: Избирательно - нет. При настроенном SMTP и включённой проверке SLA письма отправляются. Можно отключить check_slas целиком или не указывать SLA. -
Вопрос: Чем полезен BaseNotifier по сравнению с простыми функциями-коллбэками?
Ответ: Он стандартизует формат, маршрутизацию и секреты, облегчает повторное использование, тестирование и аудит; его можно передавать в *_callback и переиспользовать. -
Вопрос: Какие риски чаще всего встречаются при реализации алертов?
Ответ: Синхронные тяжёлые вызовы в коллбэках, хранение секретов в коде, дублирование сообщений, утечки чувствительных данных и нестабильные внешние каналы. -
Вопрос: Как измерять эффективность системы уведомлений?
Ответ: Отслеживать задержку доставки, MTTA/MTTR, precision/recall сигналов, долю эскалаций и покрытие критичных DAG политиками оповещения. -
Вопрос: Что нового в Airflow 2.9 для уведомлений?
Ответ: Появился on_skipped_callback на уровне задач для явных пропусков (AirflowSkipException), уточнены политики обратных вызовов и улучшена поддержка шаблонов уведомлений.
