A Log Analysis Assistant Built on Lanyun MaaS Turns Scattered Errors into Actionable Fault Chains

When an application fails, the problem is often not a lack of logs, but too many logs.

A single interface error can be accompanied by database connection pool waits, SQL timeouts, gateway 500s, and cache retries happening simultaneously. Every line is speaking, but they are not speaking the same language. Manual investigation requires first filtering out anomalies, then piecing together the fragments along the timeline, request IDs, and service call relationships.

Finding ERROR is not difficult. The difficulty lies in answering: Are these errors part of the same fault chain? Which one is closer to the origin? Should you check the connection pool, slow SQL, or the gateway next? More importantly, can every judgment be traced back to the original log text?

What I wanted to verify was not "can a large model explain logs," but whether it can enter a truly usable troubleshooting workflow.

Thus, this local web tool was born: upload or paste logs, the local program preprocesses them, then calls Lanyun MaaS's qwen3.7-plus to organize scattered records into a reviewable anomaly checklist. Each anomaly comes with original text evidence, possible causes, and next-step actions, and ultimately, the raw JSON can be viewed and exported.

It should be noted in advance that the five log files used in this article are all manually written fictional test data and do not contain real accounts, hostnames, customer information, or production keys. The "possible causes" given by the tool are only troubleshooting clues and are not equivalent to confirmed root causes.

1. Define the Tool's Boundaries First: AI Provides Clues, Not Conclusions

If you simply hand logs directly to a model and ask "what's wrong," you often get a block of natural language in return. It might read as complete, but it struggles to answer three key questions:

1. Which line of the original log does the conclusion correspond to?
2. Which content is log fact, and which is just model speculation?
3. What specific investigation actions should be performed next?

So I constrained the tool's output to five parts:

• Overall summary and overall risk level;
• Anomaly type, associated service, and confidence level;
• Evidence that must be verbatim excerpts from the input log;
• Possible causes clearly marked as "speculation";
• Next-step investigation actions, repeated patterns, and missing context.

When the log has no obvious anomalies, the model should return an empty anomaly array, rather than fabricating faults just to populate the page. When the input is too long, the program will also truncate it locally and append a marker, reminding both the model and the user that the current conclusion only covers a portion of the content.

The final processing pipeline is as follows:

Upload .log/.txt/.json or paste logs
  -> Read locally and handle common encodings
  -> Preserve line numbers, extract timestamps and log levels
  -> Control the text length sent to the model
  -> Call Lanyun MaaS
  -> Validate structured JSON
  -> Display anomalies, evidence, speculation, and investigation actions
  -> View or export raw JSON

The program's homepage is kept very simple, allowing you to either select a log file or paste content directly.

2. The Model is Just Capability; Lanyun MaaS Connects That Capability into the Tool

When building a log analysis tool, the model is just one link in the chain. What truly impacts implementation are a few other things that seem less "intelligent": whether the model is easy to select, whether existing code can be integrated at low cost, whether API keys can be managed independently, and whether the cost of calling with long logs is transparent.

This is precisely why I introduced Lanyun MaaS. The Model Plaza puts different providers, model types, context lengths, and pricing information in a single console; once a model is selected, it can be embedded into applications via a unified API. For projects already using the OpenAI Python SDK, business code doesn't need to be rewritten around a proprietary SDK. Just configure the Base URL, API Key, and model name to fit the call into the existing workflow.

This time I chose qwen3.7-plus. The cost-effective Plus model in the Qwen3.7 series, it features visual understanding capabilities and a 1024k context. The log assistant currently uses its text understanding, summarization, and structured output capabilities; the visual capability leaves room for future expansion, such as analyzing monitoring screenshots or alert screenshots.

The console screenshot also provides tiered billing information. The input price is 2 RMB/M tokens, output is 8 RMB/M tokens, and cache hit input is 0.4 RMB/M tokens. For tools like log analysis where input can be lengthy, being able to see context and pricing information directly during the selection phase helps consider both capability and cost simultaneously.

API Keys can be created on the "API KEY Management" page of the Lanyun console. The console also explicitly reminds you to keep the key safe and not upload or share it publicly. My approach is to only write the Key into a local .env file; the real value never appears in the code.

So, Lanyun here is not a passive interface that just provides answers, but an intermediate layer connecting "model selection" and "application development": upfront, you can filter models by capability, context, and price; downstream, you can integrate using a familiar SDK, with keys separated from business code. The Model Plaza also has other models, leaving room for future model comparisons or adjusting selections by task. However, this article only tested qwen3.7-plus and does not evaluate other models based on this.

3. Integrating Lanyun Doesn't Require Overhauling Business Code

The project uses Flask to provide a local web page and the OpenAI Python SDK to call Lanyun MaaS. Core configuration is placed in .env:

BLUEYUN_API_KEY=Your Lanyun API Key
BLUEYUN_BASE_URL=https://maas-api.lanyun.net/v1
BLUEYUN_MODEL=qwen3.7-plus
BLUEYUN_JSON_MODE=true
MAX_LOG_CHARS=30000

Install dependencies and start the program:

python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements.txt
python app.py

Open your browser to http://127.0.0.1:5100 to use it.

Model calls are centralized in one function. Lanyun provides an OpenAI-compatible endpoint, and the actual request is sent by the SDK to /chat/completions:

client = OpenAI(
    api_key=API_KEY,
    base_url="https://maas-api.lanyun.net/v1",
    timeout=180.0,
)

response = client.chat.completions.create(
    model="qwen3.7-plus",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": f"Please analyze the following logs:\n\n{log_text}"},
    ],
    response_format={"type": "json_object"},
    temperature=0.1,
    max_tokens=4000,
)

The prompt instructs the model to analyze only based on the given logs, evidence must be verbatim excerpts, and the result is fixed into fields like summary, overall_level, anomalies, repeated_patterns, and missing_context.

The program does not display arbitrary text returned by the model as a "successful result." It first parses the JSON and checks if anomalies is an array; if the call fails, the JSON cannot be parsed, or the fields do not match the convention, the interface explicitly returns an error. This step puts the model's capability into a program-constrained workflow, rather than hiding it behind a chatbox on the page.

4. Five Log Sets, Five Questions Asked

I prepared five sets of inputs with different purposes. They respectively ask: Can known anomalies be linked into a fault chain? Will normal logs be misjudged? Can repeated errors be merged? Will ultra-long inputs expose boundaries? Can cross-service events be disentangled?

All five log sets were actually called through Lanyun MaaS's Qwen3.7-Plus. The elapsed times in the table below come from the page's running results and only belong to this specific sample, network, and runtime environment; they are not performance benchmarks.

Sample	Log Lines	Call Elapsed Time	Main Verification Point	Actual Result
Known Anomaly Baseline	8	34444 ms	Database, gateway, and cache anomalies	Output 4 anomaly types, with original text evidence preserved
INFO-only Logs	12	14725 ms	Will it forcibly fabricate faults?	No anomaly items output, judged the system as overall healthy
Repeated Error Logs	15	36450 ms	Can it merge repeated events?	Summarized as connection pool exhaustion, query timeout, and API failure
Ultra-long Logs	420	17953 ms	Length boundary and missing info prompt	No errors found in the read segment, and prompted that the log was truncated
Sanitized Production-style Logs	17	42047 ms	Multi-service event chain and structured export	Identified authentication, timeout, circuit breaker, and order failure events

1. Known Anomalies: Reconstructing a Fault Chain from Eight Log Lines

The first log set has only eight lines but simultaneously contains a database connection pool wait, two database timeouts, two /orders interface 500s, and one Redis connection retry.

The model gave an overall level of "High," with a summary pointing out that database connection pool exhaustion caused multiple database timeouts in order.service, leading to /orders interface 500s, while also observing a Redis retry. The page further broke down four types of anomalies:

• Database connection pool exhaustion;
• Database timeout;
• Interface 500 error;
• Redis connection retry.

The most important thing here is not the anomaly names, but that the evidence can be traced back to the original text. For example, the connection pool issue cited pool wait exceeded threshold wait_ms=812 active=20 idle=0, and the interface error cited two requests with route=/orders status=500. The possible causes are prefixed with "Speculation," and the investigation actions fall into specific directions like connection pool configuration, slow queries, database load, interface error rates, and circuit breaker degradation.

Below the results page, repeated patterns, missing context, and raw JSON are also displayed. The model pointed out that database timeouts were followed by /orders 500s, and further information like database slow query logs, connection pool parameters, subsequent Redis status, and traffic changes is needed.

2. INFO-only Logs: Verifying the Model's Restraint in Output

The second set has 12 lines, all INFO, covering gateway, orders, payment, cache, database connection pool, metrics reporting, and health checks. All statuses are success or normal.

The model did not generate anomaly cards just to "complete the analysis," but instead gave a low-level summary: all services are running normally, no errors or abnormal metrics, the system is overall healthy. The page elapsed time was 14725 ms.

This test set is very necessary. If a log assistant can only find problems in error samples but misinterprets normal logs as faults, it would actually create extra noise in a real workflow.

3. Repeated Errors: Merging Multiple Error Lines into Event Patterns

The third log set simulates the gradual exhaustion of a database connection pool: idle drops to 0, waiting grows from 4 to 9; the same find_orders query times out consecutively, followed by multiple /orders returning 500; finally, the connection pool recovers to idle=8, waiting=0.

The model did not break every line into a separate problem but merged them into three anomaly types: database connection pool exhaustion, database query timeout, and API request failure. It also noted the final recovery state and suggested checking the find_orders SQL execution plan and duration, database slow queries, connection pool max connections, and traffic during that period.

This kind of result is closer to actual troubleshooting needs. The user sees a correlated chain about "connection pool wait, query timeout, gateway failure," rather than a dozen disjointed error recitations.

4. Ultra-long Input: Proactively Exposing Analysis Boundaries

The fourth log set has 420 lines, with the original file being about 50,000 characters. The program added line numbers, timestamps, and level markers during preprocessing, and controlled the text length sent to the model according to MAX_LOG_CHARS=30000.

The model found no errors in the content it read: the logs were all INFO, status codes were 200, and latency was stable at 24 ms. At the same time, it explicitly pointed out in the "Missing Context" section that the log was truncated, lacking information on whether subsequent error logs exist, and also lacking logs from other services or modules to confirm the overall status.

This is exactly the boundary awareness I wanted to preserve: for a truncated partial log, the tool can summarize what it has seen, but cannot claim based on that that the full log is all normal.

5. Sanitized Production-style Logs: Identifying Cross-service Event Chains

The fifth set is a completely fictional and sanitized production-style log, totaling 17 lines. It contains two main event chains: one where the same test user is temporarily blocked after three consecutive signature verification failures; another where the inventory service first experiences high latency, then two timeouts, the circuit breaker opens, order creation fails and the gateway returns a 503, after which the circuit breaker enters a half-open state and recovers to closed.

The model output anomalies like authentication failure, service timeout, circuit breaker trigger, and order creation failure, each with log evidence preserved. Taking authentication failure as an example, the evidence includes three invalid_signature instances and temporary_block; investigation actions include checking the client signature configuration, confirming the test user's credential status, and monitoring subsequent behavior from that IP.

For the inventory chain, the model grouped high latency and two timeouts into a service anomaly, while separately identifying the circuit breaker state=OPEN, and suggested checking service health status, resource usage, network links, and dependency service logs. It must be emphasized again here: things like "high load" or "network latency or packet loss" are only possible causes to be verified and cannot be directly taken as root cause conclusions.

5. From Page Results to Processable JSON

The page display is suitable for human reading, while JSON is suitable for entering subsequent workflows. The tool retains a "View Raw JSON" area and provides an "Export JSON" button. After exporting the fifth sample, you can see that each anomaly contains fields like actions, confidence, evidence, level, possible_causes, service, and type.

Structured results mean this demo can be further expanded later, for example, pushing high-risk items to an alerting system, writing investigation actions into a ticket, aggregating historical issues by service, or adding a manual confirmation status. This article did not implement these features, but the current output is no longer limited to a one-off chat answer.

6. Looking Back, Lanyun's Value Falls on Three Specific Points

After running the five samples and looking back, Lanyun's value doesn't just happen in the few seconds of "sending a request, receiving an answer," but falls on three specific points: selection, integration, and operation.

• During selection, the Model Plaza puts capability labels, context length, and pricing on the same interface;
• During integration, the OpenAI-compatible endpoint allows the existing Python SDK to directly enter the project;
• During operation, qwen3.7-plus handles log semantic understanding, anomaly merging, and structured output.

At the same time, the responsibilities of the local program and the model service are kept separate:

• The local program is responsible for file reading, encoding compatibility, log numbering, length limiting, JSON validation, page display, and result export;
• Lanyun MaaS's qwen3.7-plus is responsible for understanding log semantics, merging anomalies, extracting evidence, and generating possible causes and investigation actions.

This division of labor is very important. Lanyun provides model capability and a stable integration method, the program constrains input and output, and the human is responsible for confirming the root cause. Only when these three keep their boundaries can the model's semantic understanding avoid becoming an un-auditable long answer.

The five real-world tests also indirectly validated this combination: anomalous logs can form an investigation chain, normal logs weren't forcibly fabricated into faults, repeated logs can be merged, ultra-long logs expose incomplete information, and complex logs can be split by service and event. For developers looking to embed large models into existing tools, what Lanyun shortens is precisely the distance from "selecting a model" to "letting it enter the business process."

Conclusion

Let's go back to those 8 log lines at the beginning.

They were originally just a connection pool wait, database timeout, gateway 500, and Redis retry. After local preprocessing and analysis by Lanyun MaaS, they were organized into an actionable path: what the anomaly is, where the evidence is, what is just speculation, what to check next, and what information is still missing.

This time, leveraging Lanyun MaaS's qwen3.7-plus, I turned this path into a practically runnable log analysis assistant. It can organize fault chains from a small number of errors, show restraint with normal logs, and output structured JSON that is easy to view and further process.

My impression of Lanyun MaaS also lands here: it puts model capability, context and pricing information, API integration, and key management into one platform, allowing developers to put their energy back into the problem itself, rather than stopping at interface adaptation and one-off demos.

Log troubleshooting doesn't require a large model to replace the engineer. As long as it can leverage Lanyun to organize scattered logs into reviewable troubleshooting clues with evidence, boundaries, and verifiability, this combination has already found its place.