How to Perform Cross‑Region Log Analysis with SLS StoreView

Introduction

Log Service (SLS) is a cloud‑native observability platform that provides large‑scale, low‑cost, real‑time storage and analysis for logs, metrics, and traces. While SLS supports multi‑region deployment to reduce latency and network costs, analyzing data across regions traditionally required complex ETL jobs.

Data Preparation

The article uses four demo projects located in different regions, each containing a user‑queries logstore. The core fields of each logstore are:

requestId (string) – unique request identifier

status (int) – HTTP status code (e.g., 200, 400, 500)

latencyMs (int) – request latency in milliseconds

processedBytes (int) – raw data size in bytes

processedRows (int) – number of processed rows

query (string) – raw SQL query text

How to Perform Global Analysis

Before StoreView, you had to create data‑processing (ETL) tasks to synchronize each regional logstore into a centralized logstore. This approach doubled storage, incurred extra public‑network traffic, and introduced latency. After all processing tasks succeeded, you could query the centralized logstore (e.g., centralized‑user‑queries).

StoreView Overview

StoreView is a new SLS feature that virtually merges multiple logstores across regions and projects into a single logical logstore. Users can query this virtual logstore with the same SQL syntax as a regular logstore. StoreView currently supports three SPL commands: extend, project, and where. After defining a StoreView, you can run SQL statements that operate on the combined data in real time.

StoreView SPL Features

Data Visibility Control

StoreView enables row‑level visibility. For example, a StoreView can filter out all rows where status equals 200, allowing ops staff to see only error queries. The resulting virtual logstore ( failed_user_queries) returns only failed requests.

Query‑style ETL Processing

Using SPL, you can mask sensitive fields without creating separate ETL jobs. By applying project and extend, fields like sourceIp and userId can be omitted or replaced, and the sanitized view is instantly available for all users.

Schema Alignment

When different logstores use different field names for the same concept (e.g., latencyMs vs. latency), you can create an alias with extend and cast the type to varchar. This aligns schemas so that aggregate queries work across all projects.

StoreView Meta Fields

StoreView automatically adds two meta columns: __project__ and __logstore__, indicating the original project and logstore of each row. These columns let you compare metrics such as daily processed data volume per project.

Conclusion

StoreView dramatically simplifies cross‑project, cross‑region log analysis by eliminating the need for manual ETL pipelines, reducing storage costs, and providing flexible SPL‑based processing. While network latency can affect performance when reading remote logstores, Alibaba Cloud plans to improve StoreView’s stability and efficiency, making global data analysis truly seamless.