Store是Log Service中資料存放區和查詢的單元。針對不同的資料類型,Log Service分別提供了日誌庫(Logstore)、時序庫(MetricStore)和事件庫(EventStore)。
如何選擇Store類型
Log Service提供日誌庫(Logstore),指標庫(Metricstore),事件庫(Eventstore)三種類型的Store,不同類型的Store主要區別在於對資料類型的相容性上。請根據資料類型選擇對應Store,如無特殊需要可預設使用Logstore。
Store類型 | 適用情境 |
日誌庫(Logstore) |
|
時序庫(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保留欄位( Logstore、Topic、Shard之間的關係如下: | 包括Null 字元串在內的任一字元串,大小為0~128位元組。 若不需要區分Logstore中的日誌,則在採集日誌時設定為空白字串即可。Null 字元串是一個有效Topic,即Topic的值為空白字串。 |
日誌時間 | Log Service保留欄位( | Unix時間戳記。 |
日誌內容 | 日誌的具體內容,由一個或多個內容項組成,內容項為 您通過Logtail極簡模式(單行或多行)採集日誌時,Logtail不會對日誌內容進行解析。整條原始日誌將被上傳到content欄位中。 |
|
日誌來源 | Log Service保留欄位( | 任一字元串,大小為0~128位元組。 |
日誌標籤 | 日誌標籤。包括:
| 字典格式,Key和Value均為字串類型。在日誌中以 |
樣本
以下以一條網站訪問日誌為例,說明原始日誌與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的定義規範,在時序庫中所有的資料都按照時序類型儲存。

時序標識
每條時間軸都有一個唯一的時序標識,由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則不能包含豎線( | )。例如method為POST, URL為/api/v1/get 。
資料點
資料點代表時間軸在具體某個時間點的值,每個資料點由時間戳記和值組成。其中時間戳記精度為納秒,值的類型為double。
資料結構
時序資料的寫入協議和日誌寫入協議一致,使用Protobuf的資料編碼方式。時序標識和資料點都在content欄位中,具體表示方式如下所示。
欄位 | 說明 | 樣本 |
__name__ | Metric名稱。 | nginx_ingress_controller_response_size |
__labels__ | Label資訊,格式為 說明
| 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
事件數目據(Event)
事件(Event)是指值得關注的、有價值的資料。例如監控警示資料、定期巡檢作業的結果等。Log Service的事件數目據遵循CloudEvents協議規範,具體說明如下表所示。
欄位類型 | 欄位名 | 是否必選 | 資料格式 | 說明 |
協議欄位 |
| 是 | String | 根據CloudEvents協議規範,預設使用 |
| 是 | String | 事件ID,您可以根據 | |
| 是 | String | 通常用來標識事件發生的上下文資訊,例如事件來源、發布事件的執行個體等。 | |
| 是 | String | 事件類型,例如 | |
| 否 | String | 事件主題,是對 | |
| 否 | String | 事件類型,預設取值為 | |
| 否 | URI |
| |
| 否 | JSON | 具體的事件內容。不同來源和類型的事件格式會有差異。 | |
| 是 | Timestamp | 事件時間,具體格式,請參見RFC 3339。例如 | |
擴充欄位 |
| 是 | String | 事件標題。 |
| 是 | String | 事件描述。 | |
| 是 | String | 事件狀態。取值:
|
樣本
例如一個警示事件,樣本資料如下:
{
"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代表調用鏈中被命名並計時的連續性執行片段。