全部產品
Search
文件中心

Simple Log Service:管理Store

更新時間:Oct 29, 2025

Store是Log Service中資料存放區和查詢的單元。針對不同的資料類型,Log Service分別提供了日誌庫(Logstore)、時序庫(MetricStore)和事件庫(EventStore)。

如何選擇Store類型

Log Service提供日誌庫(Logstore),指標庫(Metricstore),事件庫(Eventstore)三種類型的Store,不同類型的Store主要區別在於對資料類型的相容性上。請根據資料類型選擇對應Store,如無特殊需要可預設使用Logstore。

Store類型

適用情境

日誌庫(Logstore)

  • 日誌資料(Log):系統運行過程中變化的一種抽象資料,其內容為指定對象的操作和其操作結果按時間的有序集合。廣義上來說包含了幾乎所有類型的資料,預設情況下可使用Logstore。

  • 鏈路資料(Trace):用於記錄單次請求範圍內的處理資訊,其中包括服務調用和處理時間長度等資料。

時序庫(MetricStore)

時序資料(Metric):由時序標識和資料點組成,相同時序標識的資料群組成時間軸。當資料需要時序儲存時使用MetricStore。

事件庫(EventStore)

事件數目據(Event):事件(Event)是指值得關注的、有價值的資料。例如監控警示資料、定期巡檢作業的結果等。當資料需要事件儲存時使用EventStore。

日誌庫(Logstore)

日誌庫(Logstore)是Log Service中日誌資料存放區和查詢的單元。每個Logstore隸屬於一個Project,每個Project中可建立多個Logstore。可以根據實際需求在目標Project中建立多個Logstore,一般是為同一個應用中不同類型的日誌建立獨立的Logstore。例如採集App A所涉及的動作記錄(operation_log)、應用程式記錄檔(application_log)以及訪問日誌(access_log),可以建立一個名為app-a的Project,並在該Project下建立名為operation_log、application_log和access_log的Logstore,用於分別儲存動作記錄、應用程式記錄檔和訪問日誌。

在執行寫入日誌、查詢和分析日誌、加工日誌、消費日誌、投遞日誌等操作時,都需要指定Logstore。具體說明如下:

  • 以Logstore為採集單元採集日誌。

  • 以Logstore為儲存單中繼存放區日誌以及執行加工、消費、投遞等操作。

  • 在Logstore中建立索引用於查詢和分析日誌。

時序庫(MetricStore)

時序庫(MetricStore)是Log Service中時序資料存放區和查詢的單元。每個MetricStore隸屬於一個Project,每個Project中可建立多個MetricStore。可以根據實際需求為某個專案建立多個MetricStore,一般是為不同類型的時序資料建立不同的MetricStore。例如需要採集基礎主機監控資料、雲端服務監控資料、業務應用監控資料,可以建立一個名為demo-monitor的Project,然後在該Project下建立名為host-metrics、cloud-service-metrics和app-metrics的MetricStore,用於分類儲存基礎主機監控資料、雲端服務監控資料和業務應用監控資料。

在執行寫入、查詢和分析、消費時序資料時,都需要指定MetricStore。具體說明如下:

  • 以MetricStore為採集單元採集時序資料。

  • 以MetricStore為儲存單中繼存放區時序資料以及執行消費操作。

  • 查詢和分析時序資料支援PromQL文法、SQL92文法和SQL+PromQL文法。

事件庫(EventStore)

事件庫(EventStore)是Log Service中事件數目據儲存和查詢的單元。每個EventStore隸屬於一個Project,每個Project中可建立多個EventStore。根據實際需求為某個專案建立多個EventStore,一般是為不同類型的事件數目據建立不同的EventStore。例如可以根據基礎設施例外狀況事件、業務應用事件、自訂事件等進行分類,通過不同的EventStore來進行儲存和分析。

在執行寫入、查詢和分析、消費事件數目據時,都需要指定EventStore。具體說明如下:

  • 以EventStore為採集單元採集事件數目據。

  • 以EventStore為儲存單中繼存放區事件數目據以及執行消費操作。

相關參考

日誌組(LogGroup)

日誌組(LogGroup)是一組日誌的集合,是寫入與讀取日誌的基本單元。一個日誌組中的資料包含相同Meta(IP地址、Source等資訊)。寫入日誌到Log Service或從Log Service讀取日誌時,多條日誌被打包為一個日誌組,以日誌組為單元進行寫入與讀取。該方式可減少讀寫次數,提高業務效率。每個日誌組最大長度為5 MB。

日誌組

日誌資料(Log)

日誌資料是系統運行過程中變化的一種抽象資料,其內容為指定對象的操作和其操作結果按時間的有序集合。文本日誌(LogFile)、事件(Event)、資料庫日誌(BinLog)、時序資料(Metric)等資料都是日誌的不同載體。Log Service採用半結構化的資料模式定義一條日誌,包含日誌主題、日誌時間、日誌內容、日誌來源和日誌標籤五個資料域。Log Service對各個資料域的格式要求不同,詳細說明如下表所示。

資料域

說明

格式

日誌主題(Topic)

Log Service保留欄位(__topic__)用於標識日誌主題,可區分不同服務、使用者或執行個體產生的日誌。例如,系統A包含前端HTTP請求處理、緩衝、邏輯處理、儲存等模組時,可分別為其日誌設定Topic(如http_module、cache_module、logic_module、store_module)。日誌採集至同一Logstore後,可通過Topic快速區分來源。日誌主題(Topic)需在採集配置全域配置中設定。

Logstore、Topic、Shard之間的關係如下:

包括Null 字元串在內的任一字元串,大小為0~128位元組。

若不需要區分Logstore中的日誌,則在採集日誌時設定為空白字串即可。Null 字元串是一個有效Topic,即Topic的值為空白字串。

日誌時間

Log Service保留欄位(__time__)用於標識日誌時間。更多資訊,請參見保留欄位

Unix時間戳記。

日誌內容

日誌的具體內容,由一個或多個內容項組成,內容項為Key:Value格式。

您通過Logtail極簡模式(單行或多行)採集日誌時,Logtail不會對日誌內容進行解析。整條原始日誌將被上傳到content欄位中。

Key:Value的詳細說明如下:

  • Key為欄位名稱,需為UTF-8編碼字串(字母、底線和數字但不以數字開頭)。字串大小為1~128位元組。不可使用如下欄位。

    • __time__

    • __source__

    • __topic__

    • __partition_time__

    • _extract_others_

    • __extract_others__

  • Value為欄位值,可以為任一字元串,大小不超過1 MB。

日誌來源

Log Service保留欄位(__source__)用於標識日誌來源,例如產生日誌的伺服器IP地址。

任一字元串,大小為0~128位元組。

日誌標籤

日誌標籤。包括:

  • 自訂標籤:通過PutLogs介面,在寫入日誌時添加標籤。

  • 系統標籤:Log Service為日誌添加的標籤,包括__client_ip____receive_time__

字典格式,Key和Value均為字串類型。在日誌中以__tag__:為首碼進行展示。

樣本

以下以一條網站訪問日誌為例,說明原始日誌與Log Service中資料模型的映射關係。

  • 原始日誌

    127.0.0.1 - - [01/Mar/2021:12:36:49  0800] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
  • 通過極簡模式採集到Log Service後的日誌,整條原始日誌被儲存在content欄位中。

    日誌範例

  • 通過正則模式採集到Log Service後的日誌,日誌內容被結構化,即根據設定的Regex將日誌內容提取為多個索引值對。

    日誌範例

時序資料(Metric)

時序資料由時序標識和資料點組成,相同時序標識的資料群組成時間軸。Log Service的時序資料類型遵循Prometheus的定義規範,在時序庫中所有的資料都按照時序類型儲存。

image

時序標識

每條時間軸都有一個唯一的時序標識,由Metric name和Labels組成。

  • Metric name是一個字串類型的標識符,用於標識指標類型。Metric name需遵循Regex[a-zA-Z_:][a-zA-Z0-9_:]* 。例如http_request_total表示接收到的HTTP請求的總數。

  • Labels由一組組索引值對組成,各組索引值對之間使用豎線(|)分割,用於標識指標的相關屬性。Key需遵循Regex [a-zA-Z_][a-zA-Z0-9_]* ,Value則不能包含豎線( | )。例如methodPOSTURL/api/v1/get

資料點

資料點代表時間軸在具體某個時間點的值,每個資料點由時間戳記和值組成。其中時間戳記精度為納秒,值的類型為double。

資料結構

時序資料的寫入協議和日誌寫入協議一致,使用Protobuf的資料編碼方式。時序標識和資料點都在content欄位中,具體表示方式如下所示。

欄位

說明

樣本

__name__

Metric名稱。

nginx_ingress_controller_response_size

__labels__

Label資訊,格式為{key}#$#{value}|{key}#$#{value}|{key}#$#{value}

說明
  • Label的Key需按照字母順序進行排序。

  • 建議不要寫入Value為空白字串的Label。例如Label資訊為app#$#|controller_class#$#nginx,則不建議將Key為app的Label寫入時序庫,可能造成PromQL彙總計算報錯。

app#$#ingress-nginx|controller_class#$#nginx|controller_namespace#$#kube-system|controller_pod#$#nginx-ingress-controller-589877c6b7-hw9cj

__time_nano__

時間戳記。支援以秒(s)、毫秒(ms)、微秒(us)、納秒(ns)等多種精度的時間戳記寫入。SQL 查詢時,所有時間戳記統一化為微秒(us)精度輸出,確保時間計算的一致性。

1585727297293000

__value__

值。

36.0

樣本

查詢process_resident_memory_bytes指標在指定時間區間內的所有原始時序資料。

* | select * from "sls-mall-k8s-metrics.prom" where __name__ = 'process_resident_memory_bytes' limit all

image

事件數目據(Event)

事件(Event)是指值得關注的、有價值的資料。例如監控警示資料、定期巡檢作業的結果等。Log Service的事件數目據遵循CloudEvents協議規範,具體說明如下表所示。

欄位類型

欄位名

是否必選

資料格式

說明

協議欄位

specversion

String

根據CloudEvents協議規範,預設使用1.0

id

String

事件ID,您可以根據source+id來區分事件的唯一性。

source

String

通常用來標識事件發生的上下文資訊,例如事件來源、發布事件的執行個體等。

type

String

事件類型,例如sls.alert

subject

String

事件主題,是對source欄位的補充,例如用於描述實際觸發事件的對象。

datacontenttype

String

事件類型,預設取值為application/cloudevents+json

dataschema

URI

data欄位需要遵循的Schema,預設為空白。

data

JSON

具體的事件內容。不同來源和類型的事件格式會有差異。

time

Timestamp

事件時間,具體格式,請參見RFC 3339。例如2022-10-17T11:20:45.984+0800

擴充欄位

title

String

事件標題。

message

String

事件描述。

status

String

事件狀態。取值:

  • ok

  • info

  • warning

  • error

樣本

例如一個警示事件,樣本資料如下:

{
    "specversion": "1.0",
    "id": "af****6c",
    "source": "acs:sls",
    "type": "sls.alert",
    "subject": "https://sls.console.alibabacloud.com/lognext/project/demo-alert-chengdu/logsearch/nginx-access-log?encode=base64&endTime=1684312259&queryString=c3RhdHVzID49IDQwMCB8IHNlbGVjdCByZXF1ZXN0X21ldGhvZCwgY291bnQoKikgYXMgY250IGdyb3VwIGJ5IHJlcXVlc3RfbWV0aG9kIA%3D%3D&queryTimeType=99&startTime=1684311959",
    "datacontenttype": "application/cloudevents+json",
    "data": {
        "aliuid": "16****50",
        "region": "cn-chengdu",
        "project": "demo-alert-chengdu",
        "alert_id": "alert-16****96-247190",
        "alert_name": "Nginx訪問錯誤",
        "alert_instance_id": "77****e4-1aad9f7",
        "alert_type": "sls_alert",
        "next_eval_interval": 300,
        "fire_time": 1684299959,
        "alert_time": 1684312259,
        "resolve_time": 0,
        "status": "firing",
        "severity": 10,
        "labels": {
            "request_method": "GET"
        },
        "annotations": {
            "__count__": "1",
            "cnt": "49",
            "desc": "Nginx最近五分鐘內GET請求錯誤49次",
            "title": "Nginx訪問錯誤警示觸發"
        },
        "results": [
            {
                "region": "cn-chengdu",
                "project": "demo-alert-chengdu",
                "store": "nginx-access-log",
                "store_type": "log",
                "role_arn": "",
                "query": "status >= 400 | select request_method, count(*) as cnt group by request_method ",
                "start_time": 1684311959,
                "end_time": 1684312259,
                "fire_result": {
                    "cnt": "49",
                    "request_method": "GET"
                },
                "raw_results": [
                    {
                        "cnt": "49",
                        "request_method": "GET"
                    },
                    {
                        "cnt": "3",
                        "request_method": "DELETE"
                    },
                    {
                        "cnt": "7",
                        "request_method": "POST"
                    },
                    {
                        "cnt": "6",
                        "request_method": "PUT"
                    }
                ],
                "raw_result_count": 4,
                "truncated": false,
                "dashboard_id": "",
                "chart_title": "",
                "is_complete": true,
                "power_sql_mode": "auto"
            }
        ],
        "fire_results": [
            {
                "cnt": "49",
                "request_method": "GET"
            }
        ],
        "fire_results_count": 1,
        "condition": "Count:[1] > 0; Condition:[49] > 20",
        "raw_condition": "Count:__count__ > 0; Condition:cnt > 20"
    },
    "time": "2023-05-17T08:30:59Z",
    "title": "Nginx訪問錯誤警示觸發",
    "message": "Nginx最近五分鐘內GET請求錯誤49次",
    "status": "error"
}

鏈路資料(Trace)

鏈路資料(Trace)用於記錄單次請求範圍內的處理資訊,其中包括服務調用和處理時間長度等資料。一條鏈路資料對應一條調用鏈,格式參考Trace資料格式。在廣義上,一個調用鏈代表一個事務或者流程在(分布式)系統中的執行過程。在OpenTracing標準中,調用鏈是多個Span組成的一個有向非循環圖(Directed Acyclic Graph,簡稱DAG),每一個Span代表調用鏈中被命名並計時的連續性執行片段。