Qwen AI Observability
Perform read-only observability for applications deployed by
, answering “How is the application running, and how much will it cost?” without entering the console. All prices are in
RMB (¥).
Quick Path
- Identify the application — Read in the project directory (see ).
- Choose a time range — The default is the last hour; users can select 15 minutes / 1 hour / 24 hours.
- Inspect each layer — Application, ECS, optional RDS, and cost. Each returns one unified result state; a failure in one layer does not block the others.
- Report — Start with a one-sentence conclusion, followed by layer-by-layer summaries, risks, data timestamps, and unknown items.
Scope
| In scope | Out of scope |
|---|
| Applications deployed by (state file exists) | Applications without a state file |
| A single ECS, or ECS + RDS MySQL 8.0 | Other topologies / self-hosted servers |
| Read-only availability, performance, and cost overview | Any resource changes → use |
| Reporting runtime state (availability, performance, cost) | Source code review, finding bugs/vulnerabilities, determining which line of code is wrong, or modifying code |
| Alibaba Cloud China site, RMB | International site → use |
Code Issues Are Outside the Scope of This Skill
This skill performs read-only observability only. It reports runtime availability, performance, and cost; it does not review source code, locate defects, or modify code.
When code is involved, clearly inform the user that code changes are outside the scope of this skill and that the user must decide whether and how to make those changes and bear the resulting consequences.
Prerequisites
Aliyun CLI: Run
(version 3.x required). All queries directly call OpenAPI using their native camel-case form and do not depend on plugins. Use
only to view credential configuration status.
Never read, echo, print, or request AK/SK/Token. If no valid credential profile is configured, stop and ask the user to configure credentials outside this session.
See
references/cli_installation_guide.md
.
State and Scoring
Each layer returns one state—
(normal) ·
(available but risky) ·
(unavailable) ·
(cannot be determined)—together with the check time, target resource, key evidence, and data source. If an individual query fails, continue checking the other layers and mark the failed item as
—never silently omit it and never fabricate data.
Each layer is also assigned a score. The layer scores are summed into a 0–100 health score and an A/B/C/D grade (
A ·
B ·
C ·
D). Four dimensions are assessed:
| Dimension | Weight (with RDS) | Weight (without RDS) | Signals |
|---|
| Application | 35 | 45 | Reachability, , response time, error rate |
| ECS | 30 | 45 | CPU, memory, disk utilization, disk IO, network |
| RDS | 25 | — | Connection count, slow SQL, storage, row-lock waits |
| Availability | 10 | 10 | ECS/RDS runtime state, recent system events, EIP state and bandwidth, security-group exposure |
When the application does not use RDS, its weight is redistributed to the application and ECS. Cost is never scored—show the actual bill separately, along with a utilization-based optimization note.
Recommendations about missing backups/snapshots and security-group tightening are presented only as risks and recommendations and do not count toward the health score. Signals that affect availability, such as an unbound EIP, bandwidth at its limit, or missing inbound rules for ports 80/443, count toward the availability dimension.
How to Check
First identify the application, then inspect each layer. Read the corresponding guide before executing the commands for each step. A failure in one item does not affect the other layers—mark it
and continue.
These layer checks are independent and read-only. After identifying the application, issue each layer’s read-only APIs in parallel (background
+
) rather than waiting serially. Merge the Cloud Assistant commands for the same ECS into one script and retrieve all results at once to reduce round trips.
- Identify the application — Read to obtain the region and resource IDs. See workflow.
- Can the application be accessed? — Probe the public address and , check the application and Nginx services and ports, and summarize recent errors. See observe-application.
- How is the server doing? — Check the ECS state and CPU, network, disk, and memory metrics within the selected time range. See observe-ecs.
- How is the database doing? (Only when the application includes RDS) — Check its state, connection count, QPS/TPS, storage, row-lock waits, and sanitized slow SQL. See observe-rds.
- How is the public network and exposure surface? — Check EIP state and bandwidth, security-group allow rules for ports 80/443, and exposure risks. See observe-network.
- Are maintenance and backups in place? — Check ECS system events, system-disk snapshots, and RDS backups. See observe-resilience.
- How much has it cost? — Check the application’s actual charges, with an optional current-month projection. See observe-cost.
- Score and summarize — Score each layer, sum the scores to obtain the health score and grade, and then write a natural-language conclusion. See workflow.
By default, inspect the last hour. Respect any explicit user selection of 15 minutes / 1 hour / 24 hours and state the selected range in the report.
How to Report to the User
Start with the health score, grade, and a one-sentence conclusion. Then provide one short summary line each for the application, server, database (if any), and cost, including the supporting evidence for every line. Call out risks, explain what could not be determined and why, and state the data timestamp. If
exists in the project directory, include the most recent operation action (time, action, and result) so that the current score accounts for the latest recovery action.
When an actual outage is found, proactively offer to enter
for fault diagnosis. Use AskUserQuestion to offer
Diagnose and fix immediately /
Observe only; selecting the former enters
. At the same time, write the collected evidence to
in the project directory (fault layer, key metrics, and data timestamps, excluding passwords/signed URLs) so that operate can use it as the diagnostic starting point and avoid repeating the read-only checks.
text
Health score: 87 / 100 (B, Good)—The application is healthy; monitor the RDS connection trend.
Application: Access is normal, current response time is 186 ms, and the application and Nginx services are healthy.
ECS: Running normally, average CPU over the last hour is 31%, with no sustained high load detected.
RDS: Running normally, active connections increased from 12 to 38; monitor the connection-pool trend.
Cost: Actual charges for the August 2026 billing period were ¥88.30 (ECS ¥52.10, RDS ¥36.20).
Data as of: 2026-08-03 16:20 UTC+8
After presenting the summary, proactively ask whether the user wants to export a report file, for example: “Would you like me to export a Markdown or HTML report?” Let the user decide; do not require it.
Interaction Model
- Read-only information (health-check conclusions, state, and charges): Plain text, with one evidence line after each judgment (metric, state, and timestamp).
- State-changing actions (entering operate, exporting a report, etc.): Use AskUserQuestion and clearly explain what will be done · the impact · how it will be verified. Do not execute before confirmation.
- Proactive discipline: Stay quiet when everything is healthy. Speak up only when there is a risk or actual outage, and raise only one next action at a time (diagnosis / report export) for the user to choose.
Render an Optional Report File
When the user wants a saved Markdown or HTML report, aggregate the state, score, key metrics, and evidence for each layer into a JSON object and pass it to
for rendering. Do not manually create the final formatting. The HTML output is a multi-card report containing an overview with the health score and anomalies, one card per layer with a metrics table, a cost card, and a recommendations card. Markdown is its lightweight equivalent.
- Print the schema and populate it:
python3 scripts/render_report.py --schema
- Validate before rendering:
python3 scripts/render_report.py --validate -i data.json
- Render in the format selected by the user:
python3 scripts/render_report.py -i data.json -f md -o report.md
Optional Handoff to Operations
When an actual outage is found and the user chooses to enter
, write
to the project directory. Have operate use it as the diagnostic starting point and prioritize validating the named layer:
json
{
"from": "qianwenai-observe",
"generated_at": "2026-08-03T16:20:00+08:00",
"fault_layer": "rds",
"symptoms": ["RDS active connections increased from 12 to 190, approaching the limit"],
"metrics": {"rds_active_connections": 190, "app_http_code": 200}
}
Set
to one of
/
/
/
/
/
. Write only evidence obtained through read-only observation.
Never include passwords, connection strings, or signed URLs. The file serves only as a clue; operate must independently re-verify the findings before proposing recovery actions.
Security
| Rule | Description |
|---|
| Read-only | Cloud Assistant commands must be read-only; never modify the state of an instance or application. |
| Never expose passwords | Never read or output passwords from . |
| Redaction | AccessKey, Token, passwords, connection-string passwords, and Cookie values in log output must be redacted. |
| Slow SQL | Output only SQL templates or sanitized SQL and limit its length; never display literal parameter values. |
| Cost | Show only actual charges (¥) and the billing period; never show estimates. If no bill is available, mark the cost as . |
Required Permissions
See
references/ram_policies.md
. All permissions are read-only except for
cms:InstallMonitoringAgent
, which lazily installs an agent:
,
+
(read-only commands),
,
cms:DescribeMonitoringAgentStatuses
,
cms:InstallMonitoringAgent
,
ecs:DescribeSecurityGroupAttribute
,
ecs:DescribeInstanceHistoryEvents
,
,
,
bssopenapi:QueryInstanceBill
,
, and, when RDS is included,
,
rds:DescribeDBInstanceAttribute
,
rds:DescribeDBInstancePerformance
,
rds:DescribeSlowLogRecords
, and
.
More Details
The layer guides are linked above under “How to Check.” Two additional configuration references are also available, along with the RAM permissions reference:
- CLI Configuration — Installation and credential checks.
- CLI Pitfalls Quick Reference — Common errors involving parameter formats, time formats, and response parsing.
- RAM Permissions — The read-only permissions required by this skill.