Update the monitoring architecture description

[adminwcs]

Summary by CodeRabbit

Documentation

• Restructured architecture documentation with renewed focus on alert rule management and real-time alert processing workflows.
• Updated documentation to include enhanced details on alert routing, front-end interactions, and system component interactions.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The documentation file describing the monitoring system architecture was restructured to shift its primary focus from an overall monitoring breakdown to alert rule CRUD operations and end-to-end alert processing workflows, introducing new architectural components and removing previous collection, storage, and query flow descriptions.

Changes

Cohort / File(s)	Summary
Monitoring architecture documentation docs/en/observability/monitor/architecture/architecture.mdx	Restructured content replacing "Overall Architecture Explanation" with alert rule CRUD and alert processing flows; removed monitoring collection, storage, query, and dashboard sections; introduced components (ALB, Courier API, Prometheus/VM, Warlock, Nevermore)

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant UI as Front-end (Courier API)
    participant ALB as ALB<br/>(Router)
    participant API as Alert Rule API
    participant Prometheus as Prometheus/VM<br/>(Storage)
    participant Warlock as Warlock<br/>(Executor)
    participant Nevermore as Nevermore<br/>(Notifier)
    
    rect rgb(200, 220, 255)
    Note over User,API: Alert Rule CRUD
    User->>UI: Create/Update/Delete Alert Rule
    UI->>ALB: HTTP Request
    ALB->>API: Route to API Service
    API->>Prometheus: Store Rule Configuration
    end
    
    rect rgb(220, 200, 255)
    Note over Prometheus,Nevermore: Real-time Alert Processing
    Warlock->>Prometheus: Query Metrics (based on rules)
    Warlock->>Warlock: Evaluate Conditions
    Warlock->>Nevermore: Trigger Alert
    Nevermore->>User: Send Notification
    end
    
    rect rgb(200, 255, 220)
    Note over UI,Prometheus: Display Real-time Alerts
    UI->>ALB: Poll/WebSocket for Alert Status
    ALB->>API: Fetch Alert State
    API->>Prometheus: Get Current Alerts
    API-->>UI: Return Alert Data
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Areas requiring extra attention:
  • Verify architectural accuracy of the new alert processing flow and component interactions (ALB, Courier API, Prometheus/VM, Warlock, Nevermore)
  • Ensure the restructured "Alert Rule CRUD" section accurately reflects current implementation
  • Confirm that removed sections (monitoring collection, storage, query, dashboards) are not needed or have been relocated elsewhere
  • Check for internal link consistency and references to other documentation pages

Suggested reviewers

• chinameok

Poem

🐰 A hoppy shuffle through the docs so fine,
Alert rules dance in a CRUD design,
From ALB to Prometheus they flow,
Real-time alerts—watch them glow! ✨
Architecture springs forth anew,
Warlock and Nevermore see us through! 🎯

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly identifies the main change: updating the monitoring architecture documentation. It accurately reflects the primary objective of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/AIT-63059

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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

🧹 Nitpick comments (5)

docs/en/observability/monitor/architecture/architecture.mdx (5)

10-15: Clarify terminology and introduce unfamiliar components.

The "erebus" component is referenced without explanation of its role or nature. Additionally, terminology like "prometheus/vm operator" uses inconsistent formatting. Consider introducing key components (erebus, Nevermore, Warlock) with brief context before their first mention, or consolidate nomenclature.

---

17-21: Improve clarity of configuration loading and break up long sentences.

Line 19 uses vague language ("monitoring collection and alert rule configurations"). Be more specific about what configurations are synchronized (e.g., scrape configs, rule definitions). Line 21 is a long compound sentence that would benefit from being split into multiple sentences for readability.

---

23-26: Clarify ambiguous phrasing and document technical details.

Line 25 uses unclear phrasing: "retrieves the monitoring address based on the feature monitoring"—this should be more specific about how the monitoring address is determined (e.g., based on cluster metadata, feature flags, configuration). Also clarify the purpose and scope of the request address /platform/monitoring.alauda.io/v1beta1. The mention of port 11780 should include context about why this specific port is used or be documented in a glossary.

---

28-34: Standardize terminology and clarify operator roles.

This section uses inconsistent naming conventions: "Prometheus-Operator" vs. "prometheus/vm operator" vs. "VictoriaMetrics-Operator". Standardize these terms throughout the documentation. Also clarify what "alert interval configuration" means in line 31 (evaluation interval, notification interval, repeat interval?). Line 32 vaguely refers to "content of the alert policies"—specify which fields/properties are synchronized. Consider breaking this dense section into substeps for clarity.

---

36-44: Remove redundant phrasing and clarify "primarily" qualifications.

Line 38 contains redundant phrasing: "metrics from courier-api are collected by the Global Prometheus (collected every 15 seconds)"—the word "collected" is repeated. Lines 40 and 42 both use "primarily obtained," which suggests alternate paths that are never explained. Either remove the qualifier or document the alternate mechanisms. The 15-second collection interval in line 38 should be validated and possibly documented in an operational section if it's a configurable or important SLA.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between db09773 and dfdda11.

⛔ Files ignored due to path filters (1)

• docs/en/observability/monitor/assets/visio_for_monitor.png is excluded by !**/*.png

📒 Files selected for processing (1)

• docs/en/observability/monitor/architecture/architecture.mdx (1 hunks)

[cloudflare-workers-and-pages]

Deploying alauda-container-platform with    Cloudflare Pages

Latest commit:	dfdda11
Status:	✅  Deploy successful!
Preview URL:	https://8d8e1a73.alauda-container-platform.pages.dev
Branch Preview URL:	https://feat-ait-63059.alauda-container-platform.pages.dev

View logs