🚀 Feature: Create DNS alerts enricher for TargetDown alerts

[letho1608]

🚀 New Feature

Problem

Create a new action that enriches TargetDown alerts when they're related to coreDns but kubeDns is being used instead. This will help users understand why they're getting irrelevant alerts and how to fix them.

Severity: high
File: playbooks/robusta_playbooks/dns_alerts.py

Solution

Create a new Python file with a function decorated with @action that:

Changes

• playbooks/robusta_playbooks/dns_alerts.py (new)

Testing

• Existing tests pass
• Manual review completed
• No new warnings/errors introduced

---

Closes #553

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

Walkthrough

A new robusta enricher action dns_target_down_enricher was added to handle TargetDown alerts by checking if the alert job is related to kube-dns and enriching the finding with contextual information about potential false positives when coreDns is not available.

Changes

Cohort / File(s)	Summary
DNS Enricher Action playbooks/robusta_playbooks/dns_alerts.py	Added new enricher function that checks if a Prometheus alert job name starts with "kube-dns" and enriches the finding with an INFO-level description explaining the scenario where kube-dns jobs exist but coreDns is expected.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~4 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check	⚠️ Warning	The implementation adds a dns_target_down_enricher action, but the action name differs from the requirement (dns_target_down_enricher vs core_dns_target_down_enricher) and appears incomplete regarding kubeDns detection.	Rename the action to core_dns_target_down_enricher and implement kubeDns cluster detection before enriching alerts, as specified in issue #553.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: creating a DNS alerts enricher for TargetDown alerts, which matches the primary objective of the pull request.
Description check	✅ Passed	The description is related to the changeset, explaining the problem, solution, and changes made to add a new DNS alerts enricher action.
Out of Scope Changes check	✅ Passed	All changes are within scope as they directly relate to adding the DNS alerts enricher action specified in issue #553.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@playbooks/robusta_playbooks/dns_alerts.py`:
- Line 1: Remove the unused import statement "import logging" from
playbooks/robusta_playbooks/dns_alerts.py so the file no longer imports the
logging module it doesn't use; locate the top-level import and delete that line
to eliminate the unused dependency.
- Around line 10-11: The current check uses alert.job.startswith("kube-dns") but
alert.job is Optional and may be None; update the guard to handle None first
(e.g., assign job = alert.job or "" or explicitly if not alert.job: return) and
then call startswith on that safe string; change the condition around the
existing alert.job.startswith usage in dns_alerts.py so it never calls
startswith on None.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: efa22d9d-055f-4c92-b910-6026985f3fee

📥 Commits

Reviewing files that changed from the base of the PR and between 14d6ba5 and 265b967.

📒 Files selected for processing (1)

• playbooks/robusta_playbooks/dns_alerts.py

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Remove unused logging import.

The logging module is imported but never used in this file.

Proposed fix

-import logging

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	import logging
	from robusta.api import *

🧰 Tools

🪛 Flake8 (7.3.0)

[error] 1-1: 'logging' imported but unused

(F401)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@playbooks/robusta_playbooks/dns_alerts.py` at line 1, Remove the unused
import statement "import logging" from playbooks/robusta_playbooks/dns_alerts.py
so the file no longer imports the logging module it doesn't use; locate the
top-level import and delete that line to eliminate the unused dependency.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

alert.job can be None, causing AttributeError.

According to src/robusta/integrations/prometheus/models.py, the job field is defined as Optional[RobustaJob] = None. Calling .startswith() on None will raise an AttributeError.

Proposed fix

-    if not alert.job.startswith("kube-dns"):
+    if not alert.job or not alert.job.startswith("kube-dns"):
         return

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@playbooks/robusta_playbooks/dns_alerts.py` around lines 10 - 11, The current
check uses alert.job.startswith("kube-dns") but alert.job is Optional and may be
None; update the guard to handle None first (e.g., assign job = alert.job or ""
or explicitly if not alert.job: return) and then call startswith on that safe
string; change the condition around the existing alert.job.startswith usage in
dns_alerts.py so it never calls startswith on None.