Airflow metrics with Prometheus - Time & Space Complexity

Time Complexity: Airflow metrics with Prometheus

O(n)

Understanding Time Complexity

When Airflow sends metrics to Prometheus, it collects data from many tasks and DAGs. We want to understand how the time to gather these metrics grows as the number of tasks or DAGs increases.

How does the work needed to collect metrics change when we add more tasks?

Scenario Under Consideration

Analyze the time complexity of this Airflow metrics collection snippet.

from prometheus_client import Gauge

def collect_task_metrics(dags):
    task_gauge = Gauge('airflow_task_duration', 'Duration of Airflow tasks', ['dag_id', 'task_id'])
    for dag in dags:
        for task in dag.tasks:
            duration = task.get_duration()
            task_gauge.labels(dag_id=dag.dag_id, task_id=task.task_id).set(duration)

This code loops through all DAGs and their tasks to collect duration metrics for Prometheus.

Identify Repeating Operations

Look at the loops that repeat work:

• Primary operation: Looping through each DAG and then each task inside it.
• How many times: For each DAG, it loops through all its tasks, so total loops equal the sum of all tasks in all DAGs.

How Execution Grows With Input

As the number of DAGs and tasks grows, the work grows too:

Input Size (total tasks)	Approx. Operations
10	About 10 metric sets
100	About 100 metric sets
1000	About 1000 metric sets

Pattern observation: The work grows directly with the number of tasks. Double the tasks, double the work.

Final Time Complexity

Time Complexity: O(n)

This means the time to collect metrics grows in a straight line with the number of tasks.

Common Mistake

[X] Wrong: "Collecting metrics is always fast and does not depend on the number of tasks."

[OK] Correct: Each task adds work because the code loops through all tasks. More tasks mean more time needed.

Interview Connect

Understanding how metric collection scales helps you design efficient monitoring in real projects. It shows you can think about how systems behave as they grow, a key skill in DevOps.

Self-Check

"What if we cached task durations instead of collecting them every time? How would the time complexity change?"

Practice

1. What is the main purpose of integrating Prometheus with Airflow metrics?

easy

A. To schedule Airflow DAGs automatically

B. To store Airflow logs permanently

C. To monitor Airflow task and system health in real-time

D. To send emails from Airflow tasks

Solution

1. Step 1: Understand Airflow metrics role

   Airflow metrics provide data about task execution and system performance.

2. Step 2: Identify Prometheus integration purpose

   Prometheus collects and visualizes these metrics for monitoring and alerting.

3. Final Answer:

   To monitor Airflow task and system health in real-time -> Option C

4. Quick Check:

   Monitoring = B [OK]

Hint: Prometheus is for monitoring, not scheduling or logging [OK]

Common Mistakes:

• Confusing monitoring with scheduling
• Thinking Prometheus stores logs
• Assuming Prometheus sends emails

2. Which configuration option must be enabled in Airflow to expose metrics for Prometheus scraping?

easy

A. metrics_enabled = False

B. statsd_on = True

C. prometheus_exporter = False

D. logging_level = DEBUG

Solution

1. Step 1: Identify Airflow metric exposure setting

   Airflow uses StatsD to collect metrics, so enabling StatsD is required.

2. Step 2: Match correct config option

   The correct option to enable StatsD is statsd_on = True.

3. Final Answer:

   statsd_on = True -> Option B

4. Quick Check:

   Enable StatsD = A [OK]

Hint: Enable StatsD to expose metrics for Prometheus [OK]

Common Mistakes:

• Disabling metrics with false flags
• Confusing logging level with metrics
• Assuming Prometheus exporter is off by default

3. Given this Airflow config snippet:

[metrics]
statsd_on = True
statsd_host = "localhost"
statsd_port = 8125

What will Prometheus scrape from Airflow?

medium

A. Airflow task execution metrics via StatsD exporter

B. Airflow DAG definitions

C. Airflow database contents

D. Airflow log files

Solution

1. Step 1: Analyze config snippet

   The snippet enables StatsD metrics collection on localhost port 8125.

2. Step 2: Understand Prometheus scraping

   Prometheus scrapes metrics exposed by StatsD exporter, which includes task execution data.

3. Final Answer:

   Airflow task execution metrics via StatsD exporter -> Option A

4. Quick Check:

   StatsD metrics = D [OK]

Hint: StatsD config means Prometheus scrapes metrics, not logs or DB [OK]

Common Mistakes:

• Thinking Prometheus scrapes DAG code
• Assuming Prometheus reads database directly
• Confusing logs with metrics

4. You enabled StatsD in Airflow but Prometheus shows no metrics. What is a likely cause?

medium

A. Prometheus scrape config missing or incorrect

B. Airflow DAGs are paused

C. Airflow scheduler is disabled

D. Airflow logs are too large

Solution

1. Step 1: Check Prometheus scraping setup

   If Prometheus shows no metrics, it may not be scraping the StatsD exporter endpoint correctly.

2. Step 2: Rule out unrelated causes

   Paused DAGs or scheduler off do not stop metrics exposure; large logs do not affect metrics scraping.

3. Final Answer:

   Prometheus scrape config missing or incorrect -> Option A

4. Quick Check:

   Scrape config issue = C [OK]

Hint: Check Prometheus scrape config if no metrics appear [OK]

Common Mistakes:

• Blaming paused DAGs for missing metrics
• Assuming scheduler off stops metrics
• Thinking logs size affects metrics

5. You want to create an alert in Prometheus for Airflow tasks that fail more than 5 times in 10 minutes. Which Prometheus query is correct?

hard

A. count(airflow_task_failures_total) == 5

B. sum(airflow_task_success_total) > 5

C. rate(airflow_task_failures_total[5m]) < 5

D. increase(airflow_task_failures_total[10m]) > 5

Solution

1. Step 1: Understand alert condition

   The alert triggers if failures increase by more than 5 in 10 minutes.

2. Step 2: Match Prometheus query

   increase(metric[10m]) > 5 checks if failures increased over 5 in last 10 minutes.

3. Step 3: Eliminate wrong options

   sum(airflow_task_success_total) > 5 checks successes, not failures; C uses wrong time and comparison; D counts current samples, not increase.

4. Final Answer:

   increase(airflow_task_failures_total[10m]) > 5 -> Option D

5. Quick Check:

   Use increase() over 10m > 5 for failure alert [OK]

Hint: Use increase() over time window to detect failure spikes [OK]

Common Mistakes:

• Using success metric instead of failure
• Using rate() incorrectly for count threshold
• Counting samples instead of increase