SessionStore is a session-level storage and analysis resource that Simple Log Service (SLS) provides for AI applications. It is suitable for scenarios such as agent troubleshooting, performance optimization, effect evaluation, security auditing, and cost analysis. SessionStore associates multi-turn user sessions with application logs, model inputs and outputs, execution trajectories, and tool calls. This allows you to trace an abnormal response layer by layer down to the specific execution step, locate issues such as incorrect answers, tool call failures, and high latency in the call chain, and analyze token consumption and model and tool usage. SessionStore provides data support for the continuous optimization and operation of AI applications.
What is SessionStore
A SessionStore resides in a Simple Log Service project. You can manage the SessionStores of different applications in a project and view the data of the same application in different views.
|
Data view |
Content |
Typical questions |
|
Raw data |
Raw logs that are ingested or associated |
Are the data reported successfully? Are the raw fields correct? |
|
Single trajectory |
The inputs and outputs, steps, and agent relationships of an execution |
Where is the time spent in a request, and which tools are used? |
|
Sessions |
Multi-turn interactions and execution trajectories that are associated by session ID |
What is the context of a session, and in which turn does an exception occur? |
|
Trajectory features |
Tool, file, skill, or memory events that are extracted from the execution process |
Which types of tools frequently return errors, and which trajectories accessed a specific file? |
Basic concepts
|
Concept |
Description |
|
Raw data (Raw) |
Logs that are reported by applications, collectors, or gateways. Raw data is the basis for troubleshooting collection and field issues. |
|
Trajectory |
A structured representation of an execution process, including the inputs and outputs, the execution steps, and the agent call relationships that are explicitly provided in the data. Do not treat each raw span as a separate trajectory. |
|
Session |
A group of interactions that are associated by the same session ID. A session can contain multiple execution trajectories. |
|
Trajectory feature |
A structured record of a type of behavior in an execution process, such as tool calls and file reads and writes. Feature records are used for retrieval and statistics and are not equivalent to quality scores. |
|
Step |
An event in a trajectory, such as a model interaction, a tool call, or a tool return. |
|
Trace ID |
The identifier that is used to associate an execution of a call chain. Whether this identifier is available depends on the data source. |
Select a data ingestion mode
SessionStore supports two modes: direct write and reference.
|
Item |
Direct write mode (managed) |
Reference mode (reference) |
|
Scenario |
You want to ingest data from a new application or write data directly to a SessionStore. |
Application data has already been collected to a standard Logstore. |
|
Data write location |
The SessionStore in the current project |
The original source Logstore |
|
Whether to select a source Logstore during creation |
No |
Yes. You must select a source project and a source Logstore. |
|
Data source scope |
The ingestion pipeline of the current SessionStore |
A standard Logstore that belongs to the same Alibaba Cloud account and resides in the same region. The Logstore can belong to a different project. |
|
Collection configuration management |
Managed from the data ingestion entry of the SessionStore |
Managed in the source Logstore |
|
Raw data index |
Can be created or modified in the SessionStore |
Read-only in the SessionStore. You must modify the index in the source Logstore. |
|
Adjustment of the SessionStore retention policy |
Adjusts the data that is managed by the SessionStore |
Does not change the retention policy of the source Logstore |
Supported data formats
|
Data format |
Applicable source |
|
OpenTelemetry Trace |
Execution chains and GenAI data that are reported in the form of OpenTelemetry traces or spans. Trace logs that are ingested by using Cloud Monitor 2.0 or Application Real-Time Monitoring Service (ARMS) agents, or trace logs that are ingested by using the OpenTelemetry SDK. |
|
OpenTelemetry Log Ebpf |
eBPF agent logs that are collected in the corresponding format. Logs that are collected by using the input_agentsight plug-in of LoongCollector in Simple Log Service. |
|
OpenTelemetry Log AI Gateway |
Alibaba Cloud AI Gateway logs |
Typical scenarios
Troubleshoot an abnormal response
When an agent returns an incorrect answer, a tool call fails, or a task is not completed as expected, you can view the model inputs and outputs, tool parameters, and returned results in the execution trajectory to locate the step in which the exception occurs. You can also check the basis of the answer against the associated raw logs. For example, when a customer service agent answers that an order payment has not been received, you can trace the order query, payment records, and fault information to determine whether the answer is supported by facts.
Analyze multi-agent collaboration
When a task is completed by multiple agents, you can use the relationships between the main agent and sub-agents that are recorded in the trajectory to reconstruct the task delegation, branch execution, and result return process. This helps you analyze which agent causes an issue and how the branch results affect the final answer. For example, after a customer service agent delegates fault troubleshooting to a diagnostic agent, you can check whether the diagnostic result is correctly used.
Track multi-turn sessions and task results
When a user asks follow-up questions about the same issue, you can use the session to associate each turn of the conversation with its execution trajectory. Then, you can compare changes in the business status, the query results of each turn, and the agent answers to check whether the agent updates its judgment based on new evidence. For example, in a series of interactions such as payment made but not received, service recovered, and payment verified again, you can distinguish service recovery from the actual receipt of the order payment, and identify cases in which the agent relies on outdated context or claims that the issue is resolved without verification.
Analyze execution latency and resource consumption
When an agent responds slowly or consumes a large number of tokens, you can analyze the number of calls, execution latency, and token usage by session, turn, model, and agent. You can drill down to specific model calls, tool calls, and collaboration branches to identify the steps in which latency is concentrated and repeated executions occur. This provides a basis for adjusting model selection, context organization, and collaboration workflows.
Audit agent operations and execution basis
When you need to check whether an agent follows the task requirements, you can use tool names, call parameters, returned results, and raw records to trace the operations that are actually performed, and verify the results against the associated business vouchers. For example, in a task that only allows order queries, you can check whether the collected execution records contain reissue or refund calls, and whether the answer that the payment has been received is supported by payment records.
Build evaluation and regression samples
When you need to verify the effect of changes to a model, a prompt, or an agent version, you can organize the consecutive questions and answers, execution trajectories, and tool results of production sessions into evaluation samples. These samples provide reusable context and execution evidence for evaluation systems such as AgentLoop. For example, you can use a session in which the service has recovered but no payment record exists as a regression case to check whether the new version still follows the rule that payment receipt must not be claimed without a voucher.