Knowledge base logging and monitoring-Alibaba Cloud Model Studio(Model Studio)-阿里云帮助中心

All retrieval calls to a knowledge base are delivered to Log Service (SLS) as logs. You can use these logs for call auditing, troubleshooting, usage analysis, and alerting. This topic describes how to enable this feature, explains the meaning of the log fields, and provides common use cases.

Enable and view logs

Log Service (SLS) handles the storage and querying of all retrieval logs. When this feature is enabled, a dedicated Project and LogStore are automatically created in your account. You are billed for the actual storage and traffic that SLS consumes. For more information, see Log Service billing overview.

First-time use

On the Knowledge Base List page, click Monitoring Configuration in the upper-right corner. The monitoring configuration panel appears. On your first use, the panel guides you through the following tasks:

Authorize Log Service role permissions
Role: AliyunServiceRoleForSFMAccessSLS

Policy: AliyunServiceRolePolicyForSFMAccessSLS
Enable Log Service
Use your Log Service LogStore to collect and store Model Studio knowledge base logs. This enables real-time viewing and custom log analysis.
Create a Log Service LogStore
Refresh the page and click Create LogStore. The Retrieval Logs switch is enabled by default. You can click View Details to access the log repository.

After the Retrieval Logs switch shows Enabled, all retrieval calls are delivered in real time to the specified LogStore. The delivery latency is typically within seconds.

View and analyze logs

On the Knowledge Base List page, click Monitoring Configuration in the upper-right corner. In the Store to Log Service section of the panel, click View Details to open the corresponding LogStore page in the SLS console. There, you can use the full capabilities of SLS, including query analysis, dashboards, and alerts.

NoteTurning off the Retrieval Logs switch only stops the delivery of new logs. Previously delivered logs are retained and billed according to your default SLS configuration. To stop billing completely, you must delete the corresponding LogStore in the SLS console.

Field reference

Each retrieval log has the topic log_dispatch and includes the following indexed fields:

Field	Type	Description
`request_id`	string	A unique ID for a single request. Use this ID to trace a specific call.
`pipeline_id`	string	The knowledge base ID. Use this field to aggregate statistics by knowledge base.
`workspace_id`	string	The workspace ID, in the format llm-xxxx. Use this field for usage analysis and isolation across different workspaces.
`user_id`	string	The UID of the caller.
`path`	string	The API path that was called, for example, /api/v1/indices/rag/index/retrieve. Use this field to identify the call source.
`latency`	long	The request processing time in milliseconds (ms). Use this field for performance monitoring and slow query analysis.
`response_status_code`	long	The HTTP status code, such as 200, 4xx, or 5xx. Use this field for error monitoring.
`response_code`	string	The business response code. A successful call returns `Success`. A failed call returns a dot-separated error code, such as `Index.IndexNotExist` for a non-existent knowledge base. Use this field with `response_status_code` and `response_message` to identify the specific cause of an error.
`response_message`	string	The business response message. A successful call returns `success`. A failed call includes diagnostic information, such as `index not exist, index_id: xxx, workspace: llm-xxx`.
`request_body`	json	The request body in JSON format. Use this field for detailed investigation of request parameters.
`response_body`	json	The response body in JSON format. The top-level structure is `{code, status_code, data}`. Retrieved chunks are in `data.nodes[]`. Each node contains `score` (overall score), `text` (chunk text), and `metadata` (including `doc_name` and `doc_id`). You can use this field for auditing retrieval results.

Common use cases

The following are common use cases. For more information about the query syntax, see the SLS query syntax and SLS analysis syntax documentation.

NoteIf you encounter syntax errors, you can use the Use Copilot feature in the query analysis window to get AI-powered assistance in correcting and generating queries.

Scenario 1: Get usage statistics by knowledge base or workspace

* | select pipeline_id, count(*) as cnt
    group by pipeline_id
    order by cnt desc

Replace pipeline_id with workspace_id to aggregate the results by workspace. Alternatively, remove the aggregation field and use select distinct pipeline_id to obtain a list of active knowledge base IDs.

Scenario 2: Aggregate call volume by API path

* | select path, count(*) as cnt
    group by path
    order by cnt desc

Use this query to see the call distribution across different retrieval interfaces.

Perform more complex analysis

For more complex analysis, such as viewing details of failed requests, calculating statistics over a rolling time window, or performing cross-field queries, use the built-in Use Copilot feature in the SLS query analysis window. You can use natural language and the field reference from this document to generate and validate SQL queries directly in SLS.

Recommendations

We recommend setting up the following dashboard components and alert categories in Log Service (SLS). Set the specific thresholds based on your business's historical baseline.

Dashboard component	Purpose
Call volume trend (hourly/daily)	Monitor overall usage.
Top N knowledge bases by call volume	Identify core and long-tail knowledge bases.

Alert metric	Description
Business error rate (`response_code` != 'Success')	Monitors business-layer exceptions.
HTTP 5xx error rate	Monitors server-side exceptions.