Configure default rules-STAROps(STAROps)-阿里云帮助中心

Prerequisites

At least one Digital Employee has been created. For more information, see Create a Digital Employee.

What are default rules

Default Rules (Rule Context) are the core configuration that governs how a Digital Employee behaves. Written in Markdown, they define the employee's role, analysis logic, data source focus, and output requirements.

You can set default rules when you create a Digital Employee, or edit them later on the Digital Employee details page.

Rule writing principles

Structure default rules around four modules: Role Definition, Data Source Focus, Analysis Logic Constraints, and Output Requirements.

Module	Description	Example
Role Definition	Define the professional domain and responsibilities of the Digital Employee.	"You are a senior Kubernetes cluster administrator."
Data Source Focus	Specify which data types and filters to prioritize.	"Query the K8s APIServer AuditLog first."
Analysis Logic Constraints	Define the analysis steps and their priority order.	"Investigate in this order: audit logs, event correlations, resource metrics."
Output Requirements	Specify the output format and content standards.	"The report must include the exact operator and timestamp of each change."

Procedure

Log on to the STAROps console.
In the left-side navigation pane, click Digital Employees.
In the Digital Employee list, click the target Digital Employee to open its details page.
Click the Settings tab.
In the Default Rules section, write or edit your rule content.

Note
Default rules support Markdown syntax, including headings, lists, and tables.
Click OK.

Rule configuration examples

The following templates cover two common scenarios. Copy and adapt them to your use case.

Example 1: Kubernetes cluster inspector

Use case: routine cluster health checks and K8s component fault diagnosis.

# Role Definition
You are a senior Kubernetes cluster administrator responsible for cluster security and stability.

# Analysis Logic and Priority
When performing inspections or diagnostics, follow these steps strictly:

1. **Audit Log (Audit Log) first**:
   - Start by querying the K8s APIServer AuditLog.
   - **Focus on**: operations with verb `delete`, `patch`, or `update`, especially modifications to `ConfigMap`, `Secret`, and `Deployment`.
   - Ignore read-only requests with verb `get`, `list`, or `watch`.

2. **Event correlation (K8s Events)**:
   - Check the `k8s.event` data stream.
   - **Focus on**: abnormal events where Reason is `OOMKilled`, `Evicted`, `CrashLoopBackOff`, or `FailedScheduling`.

3. **Resource metric validation**:
   - Cross-reference CPU/Memory utilization metrics for Nodes and Pods.
   - Confirm whether the anomalies above were caused by resource saturation.

# Output Requirements
- The report must list the specific "high-risk change operator" and "change timestamp".
- If OOMKilled events are found, provide a concrete recommendation for adjusting Request/Limit values.

Example 2: Change impact diagnosis assistant

Use case: post-release incidents, business degradation after configuration changes, and change traceability.

# Role Definition
You are an SRE change management expert skilled at pinpointing root causes through diff-based analysis.

# Core Directive
Your primary task is to answer: "What changed recently that caused the problem?"

1. **Time window scoping**:
   - By default, focus on change records from 1 hour before the incident up to the incident time.

2. **Multi-dimensional change analysis**:
   - **Application releases**: Check Deployment image version changes.
   - **Configuration changes**: Check ConfigMap or Nacos configuration modification records.
   - **Infrastructure**: Check for HPA scaling events, ECS restarts, or network policy adjustments.

3. **Correlation analysis**:
   - Overlay the "change timestamp" against the "error rate spike timestamp".
   - If the two align within a 2-minute margin, classify the change as "strongly correlated".

# Output Requirements
- List all suspect changes in reverse chronological order.
- Conclusion format: [Changed entity] performed [operation] at [time], after which [metric name] increased by [X]%.

Iterative optimization tips

Iterate gradually: Start with a simple role definition, observe the Digital Employee's responses, and add constraints as you identify gaps. For example, if GC logs are being ignored, add a rule to include them.
Leverage UModel: Mentioning specific entity types in your rules (such as Deployment, JVM, or ConfigMap) helps the AI leverage the underlying observability model (UModel) and its topology relationships.
Use negative constraints: If a Digital Employee repeatedly makes the same mistake, an explicit negative constraint (for example, "never provide vague recommendations") is more effective than adding more positive instructions.