Intelligent log inspection

Advantages

Intelligent log inspection converts massive log volumes into reviewable problem signals through periodic analysis, automatic drill-down, and continuous tracking:

1. Proactive detection of undefined changes — Continuously identifies new log patterns, distribution shifts, metric spikes, and long-tail anomalies without requiring preconfigured error codes, keywords, or fixed thresholds.

2. Designed for massive log analysis — Performs log clustering, baseline comparison, and dimension drill-down on the data side using overall distributions as the basis, reducing the risk of sampling omission and local sample misjudgment.

3. Automatic problem scope convergence — The Agent dynamically selects follow-up queries based on analysis results, progressively pinpointing from anomaly signals to specific service, version, region, and user dimensions while preserving comparison baselines and query evidence.

4. Continuous tracking with reduced noise — Updates problem status on each cycle, distinguishing new, worsening, recurring, and recovered issues. Uses confirmed business semantics and known noise to optimize subsequent inspections, notifying only when noteworthy changes occur.

5. Knowledge injection and multi-source analysis — Supplements business rules, domain expertise, and troubleshooting methods through Skills. Describes entity relationships and field semantics through UModel, enabling the Agent to correlate logs, metrics, traces, and other multi-source data for comprehensive analysis.

Prerequisites

Before you begin, make sure that the following conditions are met:

• You have query permissions for the target Project and Logstore.

• Indexing is enabled for the Logstore, and you can query logs normally.

• The logs contain fields suitable for analysis, such as status, request_time, request_uri, region, or version.

• Comparable data exists within the log time range. A newly created Logstore or one with insufficient data volume may not form an effective baseline.

• If you need to receive notifications, prepare a contact, bot, or Webhook as the Notification Recipient.

• Intelligent log inspection is powered by STAROps. The page clearly indicates that usage incurs fees. Set the execution cycle based on actual needs.

This guide uses the charts-demo/charts-demo Logstore in the China (Shanghai) region as an example. The sample logs are Nginx access logs containing fields such as status, request_time, and request_uri.

Enter intelligent log inspection

1. Log on to the Simple Log Service console and navigate to the target Project.

2. In the Logstore list on the left side, select the target Logstore.

3. On the query and analysis page, confirm that logs can be queried normally within the current time range.

4. In the query results area, switch to the Intelligent Inspection tab.

After entering the tab, the page displays existing inspection tasks for the current Logstore. Task cards show the task name, creator, last update time, and recent execution records. Do not directly modify tasks created by others. To try the feature, create an independent task with a clear test identifier.

Create an inspection task

1. In the intelligent inspection task list, click Create Task.

2. Enter a task name. Include both the business scope and log type, for example, "Payment Gateway Nginx Log Inspection".

3. Set the schedule. The page supports hourly execution with a specified minute within each hour.

4. Select the digital employee to execute the task.

5. Enter the inspection requirements. For initial creation, you can write only the most important goals. The system generates an initial plan based on log characteristics.

6. (Optional) Select a contact, bot, or Webhook. You can create the task without a Notification Recipient and configure one later.

7. Review the fee notice and click Create Now.

After creation, the new task appears at the top of the list. A newly created task shows "No execution records yet", which is expected.

First run and view inspection results

Click a task card to open the STAROps long-running task details page in a new browser tab.

The details page provides three core tabs:

• Conversation — View the task planning process, supplement business semantics, or submit new drill-down requirements.

• Executions — View periodic execution records or manually trigger an execution on demand.

• Reports — View reports generated after an inspection completes.

When a new task has not yet completed its first execution, the counts for Executions and Reports are 0. After the first execution completes, navigate to the corresponding tabs to view analysis scope, query evidence, anomaly dimensions, findings, and uncertainty statements.

Modify a task

Supplementary inspection requirements: treat /healthz as health check traffic;
also focus on upstream_response_time,
and whether anomalies are concentrated on specific source addresses or User-Agents.

How to read an inspection report

After a report is generated, review the following items in order:

1. Analysis scope — Verify that the current window, comparison window, and actual query scope match expectations.

2. Inspection plan — Check which metrics, fields, and log patterns were actually inspected in this cycle.

3. Problem conclusions — Determine whether new anomalies, worsening issues, recurring problems, or scope expansion were detected.

4. Data evidence — Identify which log queries, clustering results, or dimension drill-down results support the conclusions.

5. Impact scope — Determine whether problems are concentrated on specific URIs, status codes, source addresses, versions, or other dimensions.

6. Uncertainty — When data is insufficient, baselines are not comparable, or fields are missing, the report explains what cannot currently be confirmed.

Metric changes do not necessarily indicate a failure. For example, an increase in slow-endpoint traffic share pushes up the overall p90, but individual endpoint performance may not have degraded. Combine dimension drill-down results to determine whether a change represents performance degradation or traffic composition change.

Notification configuration

The inspection cycle and notification frequency are separate concerns. A task can execute hourly, but normal results do not need hourly notifications.

Send notifications only in the following situations:

• A new high-risk problem is discovered.

• An existing problem has significantly worsened.

• A recovered problem recurs.

• The impact scope has significantly expanded.

• Manual confirmation of business semantics or remediation approach is needed.

If no Notification Recipient was selected during creation, you can navigate to notification management from the task settings page and add a contact, bot, or Webhook later.

Use custom Skills to improve inspection quality

For log scenarios with well-defined business semantics, specialized fields, or established troubleshooting practices, you can create custom Skills to provide team knowledge to the digital employee executing the inspection. This improves the accuracy, consistency, and reviewability of inspection results.

Include the following content in custom Skills:

1. Field and status semantics — Define the meaning of business error codes, status fields, versions, regions, tenants, and user identifiers.

2. Normal behavior and known noise — Define health checks, stress testing traffic, bot requests, scheduled tasks, and other issues that do not require escalation, along with their applicable scope.

3. Anomaly detection methods — Specify key metrics for comparison, baseline windows, clustering fields, and anomaly dimensions.

4. Drill-down troubleshooting procedures — Codify commonly used query statements, diagnostic sequences, correlation conditions, and root cause confirmation methods as standard steps.

5. Reporting and evidence requirements — Specify the time ranges, comparison data, query evidence, uncertainty statements, and follow-up actions that reports must include.

Custom Skills in STAROps are written in Markdown. Skill design can include reference materials in a references/ directory and helper scripts in a scripts/ directory, in addition to the SKILL.md instructions. After creation, no installation is required. You can associate the skill with the digital employee that executes log inspection in the usage scope settings.

Create a draft first and enable Use Draft only for the testing digital employee. Run a manual inspection to verify field understanding, query scope, and report results. After confirming accuracy, publish the official version for all associated digital employees.

Entry point: STAROps console > Skills > Custom > create a custom Skill.

For detailed instructions on creating custom Skills, see Skill Center.

Continuous optimization suggestions

• After the first run, confirm that the data scope, field identification, and baseline are correct.

• Communicate business error codes, field meanings, and normal behavior to the inspection Agent.

• Mark health checks, stress testing, bot requests, and other known noise, specifying their applicable scope.

• Supplement root cause and remediation experience for real problems so subsequent inspections can reference them.

• Set notifications to trigger on problems only, avoiding repeated disruptions to on-call personnel during normal cycles.

• After changes to log structure, version fields, or business goals, re-verify the inspection plan.

FAQ