STAROps:STAROps Skill Integration

Scenario 1: Query the number of APM services

Prompt

How many APM services are in the current workspace?

Example agent output

The current workspace rca-benchmark contains 49 APM services.

Language distribution overview:

| Language | Count |
|------|------|
| Java | Most (ad, fraud-detection, accounting, etc.) |
| Go | Several (product-catalog, checkout, etc.) |
| Node.js | Several (frontend, frontend-web, etc.) |
| .NET | Several (cart, accounting, etc.) |
| Python / Rust / PHP / Ruby / C++ | A few each |

These services cover the complete link of e-commerce and financial scenarios, including core
microservices such as frontend, product-catalog, cart, checkout, payment, shipping, and
fraud-detection.

Scenario 2: View service distribution by language

Prompt

Show me services grouped by programming language in the current workspace.

Example agent output

The current workspace rca-benchmark contains 49 APM services, grouped by programming language:

| Language | Count | Services |
|------|---------|---------|
| Java | 28 | ad, fraud-detection, inventory, loyalty, review, promotion, wishlist, notification, warehouse, risk-scoring, search, pricing, user-profile, refund, coupon, order, audit-trail, payment-router, ... |
| Golang | 3 | product-catalog, flagd, checkout |
| Node.js | 3 | frontend, payment, loadgenerator |
| .NET | 2 | cart, accounting |
| Python | 1 | recommendation |
| C++ | 1 | currency |
| Rust | 1 | shipping |
| PHP | 1 | quote |
| Ruby | 1 | email |
| WebJS | 1 | frontend-web |
| Not specified | 2 | image-provider, frontend-proxy |

A total of 10 programming languages are represented. Java services account for the largest
share (28 services) and are the primary backend development language.

Scenario 3: Identify the root cause of service errors

Prompt

Identify the root cause of errors in the inventory service.

Example agent output

## Root Cause Analysis Report: inventory Service 5xx Errors

### Conclusion

Root cause: The inventory service timed out (5 seconds) when calling the downstream
notification service, causing cascading 5xx errors.

### Evidence Chain

#### 1. Trace Analysis

61 error traces were diagnosed and analyzed. All errors point to the same step:

| Error Span | Service | Duration | Diagnosis |
|-----------|------|------|----------|
| notification POST | notification | ~5000ms | error_and_slow |
| checkout orders publish | checkout | 1366-1927ms | slow |

Call path:
frontend-proxy -> frontend -> checkout -> inventory -> notification (5s timeout)

In all error traces, the POST call to the notification service takes about 5000ms
(reaching the timeout threshold), and statusCode=2 indicates an error.

#### 2. Related Alerts

Alerts triggered in the last 30 minutes:
- [Health Rule] latency_avg_threshold_critical (CRITICAL): average latency of the checkout service is 3.6 seconds
- Slow frontend interface response alert (CRITICAL): average response time of frontend service POST interfaces > 1000ms
- Container memory usage above 85% (CRITICAL): memory usage of the kafka container is 88.52%

#### 3. Resource Status of the notification Service

| Metric | Value | Status |
|------|-----|------|
| Pod status | Running | Normal |
| Memory usage/limit | 66.6% | Normal |
| Memory usage/request | 133.2% | Exceeds request value |

### Possible Causes

1. Downstream dependency issue of the notification service: high memory usage of the Kafka container (88.52%) may delay message processing.
2. Insufficient resources of the notification service: memory usage reaches 133% of the request value, which may trigger GC under traffic peaks.
3. Network connectivity issue: connections from inventory to notification may suffer from latency or connection pool exhaustion.

### Immediate Remediation Suggestions

1. Check the notification service logs and the Kafka cluster status.
2. Temporarily scale up the notification service (increase resources.limits.memory).
3. Configure more appropriate timeout and circuit breaker policies in the inventory service to prevent cascading impact.

Scenario 4: Multi-turn follow-up based on diagnostic conclusions

The STAROps Skill supports multi-turn interactions. By continuing within the same thread from the previous turn, you can progressively narrow the investigation scope.

Turn 1 prompt

Identify the root cause of errors in the inventory service.

Turn 2 prompt (same thread)

Based on the notification service timeout identified earlier, check the error logs of the
notification service itself for the last 30 minutes, and determine whether the issue is
internal to notification or caused by its downstream Kafka.

Turn 3 prompt (continue drilling down)

The memory usage of the Kafka container is 88.52%. Provide scale-up recommendations and a
temporary mitigation plan.

Multi-turn follow-up that reuses the same threadId allows the STAROps Agent to reason directly from the accumulated tool call results (metrics, traces, and logs). This avoids repeated data scans and keeps conclusions consistent.

Do I need to create a thread in the console before using the Skill?

No. The Skill automatically creates a session thread through CreateThread on first invocation and prints the STAROPS_URL. You can use this URL to navigate directly to the STAROps console and view all messages and tool call records for that thread.

How do I configure Alibaba Cloud account credentials?

Run aliyun configure in the Alibaba Cloud CLI. The Skill automatically reads the credentials from ~/.aliyun/config.json. For other credential sources and their priority order, see Configure credentials.

Can I use a custom endpoint?

Yes. Set the environment variable STAROPS_AGENT_ENDPOINT=<domain> to specify a dedicated or private network endpoint.

What should I do if the diagnostic results are not specific enough?

Consider the following improvements:

• Include key evidence in your prompt: the service name, time range, TraceID, and the original alert content.

• Verify that the workspace has APM, SLS, and UModel data sources connected. Missing data sources prevent the STAROps Agent from gathering evidence.

• Reuse --thread for multi-turn follow-up questions, so that the STAROps Agent can drill down from existing conclusions instead of starting a new session.

• If STAROps returns (No assistant answer was returned.) or only a generic response, retry once using the same thread. If the issue persists, honestly inform the user that STAROps did not return valid diagnostic data. Do not fabricate conclusions from prior knowledge.

HTTP 401 Unauthorized

The credential chain did not resolve an identity with STAROps permissions.

Resolution:

• Verify that the Credentials default chain can resolve at least one of the following sources: STS token, RAM role, CLI profile, or instance metadata.

• Verify that the RAM policy of the resolved identity includes starops:CreateThread and starops:CreateChat.

• If you use an STS token, confirm that the token has not expired and that the assumed role includes the required permissions.

• Grant the required permissions before you reissue the request.

HTTP 404 Not Found

One of the Digital Employee, workspace, or UID values does not match the actual resources.

Resolution:

Verify that STAROPS_AGENT_EMPLOYEE, STAROPS_AGENT_WORKSPACE, and STAROPS_AGENT_UID all correspond to the same set of actual resources. The UID must be the Alibaba Cloud account UID of the account that owns the workspace.

ConfigError: Missing required STAROps environment variables

One or more of STAROPS_AGENT_EMPLOYEE, STAROPS_AGENT_WORKSPACE, or STAROPS_AGENT_UID is not set or is empty.

Resolution:

Run the pre-flight check script in SKILL.md to confirm that all variables are set, and then retry.

CredentialError

The Alibaba Cloud Credentials SDK did not find any available credential source.

Resolution:

Configure credentials through one of the supported sources. The recommended method is the Alibaba Cloud CLI (aliyun configure). For details, see Configure credentials.

Idle timeout error

No SSE events were received within the --idle-timeout window. The STAROps Agent may be stuck.

Resolution:

Retry once with the same --thread. For complex tasks that are expected to be silent for extended periods, increase --idle-timeout accordingly.

ModuleNotFoundError

The Python dependencies are not installed.

Resolution:

Run pip3 install -r scripts/requirements.txt in the Skill root directory. The dependency file is in the scripts/ subdirectory, not the project root.