Unlock Cross‑Region Log Analysis with SLS StoreView: A Practical Guide

Introduction

Log Service (SLS) is a cloud‑native observation and analysis platform that provides large‑scale, low‑cost, real‑time services for Log, Metric, and Trace data. While SLS supports multi‑region deployment to reduce latency and network costs, analyzing data across regions traditionally required ETL jobs to centralize logstores.

StoreView Feature

StoreView allows users to combine multiple logstores from different regions and projects into a virtual logstore, enabling cross‑region and cross‑project queries as if they were a single logstore. This eliminates the need for separate ETL synchronization tasks.

Data Preparation

Four demo projects from different regions are used to illustrate common scenarios. Each project contains a user‑queries logstore with core fields such as requestId (string, unique request ID), status (integer, request status), latencyMs (integer, request latency), resultRows (integer, number of result rows), processedBytes (integer, raw data size), processedRows (integer, raw data rows), query (string, SQL content).

requestId : string – unique request ID

status : integer – request status (e.g., 200, 400, 500)

latencyMs : integer – request latency in milliseconds

resultRows : integer – number of rows returned

processedBytes : integer – amount of raw data processed (bytes)

processedRows : integer – number of raw data rows processed

query : string – SQL query text

Traditional ETL Approach

Before StoreView, users had to create ETL tasks to sync logstore data from each region to a centralized logstore, which doubled storage, incurred extra network costs, and required manual maintenance.

Using StoreView for Global Analysis

After defining a StoreView, users can run SQL queries that operate on the virtual logstore, achieving the same results as centralized ETL without data duplication or latency. Example SQL demonstrates identical analysis capabilities.

StoreView SPL Features

StoreView integrates SPL (Search Processing Language) operators, currently supporting extend, project, and where. These enable advanced capabilities such as:

Data Visibility Control : Row‑level filtering (e.g., showing only error queries to ops staff).

Query‑Based ETL Processing : On‑the‑fly data transformation without separate ETL jobs.

Sensitive Data Masking : Hide fields like sourceIp and userId from non‑privileged users.

Heterogeneous Schema Alignment : Use extend to alias mismatched field names (e.g., latency vs. latencyMs).

Data Visibility Control Example

A StoreView can filter rows so that only failed queries (status ≠ 200) are visible to certain users, effectively implementing row‑level access control.

Sensitive Data Masking Example

Using SPL project to exclude sourceIp and userId fields creates a StoreView that returns queries without exposing personal information.

Schema Alignment Example

When different projects use different field names for latency, the extend operator can create an alias so that a unified query works across all logstores.

StoreView Meta Fields

StoreView adds meta fields __project__ and __logstore__ to identify the original source of each record, enabling analyses such as per‑project daily processing volume.

Conclusion

StoreView provides a simple, cost‑effective way to perform cross‑region and cross‑project log analysis without the overhead of ETL pipelines, supporting real‑time queries, SPL‑based transformations, and fine‑grained access control. Future improvements will focus on performance, stability, and broader feature support.