Alarm

alarm

Alarm and resource-health workflow for triggered alert retrieval, rule-aware alert analysis, component-model-driven resource health evidence, and status operations.

Purpose

Provide alarm-management capabilities:

• List triggered alerts with machine-readable metadata
• Resolve one exact resource and distinguish current firing/muted alerts from currently resolved alerts triggered within the configured lookback for comprehensive resource analysis
• Analyze one alert with normalized facts, datasource-enriched resource context, assessment, and remediation guidance
• Analyze one resource independently of alerts by handing component-specific monitoring evidence to the LLM
• Perform validated status operations (mute, resolve, reopen)

Handlers and helpers

scripts/adapter.py contains the four Tool handlers: list_alerts, analyze_alert, analyze_resource_health, and operate_alert. It converts AtlasClaw Context and Tool parameters, then calls SmartCMP Provider.

scripts/_alarm_object_actions.py remains separate because the embedded assistant Context resolver calls it to build alert page actions. It is not a one-command forwarding script.

Workflow

See references/WORKFLOW.md for the supported workflow.

Resource Enrichment

During alert analysis, the Adapter uses SmartCMP Provider resource resolution when the alert exposes entityInstanceId or nodeInstanceId.

• Resolve related SmartCMP resources before finalizing the analysis narrative.
• Merge normalized type + properties resource facts into the alert analysis payload.
• If resource lookup is unavailable, continue the alert analysis with alert and policy facts, and treat resource enrichment as best-effort context.

Resource Health Analysis

Resource health analysis is independent of alert analysis:

• Resolve the resource through datasource resource helpers and use its normalized componentType.
• Load the effective monitoring model for that component; never substitute a generic VM metric list.
• Query only PromQL that can be scoped to the resolved resource through model-declared labels and exporter identity.
• Emit descriptive statistics and monitoring coverage, but leave healthy, abnormal, or indeterminate judgment to the AtlasClaw LLM.
• The final LLM response must include status, confidence, principal findings, metric evidence, missing evidence, and recommended actions.
• Treat disabled, unavailable, or missing monitoring as an evidence gap rather than proof that the resource is healthy or unhealthy.
• Do not read active alerts or alarm-policy thresholds for the resource-health conclusion.

Resource Alert Evidence

Resource alert evidence complements, but never changes, the independent health contract above.

• Call smartcmp_list_alerts with the same exact resource target used by the other comprehensive analysis tools.
• current_and_recent queries current ALERT_FIRING and ALERT_MUTED alerts without a trigger-time limit, then queries alerts whose current status is ALERT_RESOLVED and whose triggerAt is within the last seven days. SmartCMP does not expose a resolveAt range in this search contract, so this must not be described as “resolved during the last seven days.”
• Resolve the target to SmartCMP Resource.id, pass it through the exact targetEntityId query parameter, and verify the same field in every returned alert.
• Do not use the resource name, nodeInstanceId, or entityInstanceId as resource-association evidence.
• Read ##RESOURCE_ALERT_COVERAGE_START## before concluding that no alert was observed. partial or indeterminate association means the alert dimension is unknown.
• If the same alert is observed as current and resolved across the two requests, preserve both observations and treat the lifecycle race as partial evidence.
• Absence of a matched alert is not monitoring-health evidence and must not be used to upgrade an indeterminate health conclusion.