The Player Says 'My Top-Up Never Arrived.' The Log Only Says BAG_FULL.

This article introduces how the SLS Semantic Layer and DataAgent automate multi-log troubleshooting to deliver verifiable business conclusions.

1. Why Does a Single "Top-Up Not Credited" Complaint Require Checking Multiple Logs?

At 9:47 p.m., support agent Lin picks up an urgent ticket. The player says they just paid 648 CNY, the money is gone, but the top-up package never showed up.

Lin checks the order first: payment succeeded. She checks the payment callback: signature verification passed too. Neither the money nor the payment channel is at fault, so the problem has to be in delivery. She switches to the delivery log and finds a single line: deliver_status = failed. Following the trace_id into the system log, she picks up one more clue: the error code BAG_FULL.

A veteran agent reads this instantly: the player's inventory was full, the system retried delivery, and it kept failing. To someone new to the business, though, this is just a handful of fields and values scattered across different LogStores. To give the player one accurate answer, Lin has to jump back and forth between orders, payments, delivery, and the inventory transaction log, translating machine-recorded facts into a conclusion the player can understand.

This ticket comes from a demo we built, and the logs are synthetic. But cases like this are daily work for game support: top-ups and payments, item changes, matchmaking and ranked play, anti-cheat appeals, social disputes. Answering one of them usually spans several LogStores and takes three to six queries in sequence. The most obvious cost is time: the agent switches repeatedly among orders, payment callbacks, delivery, and the inventory transaction log, several rounds of queries for a single question. And finding the data does not mean understanding it: a newcomer and a veteran can read the same field and reach different conclusions. Add phrases like "revenue," "credited," or "I won but lost points," which different business teams compute differently, and you first have to ask which metric definition the question means.

2. Logs Record Facts, Not Conclusions

The logs are all there. The difficulty is that logs never state the business conclusion outright. Look at deliver_status = delivered and item_id = WPN_LEG_001: neither a person nor an AI can know from the values alone that they mean "delivered" and "Skysplitter Blade." The machine records facts; what those facts mean for the business is not written anywhere in the log.

The SLS semantic layer and DataAgent supply that missing translation. The semantic layer organizes the fields, enum values, business metrics, glossary terms, and samples in your LogStores into a business dictionary. Once the dictionary exists, everyone who asks gets the same metric definition. The DataAgent is the investigator who carries that dictionary. It is attached to at least one Context Model; it maps the player's natural-language question to an explicit metric definition and data source, then builds the queries, analyzes the evidence, and finally produces a conclusion and a draft reply.

3. Three-Layer Collaboration: From Raw Logs to Support Conclusions

All synthetic logs for the sample game are written to the SLS project semantic-game-demo. When troubleshooting, the DataAgent uses three business-evidence LogStores.

LogStore	Main data
game-biz-logstore	Business transaction records for orders, payment callbacks, and delivery; inventory and item changes; gift mail, guild rewards, and season rewards
game-audit-logstore	Audit records for payment risk control, player trades, matchmaking and match settlement, anti-cheat and appeals, reports, and season participation
game-system-logstore	System runtime records for service faults, dependency failures and recovery, performance metrics, and season rule configuration

Most player events carry the common fields user_id, server_id, timestamp, and trace_id. Cross-LogStore troubleshooting then relies on business identifiers such as order_id, battle_id, and item_uuid to string the evidence together. On top of that, each of the three layers has its own job.

(1) Source Model: Describing the Data as It Is

A Source Model maps one-to-one to a project, so you do not name it separately. Once you start automatic generation, the system uses an LLM to analyze dashboards, alerts, Scheduled SQL, and data sampling together, and extracts field semantics, metrics, and glossary terms. Generation time depends on how many LogStores the project holds and how much data they contain; it usually finishes within a few minutes. Extraction results fall into three states by how strong the evidence is. Auto-adopted means the evidence is sufficient and the entry is ready to use. Not adopted means the evidence is thin or ambiguous and someone needs to confirm it. Manually adopted means a person has already checked it. The DataAgent uses only adopted content, so a field meaning still in doubt is never treated as a business fact. A few examples make clear what it extracts.

Semantic element	Game scenario example	Problem it solves
Field	In the order log, deliver_status = delivered means delivered, and amount is denominated in cents	How to interpret fields and enum values
Metric	"Recognized recharge revenue" = SUM(CASE WHEN deliver_status = 'delivered' THEN amount ELSE 0 END)	How a business metric is computed
Glossary term	"Diamonds" = currency_diamond; "Skysplitter Blade" = WPN_LEG_001	How player wording maps to the logs

(2) Context Model: Scoped by Business, Aggregated Centrally

The Context Model is the account-level semantic layer. Each project has one Source Model. When a business spans several projects, you first pick the Source Models of the relevant projects, then select from them the LogStores this business actually needs, and the scattered data semantics come together into one unified model. The game-support Context Model in this article, for instance, selects only the three business-evidence LogStores; unrelated data sources and evaluation-only data sources stay out. Content in a Context Model comes from two places. One is automatic synchronization: whatever the selected LogStores hold in the Source Model flows in automatically, with a maximum delay of 60 seconds, and entries are only added, never removed. The other is manual additions: you can append metrics, glossary terms, and samples, and automatic synchronization never touches these entries. A Context Model aggregated this way serves the DataAgent, and agents such as Codex, OpenClaw, and Claude can connect to it and reuse it as well.

(3) DataAgent: Troubleshooting with a Unified Definition

A DataAgent is a conversational assistant instance, and you attach at least one Context Model when you create it. Given a question, it first identifies the business terms and the metric definition, then chooses data sources, builds queries, strings multi-step log evidence together, and finally outputs a conclusion, the supporting evidence, and a draft reply. You can check every step.

4. Can We Skip the Semantic Layer and Let the LLM Query Logs Directly?

By now you are surely asking: querying SLS logs through Model Context Protocol (MCP) or NL2SQL already works today. If the LLM can write the query itself, why build a semantic layer first?

Take "revenue" from earlier. It could mean order face value, the amount actually paid, or the delivered amount. Ask the LLM directly and it has to guess which field to use and whether to filter for successful delivery; ask the same question twice and it may guess differently. The semantic layer pins down the formula for recognized recharge revenue, so the same metric definition is computed no matter who asks. Now take "Big Sword." That is the name players use; the log stores WPN_LEG_001. Without the glossary mapping, the LLM does not know which log table to open or which value to match, and will likely run a full-text search on the player's wording, find nothing, and tell the player the item was never lost. Then there is that top-up ticket. The useful conclusion is that a full inventory caused delivery to fail, and it takes the payment, delivery, and system logs together to support it. A one-shot query tends to stop at the first plausible answer: it finds deliver_status = failed, blames delivery, and never asks why delivery failed. The DataAgent gets as far as inventory capacity because the Context Model tells it in what order to look and which pieces of evidence to connect.

The query capability is already there. To make queries trustworthy, every conclusion has to map to fixed fields and formulas, and the path of verification has to be deterministic. That is exactly what the semantic layer does. Grant an LLM query permissions without this layer and its answers will read smoothly, so smoothly that you will have trouble noticing whether the metric definition is right and whether the evidence is complete.

5. Best Practice: Build a Game-Support DataAgent in Four Steps

There are three prerequisites. Business logs are already in the project semantic-game-demo, the relevant LogStores have the field indexes required for querying, and the operator has permissions to create and configure a DataAgent.

Step 1: Generate the Source Model for Semantic-game-demo

Open DataAgent from the SLS console home page.

On the source model tab, select the business project semantic-game-demo.

After you start the source model generation task, you can check its status on the details page. Generation time depends on how many LogStores the project holds and how much data they contain; it usually finishes within a few minutes.

When generation finishes, the system lists the field semantics, metrics, and business glossary terms extracted from the LogStores.

For entries that are not adopted, verify the business meaning first, then adopt them in bulk once they are correct, or edit and adopt them one by one.

Step 2: Create the Game Context Model

Create a Context Model and associate the source model of semantic-game-demo. In the description, we recommend stating the business scope the model covers and its main uses, for example support scenarios such as top-ups, items, ranked play, and anti-cheat.

Once associated, the adopted field semantics, metrics, and glossary terms from the source model are synchronized in. You can then add domain-specific terms, metric definitions, and common samples, where a sample can include the question description, the query statement, and the related fields.

Step 3: Create the Game-support DataAgent

Create the DataAgent and attach the context model you built in the previous step.

A DataAgent requires a dedicated RAM role at runtime. By default you can use the system role aliyunslsdataagentrole; if authorization is not yet complete, grant it through the authorization link first. To restrict which resources the agent can access, switch to a custom role, in which case the operator needs the corresponding ram:PassRole permission.

Step 4: Run Conversational Tests with Typical Complaints

Create a conversation, select the DataAgent you just created, and paste in the player's complaint verbatim. Using the context model, the DataAgent identifies the glossary terms and metric definitions, queries the relevant logs, and outputs the key evidence, its analysis, and a draft support reply.

6. How Did the Blind Test Perform?

The test runs on reproducible synthetic logs and covers 13 categories of customer-complaint scenarios.

First, a word on evaluation isolation. game-qa-logstore stores only the questions, the ground truth, and the evaluation evidence; it is not a business query data source. During a blind test, do not grant the DataAgent query permissions on this LogStore, or it will see the ground truth. Take "top-up not credited" as an example. The DataAgent first checks payment: the callback succeeded, signature verification passed, the money really was paid. Next it checks delivery: delivery failed after three retries. It then looks into the cause, and the system error and the inventory capacity point to the same one: a full inventory. The final conclusion rests on the payment, delivery, and system logs together; a single error code cannot get you there.

Now three representative cases.

Player question	Key evidence the DataAgent connects	Conclusion produced
Item missing "Big Sword" WPN_LEG_001	Joins the inventory transaction log with trade records via item_uuid; logon devices normal, no unusual logon; change_reason = trade_sell, sale price 64,663 gold	Based on the available logs, the item was sold on the auction house from the current account, and no evidence of unusual logon or abnormal device activity has been found so far. We recommend providing the trade record and prompting the player to check their account security
Won but lost rating points Match BT_FC3E058B	battle_result = win; rating dropped from 1259 to 1237; rank_change_reason = disconnect_penalty; disconnected for 130–200 seconds, over the 120-second threshold	The rating change comes from the "disconnect counts as forfeit" penalty rule, not from a fault in the normal win-rating logic
Wrongful cheating-ban appeal Event CHT_922FE15A	Detection value 8.85, about 4.1% above the 8.5 threshold; ml_score = 0.62, below the high-confidence bar of 0.7; memory scan result clean; ping 180–250 ms	The available evidence better supports a movement-speed calculation deviation caused by high latency; we recommend handing the case to the anti-cheat team for manual review

The restraint in these conclusions is worth noting. The missing-item conclusion does not say the item "was not stolen"; it says the available logs show no anomalous evidence, and it recommends prompting the player to check their account security. The wrongful-ban appeal does not overturn the ban either; it says the evidence better supports a high-latency deviation and recommends manual review. The conclusion stops where the evidence stops, and the action is left to a person. When a question could map to more than one metric definition, for instance "revenue" meaning order face value, the amount actually paid, or the delivered amount, the DataAgent first asks which definition you want, then continues the query. To reduce these clarifications, add more precise glossary terms, metric descriptions, and samples to the context model.

Making It Work Reliably in Your Own Business

The data is already in SLS, but the knowledge needed to understand it is scattered. Field meanings live in the code, status explanations live in stray documents; dig around and you can still find both. The other two are harder to get. Metric definitions live in business people's heads, and knowing which logs to check for which problem rests on the experience of a few experts. Newcomers keep asking, business people keep depending on engineering, and an AI that does not know the real metric definition can reach a wrong conclusion.

The semantic layer and DataAgent move all this knowledge into one place. Field meanings, metric definitions, and query paths are pinned down; business people can ask in natural language, and the DataAgent understands the question, picks data sources, runs queries, and organizes the evidence, with results you can check. The time newcomers spend asking and engineers spend explaining goes away. You do not have to do it all at once, either: start by getting one question to work end to end. Find the high-frequency question your team answers every day, pick the relevant LogStores, confirm the fields, glossary terms, and metric definitions, add typical phrasings and query samples, and let the DataAgent go from question to conclusion on its own. Once that proves out, extend to more questions, more projects, and more business roles. So we recommend the following:

1. Start with high-frequency, high-value scenarios. Pin down the metric definitions for questions like top-up not credited and duplicate charge first; they make a verifiable baseline easy to establish.

2. Get definitions right before pursuing coverage. Confirm these one by one first: amount units, status enums, time fields, unique identifiers, and metric formulas. If the definitions are wrong, the more questions you cover, the further off you get.

3. Build human review into the process. Set clear boundaries for actions such as refunds, redelivery, bans, and unbans: the DataAgent produces evidence and recommendations, and a person reviews them before execution.

A few limits are worth stating plainly as well:

Limit	Details
Centralized services (context model, DataAgent)	Available only in the cn-beijing central region
Source model	Deployed per region; supported in cn-beijing, cn-shanghai, cn-hangzhou, cn-chengdu, and cn-heyuan
Number of context models/DataAgents	50 each per account and per user by default; you can request an increase

Conclusion: Start with One High-Frequency Question

Back to that opening ticket. With the metric definitions configured, the next time a player asks about a top-up that never arrived, Lin no longer switches back and forth among orders, payments, delivery, and inventory. She hands the question to the DataAgent, gets evidence from three logs plus a draft reply, checks it once, and sends it to the player.

The logs in the demo are synthetic so the case is reproducible. The 13 scenarios are modeled on common customer complaints, not on any one studio's real data. Outside gaming, after-sales, risk control, and O&M have the same kind of question, the kind that takes several logs to answer, and the approach is the same. With your own logs, start with the question your team answers over and over: get the fields, glossary terms, and metric definitions right, make that one work, then decide whether to add more. Questions like this used to be answerable only by the people who understood the logs. Once the first one gets answered, the people who can answer are no longer just those few.

Try the new semantic capabilities in SLS today.