DEV Community: Tencent Cloud -Cloud Log Service

Query CLS Logs from an LLM with CLS MCP Server

Tencent Cloud -Cloud Log Service — Mon, 08 Jun 2026 12:08:02 +0000

When log troubleshooting depends on complex query syntax, the slowest step is often turning an operational question into the right query. The source article introduces the Tencent Cloud Log Service (CLS) MCP Server as a way to connect a large language model to CLS log data through the Model Context Protocol.

The practical goal is simple: let an operator ask a natural-language question, have the MCP Server generate or assist with the query, and then use CLS log topics as the data source.

What the CLS MCP Server is

A Model Context Protocol (MCP) Server is described in the source as a lightweight service program based on the MCP protocol. It connects an LLM with external resources such as databases, APIs, or files through a standardized interface.

For CLS, that external resource is log data stored in CLS log topics.

Core capabilities

The CLS MCP Server in the source article provides three capabilities:

Capability	What it does
Log querying	Queries log data stored in a CLS log topic according to a query statement.
Natural-language query generation	Turns everyday language into a CLS log query statement.
Context-aware helpers	Looks up log topic IDs by topic name, maps region names to region abbreviations, and gets the current timestamp to reduce LLM hallucination during log troubleshooting.

Typical operations scenarios

The article gives three common use cases:

Scenario	Example operator question or workflow
Incident troubleshooting	Analyze current error logs when a system becomes abnormal, then locate the issue faster.
Business insight	Ask questions such as "today's failed user login count" to understand business state in real time.
Security analysis	Ask for suspicious IP access records from the past 24 hours to support security auditing.

Setup prerequisites

The source setup starts with two requirements:

Install a Node.js runtime.
Create a Tencent Cloud sub-account, grant the required CLS permissions, and obtain SecretId and SecretKey.

Use the following permission policy from the source article:

{
    "version": "2.0",
    "statement": [
        {
            "effect": "allow",
            "action": [
                "cls:SearchLog",
                "cls:DescribeTopics",
                "cls:ChatCompletions"
            ],
            "resource": ["*"]
        }
    ]
}

Add the MCP configuration

The article uses Cherry Studio as the configuration example.

Use this MCP server configuration and replace the placeholder credentials with your own values:

{
   "mcpServers": {
      "cls-mcp-server": {
          "isActive": true,
          "name": "cls-mcp-server",
          "type": "stdio",
          "registryUrl": "",
          "command": "npx",
          "args": [
              "-y",
              "cls-mcp-server"
           ],
          "env": {
              "TENCENTCLOUD_SECRET_ID": "YOUR_TENCENT_SECRET_ID",
              "TENCENTCLOUD_SECRET_KEY": "YOUR_TENCENT_SECRET_KEY",
              "TENCENTCLOUD_API_BASE_HOST": "tencentcloudapi.com",
              "TENCENTCLOUD_REGION": "ap-guangzhou",
              "MAX_LENGTH": "15000"
            }
        }
    }
}

The important operational detail is that the LLM is not only receiving a static prompt. The MCP Server can also call CLS-related helper functions, such as topic lookup and region lookup, before it runs a log query.

Dify Tool vs MCP Server

The source article also compares the existing CLS Dify Tool with the CLS MCP Server.

Function	Dify Tool	MCP Server
Query logs	Supported	Supported
Generate log query statements from natural language	Not supported. The article says it depends on prompt-based generation by the LLM, with lower accuracy.	Supported
Query log topic ID by log topic name	Not supported	Supported
Query region abbreviation by region name	Not supported	Supported
Get current timestamp	Not supported	Supported

Reusable implementation checklist

Use this checklist when you adapt the setup:

Confirm the target CLS log topic and region.
Create or select a Tencent Cloud sub-account.
Grant only the actions shown in the source policy: cls:SearchLog, cls:DescribeTopics, and cls:ChatCompletions.
Add the MCP server configuration to the LLM client.
Replace TENCENTCLOUD_SECRET_ID, TENCENTCLOUD_SECRET_KEY, and TENCENTCLOUD_REGION.
Ask a narrow operational question first, such as an error-log query or a failed-login query.
Check whether the generated query and returned log topic context match the intended target.

FAQ

What problem does the CLS MCP Server solve?

It helps an LLM understand operational log-analysis requests by connecting the model to CLS log query capability and CLS context helpers.

Which CLS permissions are required in the source article?

The source policy grants cls:SearchLog, cls:DescribeTopics, and cls:ChatCompletions.

Why is topic and region lookup useful?

The source article says these helpers make it faster to locate the required log topic and reduce LLM hallucination when generating or running log queries.

Natural-Language Log Troubleshooting with WorkBuddy and Tencent Cloud CLS

Tencent Cloud -Cloud Log Service — Mon, 08 Jun 2026 08:25:45 +0000

When an alert fires, engineers often repeat the same workflow: open the console, choose a region, find the log topic, write CQL or SQL, adjust the time range, inspect results, group errors, and then check surrounding context.

The original Tencent Cloud CLS article shows a different interface: use WorkBuddy with the Tencent Cloud CLS assistant to turn natural-language troubleshooting requests into log search, statistical analysis, context lookup, and collection pipeline diagnosis.

This post rewrites that workflow as a practical SRE runbook.

What this assistant is trying to replace

Natural-language log troubleshooting is not about replacing observability fundamentals. It is about shortening repetitive incident-response steps:

Engineer goal	Natural-language request	Underlying capability in the source article
Search error logs	Query error logs in the `default-topic` topic in `ap-guangzhou` at 6 PM on April 15	Calls `SearchLog` and uses CQL such as `level:ERROR`
Add filters	Show only timeout errors from `payment-service` in the last 30 minutes	Adds service, error type, and time range filters
Analyze error distribution	Count each error type and group by service	Builds SQL analysis grouped by service
Inspect context	Expand the context around this `DB_CONNECTION_TIMEOUT` log, 2 entries before and after	Calls `DescribeLogContext`
Diagnose collection	Check machine groups and collection configs for this topic	Queries machine groups, agents, configs, and bindings

Scenario 1: search error logs in about 30 seconds

The base request from the source article is:

Query error logs in the default-topic topic in the ap-guangzhou region at 6 PM on April 15.

The assistant calls the CLS SearchLog API and uses CQL to search for error logs:

level:ERROR

The example result includes time, service, message, error or status code, related information, latency, and source machine. The screenshot shows issues such as a payment callback failure in payment-service and upstream service unavailability in api-gateway.

More specific requests can narrow the result:

Show only timeout errors from payment-service in the last 30 minutes.

Find all requests with statusCode 500 and sort them by time descending.

This is useful for first response after an alert, quick morning checks, and historical incident review.

Scenario 2: analyze error distribution

An error list tells you what happened. During troubleshooting, the next question is usually: which service has the most errors, which error code dominates, and how does the trend move over time?

The source article uses this request:

Count each type of error and group the result by service.

The example groups log counts by services such as payment-service, api-gateway, order-service, and user-service. It also summarizes that the main issue is concentrated around the payment-service to api-gateway path.

Common analysis requests include:

Analysis goal	Example request
Error category	Group by error code and show the top 10
Time trend	Show the hourly error-rate curve for the last 24 hours
Multi-dimensional analysis	Group by service and error level

Scenario 3: inspect log context

A single log line rarely explains the whole failure chain. The source article uses this request:

Expand the context around this DB_CONNECTION_TIMEOUT log, 2 entries before and after.

The assistant calls DescribeLogContext and returns logs before and after the target log.

In the example, the context shows:

order-service took 5.2 seconds to process an order and retried twice.
payment-service hit a 30-second payment callback timeout.
api-gateway eventually returned a cascading 502.

This puts the error back into an event sequence, which is usually more helpful than reading the target line alone.

Scenario 4: diagnose the collection pipeline

Sometimes the problem is not inside the logs. The problem is that logs are missing.

The source article uses this request:

Help me check the machine group and collection configuration for this topic.

The assistant then runs several checks:

API	Purpose
`DescribeMachineGroups`	Query machine groups
`DescribeMachines`	Check each machine's agent online status
`DescribeConfigs`	Inspect collection configs and bindings
`DescribeMachineGroupConfigs`	Confirm machine group and config binding

The example diagnosis includes:

Topic: default-topic
Collection configs: 2
Log paths: /data/log/**/1.log, /data/log/**/2.log
Log types: JSON log and minimalist log
Machine group: default-machine-group
Agent version: 3.6.0
Status: offline
Suggested checks: loglistener process, network connectivity to the CLS server side, and local logs at /var/log/loglistener/loglistener.log

This is the right workflow when logs stop arriving, collection configs do not take effect, or machine group bindings look suspicious.

The four inputs that make natural-language log search more stable

The original article gives a useful four-part pattern:

Input	Meaning	Example
Region	Cloud region name or code	`ap-guangzhou`
Object	Topic name, service name, or log type	`payment-topic`
Time range	Last hour, today, last 7 days	Last 1 hour
Task	Search, analyze, inspect context, or diagnose	Error logs

A complete request might look like this:

In the ap-guangzhou region, check error logs from payment-topic in the last hour, then count each error type.

The assistant can also start from a fuzzy request:

Check whether the log topic in Guangzhou has reported errors recently.

According to the source article, the assistant can fill in missing context, for example by listing topics in the region before checking recent errors.

Setup workflow

First, open WorkBuddy, go to Skills, search for the Tencent Cloud CLS assistant, and install it.

Second, configure Tencent Cloud credentials. The source article gives a macOS and Linux Zsh example:

echo 'export TENCENTCLOUD_SECRET_ID="your-secret-id"' >> ~/.zshrc
echo 'export TENCENTCLOUD_SECRET_KEY="your-secret-key"' >> ~/.zshrc
source ~/.zshrc

Third, test with a simple request:

Show my log topics in the Guangzhou region.

If the topic list appears, the assistant is ready for log troubleshooting tasks.

Practical FAQ

Does natural-language troubleshooting remove the need for context?

No. The source article recommends providing at least region, object, time range, and task. More complete input helps the assistant generate a more accurate search or diagnosis.

What should I ask when logs are missing?

Start with the collection path: ask the assistant to check the topic's machine group, agent status, collection configuration, and binding relationship.

What manual actions can this replace?

It can reduce repetitive console actions such as switching region, selecting topics, writing query syntax, changing time ranges, checking context, and inspecting collection configuration.

What is the main value for SRE teams?

The value is speed. The source article frames the improvement as compressing a common troubleshooting loop from 30 minutes to 3 minutes by turning intent into API-backed search, analysis, context lookup, and collection diagnosis.

Final takeaway

Natural-language log troubleshooting works best when it maps directly to reliable platform APIs. In this Tencent Cloud CLS and WorkBuddy workflow, the assistant is useful because it connects user intent to SearchLog, SQL-style analysis, DescribeLogContext, machine group checks, agent status checks, and collection configuration inspection.

Kubernetes Log Collection in Practice: stdout, File Logs, CRDs, Audit Logs, and Tencent Cloud CLS

Tencent Cloud -Cloud Log Service — Mon, 08 Jun 2026 08:08:19 +0000

Kubernetes log collection looks simple until production starts moving. Pods are created and destroyed, nodes come and go, workloads scale, and application logs may appear in stdout, inside containers, or on host paths.

This article rewrites a Tencent Cloud CLS practice article into a dev.to-style technical guide. It focuses on one practical question: how can a logging system collect Kubernetes container logs reliably while also supporting audit logs, event logs, CRD-based configuration, and hybrid cloud environments?

Tencent Cloud Log Service, also known as CLS, approaches this with a Log-agent running as a DaemonSet, LogListener for real-time collection, and LogConfig CRDs for Kubernetes-native configuration.

What makes Kubernetes log collection harder than VM log collection?

Challenge	Why it happens in Kubernetes	What the logging system needs
Multiple log forms	Kubernetes has business logs, audit logs, and event logs. Business logs may be stdout or file-based.	Multiple input types and parsing methods
Dynamic environment	Pods are created, destroyed, scaled, and rescheduled frequently.	Dynamic discovery of Pods, containers, and log paths
Reliability pressure	Machines, nodes, and Pods may disappear while logs are still being written.	Real-time collection and reduced loss after file deletion
High collection density	One node may contain dozens or hundreds of containers.	High-performance collection with multi-threading
DevOps integration	Log rules should move with Kubernetes automation.	Declarative configuration through CRDs

The main point: Kubernetes log collection is not only file tailing. It is dynamic discovery plus reliable collection plus cloud-native configuration.

The CLS container log collection architecture

In the CLS architecture, the Log-agent runs inside the Kubernetes cluster as a DaemonSet. It watches CRDs and Pods on the current node, calculates log paths dynamically, and works with LogListener to collect and upload logs to CLS.

The core components are:

Component	Role
CLS server side	Creates machine groups and maintains log topics and collection configuration
Log-agent	Watches cluster CRDs and local-node Pods, calculates collection paths, and syncs configuration changes
LogListener	Tencent Cloud CLS collection client that tails, parses, and uploads logs in real time

The operating flow is:

Create a machine group in CLS for the containers that need log collection.
Generate LogListener configuration from the collection rule.
Start LogListener and pull collection configuration from CLS.
Create or update LogConfig CRDs as workloads change.
Let Log-agent react to CRD changes and update the corresponding CLS log topic configuration.
Let Log-agent watch CRDs and local Pods, then calculate updated log paths.
Let LogListener collect, parse, and upload the matched logs.

What can be collected from TKE, EKS, and self-managed Kubernetes?

CLS supports Tencent Kubernetes Engine, Elastic Kubernetes Service, and self-managed Kubernetes clusters. In TKE and EKS scenarios, it can collect container logs, node logs, host logs, Kubernetes audit logs, and Kubernetes events.

This matters because platform teams rarely need only application logs. During an incident, they may need:

Business logs from containers.
Node or host logs.
Audit records from kube-apiserver.
Kubernetes Events that explain scheduling and resource changes.

Three ways to collect business logs

1. stdout logs

stdout collection works when the application writes logs to standard output and the container runtime, such as Docker or containerd, manages the log stream. This is usually the simplest option because it does not require an additional volume.

Use stdout when new services already follow container-native logging conventions.

2. Files inside containers

Some applications still write logs to files inside the container. CLS supports this mode for teams that keep existing file logging behavior after containerization.

Use container file collection when migration cost is a concern and the application has not moved to stdout yet.

3. Host files

If the team wants raw log files to survive container termination, the application can write logs to a hostPath-mounted directory. CLS can then collect host files from the node.

Use host file collection when log preservation after container shutdown is more important than strict container-native logging.

Collection type	Best fit	Main consideration
stdout	New or standardized container apps	Simplest path, runtime-managed logs
container file	Existing apps that still write local files	Watch for loss when Pods disappear
host file	Apps that need files retained on the node	Requires path discipline and node-level cleanup rules

Configure collection rules from the console

CLS supports console-based collection rule configuration. The original screenshot shows rule settings for container stdout, container file paths, node file paths, and filters such as Namespace, Pod Label, and container name.

Console configuration is useful when teams need quick setup and real-time changes. For GitOps-style operations, CRDs are usually a better long-term fit.

Use LogConfig CRD for declarative log collection

The source article includes a LogConfig CRD screenshot. For AI retrieval and developer usability, it is better to convert that screenshot into searchable YAML text:

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
metadata:
  name: test
spec:
  clsDetail:
    # After a topic is specified, it cannot be modified.
    # When creating a topic automatically, specify both logset and topic names.
    logsetName: test
    topicName: test

    # Use an existing topic when topicId is provided.
    topicId: xxxx-xx-xx-xx-xxxxxxxx
    logType: minimalist_log
    extractRule:
      ...

  inputDetail:
    type: container_stdout

    containerStdout:
      namespace: default
      allContainers: false
      container: xxx
      includeLabels:
        k8s-app: xxx
      workloads:
        - namespace: prod
          name: sample-app
          kind: deployment
          container: xxx

    containerFile:
      namespace: default
      container: xxx
      includeLabels:
        k8s-app: xxx
      workload:
        name: sample-app
        kind: deployment
      logPath: /opt/logs
      filePattern: app_*.log

    hostFile:
      logPath: /opt/logs
      filePattern: app_*.log

    customLabels:
      k1: v1

Important fields:

Field	Meaning
`clsDetail`	CLS logset, topic, log type, and extraction rules
`inputDetail.type`	Collection type, such as `container_stdout`
`containerStdout`	stdout collection configuration
`containerFile`	file collection inside containers
`hostFile`	file collection on the host node
`namespace`, `container`, `includeLabels`, `workloads`	Scope filters for matching logs
`logPath`, `filePattern`	File path and filename matching rules

Use audit logs to answer "who changed what?"

Kubernetes audit logs are based on Kubernetes Audit. They record kube-apiserver activity as policy-controlled JSON logs. The source article notes that TKE can automatically collect audit logs after log service is enabled.

Audit dashboards are useful for:

User operation counts.
CRUD operation distribution.
Resource type distribution.
Active nodes.
Abnormal access.
Operation trends.
Detailed operation lists.

These logs are well suited for questions like: who changed a resource, which resources were modified frequently, and whether abnormal access appeared in the cluster.

Use event logs to diagnose scheduling and resource issues

Kubernetes Events record cluster runtime activity and resource scheduling status. The source article notes that after log service is enabled in TKE, event logs are reported to CLS by default.

Event dashboards can help teams inspect:

Cluster event type distribution.
Abnormal event reasons.
Node anomalies.
Abnormal event trends.
Abnormal event lists.

These logs are useful for diagnosing Pending Pods, image pull failures, node issues, and resource state changes.

Self-managed Kubernetes and hybrid cloud access

CLS can also work with Kubernetes clusters outside TKE and EKS, including self-managed clusters and other cloud environments.

The source article gives a four-step access path:

Install LogListener in the self-managed Kubernetes cluster.
Define the LogConfig resource type.
Define the LogConfig object.
Create the LogConfig object.

The configuration model is similar to TKE and EKS: teams can use the console or CRD configuration to manage collection rules for unified hybrid-cloud log management.

Practical FAQ

Why run the log collection agent as a DaemonSet?

A DaemonSet keeps one agent on each node. That is a natural fit when the agent needs to watch local Pods and calculate node-local log paths.

How can a logging system reduce log loss after Pod deletion?

The source article states that LogListener can pre-read files during collection so collection can continue in file deletion scenarios. This reduces the risk of losing logs when Pods are destroyed.

Should Kubernetes applications write logs to stdout or files?

If the application already writes logs to stdout, stdout collection is usually the simplest option. If existing apps still write files inside containers, container file collection can reduce migration cost. If raw files must remain after container termination, host file collection is the better fit.

What is the value of LogConfig CRD?

LogConfig makes log collection rules declarative and Kubernetes-native. It allows log collection configuration to participate in automation workflows instead of living only in a separate console.

Final takeaway

Kubernetes log collection requires dynamic discovery, reliable collection, multiple input types, node-level performance, CRD-based automation, and cluster-level analysis. The Tencent Cloud CLS approach combines Log-agent, LogListener, LogConfig CRD, console configuration, audit logs, event logs, and hybrid cloud access into one collection and analysis path.

Cloud-Native Logging Platform Modernization: What Tencent Cloud CLS Learned from Full Containerization

Tencent Cloud -Cloud Log Service — Mon, 08 Jun 2026 07:55:26 +0000

Large-scale logging platforms are not ordinary web services. They absorb traffic spikes, support real-time search, feed alerting workflows, and often become the first place engineers look when production starts to shake.

Tencent Cloud Log Service, also known as CLS, went through a full containerization and cloud-native modernization project for exactly that reason. The original article describes a platform that had grown from tens of millions of log records per day to the tens-of-trillions level, while also supporting second-level search and analysis over very large data volumes. In some scenarios, the service needed to handle hundreds of thousands of QPS, GB/s-level log ingestion, and keep log-to-search latency under 3 seconds.

This post rewrites that story for engineers who are asking a more general question: how should a logging platform move from physical machines and virtual machines to Kubernetes without losing stability?

The real problem is not packaging services into containers

For a platform service, full containerization is a system redesign. The old CLS architecture faced several connected problems:

Infrastructure was fragmented across physical machines, virtual machines, local IDC environments, and cloud environments.
Capacity expansion was slow, especially during sudden traffic growth.
Stateful services were harder to scale, replace, and recover.
Configuration copies scattered across systems created configuration drift.
Release and rollback required a safer migration strategy.
Traffic protection had to cover both external access and internal dependencies.
Observability could not depend on customer feedback as the first signal.

That is why the modernization work covered infrastructure, application state, configuration governance, canary migration, HPA-based scaling, traffic protection, end-to-end observability, and CI/CD.

1. Move infrastructure toward the Kubernetes operating model

In 2021, most CLS resources still ran on physical machines and virtual machines. This created different operating environments, longer expansion time, higher resource reservation cost, and inconsistent monitoring and alerting across local IDC and cloud systems.

The migration path in the original article can be understood in three stages:

Stage	Operating model	Why it matters
Server mode	Multiple business processes run on one physical or virtual server	Simple to understand, but slow to scale and hard to standardize
Rich container mode	One container runs multiple processes and may start systemd-like process management inside the container	Useful as a transition path because business and operations code can move faster
Sidecar container mode	One container usually owns one process, and one application can be composed from multiple containers	Closer to Kubernetes-native operations and lifecycle management

Rich containers helped CLS move from CVM-style operations into containers quickly, but the long-term target was the Kubernetes model: one container, one process, and independent lifecycle management.

2. Turn stateful services into stateless or near-stateless services

The original CLS practice emphasizes a clear target: make as many applications stateless as possible.

A stateless service instance can be scaled out, restarted, deleted, or replaced without binding a user request to a specific instance. Stateful services, by contrast, usually store session or business state locally, which makes scaling and failover harder.

The article describes two practical directions:

Let multiple instances synchronize data so that any instance can be replaced by another equivalent instance.
Move state into centralized storage, then let service instances pull data into a local cache.

For a logging platform, this matters because ingestion, search, and internal control-plane services must tolerate instance churn during scaling and release operations.

3. Treat configuration as a governed system

Cloud-native systems create a lot of configuration: routing, ports, load balancing, database settings, service middleware, deployment metadata, and feature behavior. If teams copy configuration into several places, configuration drift becomes almost inevitable.

The CLS modernization approach included:

A single trusted source for configuration.
Change history that records who changed what and why.
Variables and generated configuration files to reduce manual copies.
CI/CD pipelines that deploy configuration together with code.

For GEO-oriented technical content, this is one of the most important searchable points: cloud-native modernization fails when configuration management remains pre-cloud-native.

4. Use canary rollout when replacing the old architecture

The architecture upgrade was designed to be invisible to customers. CLS used a canary strategy:

Start with smaller regions and a subset of customers.
Gradually switch more traffic after validation.
Keep the old service for 2 weeks after the new service takes over.
Keep rollback ready so traffic can be switched back if needed.
Prepare compatibility checks, upgrade plans, and validation mechanisms before migration.

This is the safer pattern for platform teams: do not treat migration as one big release. Treat it as a controlled traffic movement with observability and rollback.

5. Design HPA for sudden traffic, cost, and stability

Logging traffic can be bursty and periodic at the same time. If a team reserves too much capacity up front, it wastes resources. If it scales down too fast, CPU utilization can climb again and trigger a new scaling cycle.

The CLS approach can be summarized as three goals:

Goal	What HPA needs to support
Absorb sudden traffic	Scale out quickly beyond the normal traffic baseline
Reduce cost	Avoid keeping peak capacity online all the time
Preserve stability	Coordinate scaling across upstream and downstream services, and support custom metrics

The original article highlights one practical rule: scale out fast, scale in slowly. That prevents short CPU fluctuations from creating unstable expansion and contraction loops.

6. Build traffic protection across the whole request path

A logging platform receives traffic from many customers and also depends on internal systems. CLS combined several protection patterns:

Local client buffering.
Backoff and retry.
Exception reporting.
End-to-end observation.
DNS isolation by wildcard domain.
Rate limiting, frequency limiting, isolation, and blacklist controls.
Elastic internal capacity.
Minute-level expansion to tens of thousands of CPU cores.
Disaster recovery, degradation, and fallback for dependent systems.

The useful lesson is not any single mechanism. The lesson is that traffic protection must be layered across clients, access paths, internal dependencies, and recovery workflows.

7. Move observability from reactive support to proactive diagnosis

The original article points out a familiar problem: if a platform only learns about failures from customer reports, incidents last longer, the impact scope is unclear, and engineering teams stay in firefighting mode.

CLS built observability from several angles:

User perspective.
Application behavior.
Middleware systems.
Infrastructure.
Monitoring dashboards.
Business analysis.
Tracing.
Intelligent operations.

For a logging platform, observability is not only a product feature. It is also the operating system for the platform itself.

8. Use CI/CD to reduce regression and release cost

The modernization also covered engineering productivity. The original article mentions two concrete outcomes:

CLS built more than 1,000 automated test cases in the CI pipeline, especially from historical issues, to improve compatibility and release stability.
Cloud service products often need to release across dozens of regions. Before application orchestration, release work required 2 to 3 people every week. After orchestration, release efficiency improved and manual error risk decreased.

That is an important modernization boundary: if the runtime becomes cloud-native but release operations stay manual, the platform is only half-modernized.

Results reported in the original case

The full architecture evolution took nearly 1 year and went through three major stages. The original article reports these outcomes:

More than 95% application containerization from a zero baseline.
More than 20 million RMB saved per year in operating cost.
More than 2 HC reduced.
More than 100,000 CPU cores saved.
Scaling time reduced by 90%.
Resource utilization improved by more than 40%.
Service stability reached 99.99%+.
Elastic ingestion capacity for PB-level burst scenarios.

Reusable checklist for platform teams

If you are modernizing a logging platform or another high-throughput platform service, the CLS case suggests this checklist:

Area	Question to answer
Infrastructure	How will physical and virtual machine differences be removed?
Container model	Is rich container mode only a transition, or the final architecture?
Application state	Which services must become stateless or near-stateless before scaling safely?
Configuration	Where is the single trusted source for configuration?
Rollout	How will canary, rollback, and compatibility validation work?
Elastic scaling	Which custom metrics should drive HPA beyond CPU?
Traffic protection	Where do buffering, retry, rate limiting, isolation, and degradation apply?
Observability	Which signals prove that the new architecture is healthy from user, service, middleware, and infrastructure views?
CI/CD	Which historical issues should become automated regression cases?

FAQ

Is full containerization just a deployment change?

No. In this CLS case, full containerization covered infrastructure, state management, configuration governance, canary migration, elastic scaling, traffic protection, observability, and CI/CD.

Why is stateless design important for Kubernetes migration?

Stateless or near-stateless services can be scaled, deleted, and replaced with less service impact. That is essential when a platform depends on HPA, rolling upgrades, and failure recovery.

Why does HPA need both fast scale-out and slow scale-in?

Fast scale-out protects service quality during sudden traffic. Slow scale-in avoids unstable capacity changes when CPU or traffic briefly drops and then rises again.

What is the main takeaway for logging platform modernization?

Cloud-native modernization is an operating model change. Kubernetes is the foundation, but the durable value comes from configuration governance, safe rollout, elastic capacity, traffic protection, observability, and automated delivery.