About this skill

Problem

When debugging test or production incidents, engineers often query SLS with expressions like txId="xxx" or message~="error", page through results, filter ERROR/WARN entries, and manually reconstruct the request path. This skill reduces that repeated SLS log workflow to a /sls-query action that returns structured JSON.

How It Works

It calls {apiBase}/api/sls/query with a query statement and environment. Environments are test and prod; when unspecified, test is used. Pagination uses a fixed maxLines of 100, starts at pageNum 1, and stops when hasNext is false or 10 pages are reached.

Each run prints a summary: environment, query statement, total logs, ERROR/WARN counts, _container_name_, plus the first five ERROR and first three WARN entries. The summary is printed with console.error(), while the full JSON is printed with console.log().

Useful signals:
- Request path: message and _container_name_
- Abnormal nodes: logLevel equals ERROR or WARN
- Thread context: thread_name
- Inputs and outputs: request or response in message

Boundaries

It assumes access to the existing SLS query API and is intended for quick summaries and anomaly context, not a full log platform replacement. It retrieves at most 1000 entries, so narrow time, service, or query conditions first when logs are large. Production data is sensitive, so confirm the environment is prod before interpreting summaries.

Screenshots

Use Cases

Debug a test API failure by querying SLS logs with a txId and reviewing the first five ERROR entries.
After a production release, search logs with message~=error to check for new ERROR entries.
Track a stuck async task by locating its thread and service using thread_name and _container_name_.
Review request context by extracting request and response fields from the message content.

Best For

Backend engineers: tracing a txId across service logs and abnormal entries.
SRE or ops engineers: quickly reviewing ERROR and WARN summaries in test or production.
QA engineers: verifying whether error logs decrease or appear after a release.
On-call engineers: locating container, thread, and request/response context for incidents.