All Products
Search

This Product

    STAROps:From data connection to fault diagnosis

    Document Center

    STAROps:From data connection to fault diagnosis

    Last Updated:Sep 21, 2026

    This topic uses CloudMonitor 2.0 as an example to show how to connect observable data to a custom Digital Employee and complete a verifiable fault diagnosis. The process consists of three steps: create a CloudMonitor 2.0 connector, verify data access, and initiate and verify fault diagnosis. After you complete the process, you obtain a diagnostic conclusion based on the connected data.

    Prerequisites

    Before you begin, make sure that the following requirements are met:

    Item

    Requirement

    STAROps and a Digital Employee

    You can access STAROps and have created a custom Digital Employee.

    CloudMonitor 2.0 workspace

    The workspace is created and contains at least one type of entity, metric, log, or trace data that can be used for diagnosis.

    Operator permissions

    The current RAM user or RAM role can operate the target Digital Employee and manage connectors. If you use a custom runtime role, the operator must also have the ram:PassRole permission to pass the role to the Digital Employee.

    Diagnostic time range

    We recommend that you select a time range in which data is known to exist. A known exception time and entity help verify diagnostic accuracy, but are not required.

    This topic uses the Employee role to access the workspace. The role is AliyunServiceRoleForSTAROps, which is automatically created and maintained by STAROps. You do not need to create or authorize an additional RAM role.

    If your current identity cannot add or manage connectors, contact an administrator to grant the required connector management permissions.

    Important

    Operator permissions and Digital Employee runtime permissions are independent of each other. A RAM user who can operate a Digital Employee or connector does not necessarily allow the Digital Employee to read business data. Likewise, a Digital Employee runtime role that can read data does not automatically grant the same permissions to the RAM user.

    Step 1: Create a CloudMonitor 2.0 connector

    1. Log on to the STAROps console. In the Digital Employee list, click the name of the target Digital Employee, and then choose Settings > Connectors > Observable.

    2. Click Add observable, select CloudMonitor 2.0, and then click Next.

    3. Enter a connector ID and name.

    4. Set the access role to Employee role.

    5. Select the region of the target workspace and then select the workspace.

    6. Turn on Agentic modeling. After you save the connector, the system creates a data model for the data source.

    7. On the Check and add page, verify the connector ID, name, role, region, workspace, and modeling switch, and then save the connector.

    After you save the connector, it appears in the Observable connector list and the system automatically checks its connection status. For the status criteria, see Step 2.

    Note

    • One connector corresponds to one workspace. A single workspace cannot be bound to multiple connectors. After a connector is created, its role, region, and workspace cannot be modified. To change them, delete the connector and create a new one. This restriction does not apply to the Agentic modeling switch, which can be turned on after creation.

    • If the workspace and Digital Employee are stored in different regions, cross-region data transfer may occur. If different countries or areas are involved, cross-border data transfer may also occur. Select a region based on your data compliance requirements.

    Step 2: Verify data access

    Verify each layer in the following order. A connector status of Succeeded does not mean that the entire diagnostic workflow is available.

    Verification layer

    Success criteria

    Troubleshooting

    Connector

    The Observable connector list displays Succeeded, and the role, region, and workspace match the expected values.

    View the failure cause in the connector details and correct the role permissions. If you need to change the role, region, or workspace, delete the connector and create a new one.

    Data modeling

    The data modeling task is complete and displays entity or model information that corresponds to the actual data types in the workspace.

    Open the modeling conversation to view the failure information. After you correct the connector or data permissions, initiate modeling again in the same conversation.

    Runtime query

    A conversation can query at least one type of connected data within the target time range.

    If the error message identifies a missing RAM Action, add the corresponding permission to the Digital Employee runtime role. If no specific Action is provided, check the role, region, workspace, data type, and time range in sequence.

    Step 3: Initiate and verify fault diagnosis

    Exploratory diagnosis

    If you do not know the specific abnormal entity, first ask the Digital Employee to identify abnormal objects within a specified time range.

    1. In the Digital Employee, click New conversation. Then, use the time selector at the top of the conversation page to select a time range in which data is known to exist.

    2. Enter and send a diagnostic question. The following example identifies abnormal entities:

      Use the data in the CloudMonitor 2.0 connector <connector name> to check the overall operating status from <start time> to <end time>. Identify abnormal services or instances and provide the basis for your assessment. If data or permissions are insufficient, clearly state what information is missing.

    3. From the abnormal objects returned by the Digital Employee, select the entity that you want to analyze further, and then perform a targeted diagnosis.

    Targeted diagnosis

    If you already know the abnormal entity, you can analyze the entity directly.

    1. Enter @ in the conversation box, and select the Service, Pod, or another entity that you want to diagnose.

    2. Describe the symptom and time range in the question, and then send the question. The following example analyzes an entity that you selected by using @:

      Use the data in the CloudMonitor 2.0 connector <connector name> to analyze the increase in error rate for my selected entity from <start time> to <end time>. Identify possible causes, provide evidence supported by the currently available data, and describe recommended actions and verification methods. If data or permissions are insufficient, clearly state what information is missing.

    Verify the diagnostic result

    After a diagnostic conclusion or a link to the full diagnostic report appears, verify the result based on the following criteria:

    • The analysis object, time range, and workspace match the question.

    • The conclusion contains at least one piece of verifiable evidence from the connected data.

    • If a type of data cannot be obtained, the result clearly states the data or permission limitation instead of fabricating evidence.

    • The recommended actions include risk information and verification methods.

    • Speculative conclusions are clearly marked as requiring verification.

    If the evidence is insufficient, ask follow-up questions based on the specific gap:

    Evidence gap

    Follow-up example

    No time comparison

    Compare the error rate and latency during the abnormal period with those during the same period on the previous day.

    No analysis of upstream or downstream impacts

    Check whether the upstream ingress and downstream dependencies of the service have related exceptions.

    No change correlation

    Analyze the issue again based on release, configuration, or scaling records generated before the exception occurred.

    No fix verification

    The fix is complete. Compare the key metrics before and after the fix and confirm whether the service has recovered.

    What to do next

    After you complete this process, you can perform the following operation as needed:

    FAQ

    What do I do if the target workspace is not displayed in the workspace list?

    Perform the following checks in sequence:

    1. Make sure that the target workspace exists and that the selected region matches the region of the workspace.

    2. Check whether the Digital Employee runtime role has permission to access the target workspace.

    What do I do if a message indicates that the workspace is already bound when I save the connector?

    A single workspace cannot be bound to multiple connectors. Contact an administrator to identify the Digital Employee to which the existing connector belongs. Continue to use the existing connector or select another workspace.

    What do I do if the connector status is Failed?

    Perform the following checks in sequence:

    1. View the failure cause in the connector details.

    2. Check whether the role, region, and workspace are still valid.

    3. After you correct the permissions, refresh the connector status. If you need to change the role, region, or workspace, delete the connector and create a new one.

    What do I do if data modeling fails?

    Perform the following checks in sequence:

    1. Open the Data modeling page and find the modeling task for the connector.

    2. View the error information in the modeling conversation.

    3. Correct the connector or data permission issue.

    4. Click Start modeling to initiate the modeling task again.

    What do I do if the target entity is not displayed after I enter @?

    Perform the following checks in sequence:

    1. Make sure that data modeling for the corresponding connector is complete.

    2. Make sure that the workspace contains entity data that can be modeled.

    3. Make sure that the target entity belongs to the workspace bound to the connector.

    4. After you correct the connector, data, or modeling issue, enter @ again to select the entity.