すべてのプロダクト
Search
ドキュメントセンター

Simple Log Service:ストアの管理

最終更新日:Apr 01, 2026

ストアは、Simple Log Service におけるデータの保存およびクエリ処理の単位です。異なるデータタイプを扱うために、Simple Log Service では LogStore、MetricStore、EventStore の 3 種類のストアが提供されています。

ストアタイプの選択

Simple Log Service では、LogStore、MetricStore、EventStore の 3 種類のストアが提供されています。これらのストアタイプの主な違いは、それぞれのデータモデルとの互換性にあります。ご利用のデータに最も適したストアタイプを選択してください。特に要件がない場合は、デフォルトで LogStore を使用できます。

ストアタイプ

適用範囲

LogStore

  • ログ:システムの状態変化を時間軸上で抽象化した表現です。ログは、特定のオブジェクトに対する操作とその結果から構成される順序付きコレクションです。広義には、ほぼすべてのデータタイプをカバーするため、LogStore はデフォルト選択肢として最適です。

  • トレース:単一のリクエストに対する処理情報を記録したもので、サービス呼び出しや処理時間などを含みます。

MetricStore

時系列データ(メトリック):時系列 ID とデータポイントから構成されます。同一の ID を持つデータポイントは、1 つの時系列を形成します。データが時系列形式での保存を必要とする場合、MetricStore を使用してください。

EventStore

イベントデータ(イベント):モニタリングアラートや定期的な検査ジョブの実行結果など、注目すべき価値ある発生事象の記録です。データがイベントベースの保存を必要とする場合、EventStore を使用してください。

LogStore

LogStore は、Simple Log Service におけるログデータの保存およびクエリ処理の単位です。各 LogStore はプロジェクトに所属し、1 つのプロジェクトには複数の LogStore を含めることができます。要件に応じて、対象のプロジェクト内に複数の LogStore を作成できます。通常、同一アプリケーションから出力される異なる種類のログに対して個別の LogStore を作成します。たとえば、「App A」というアプリケーションの操作ログ、アプリケーションログ、アクセスログを収集する場合、プロジェクト名として app-a を指定し、そのプロジェクト内に operation_logapplication_logaccess_log という名前の LogStore をそれぞれ作成して、各ログタイプを別々に保存します。

ログの書き込み、クエリ、分析、処理、コンシューム、配信などの操作を行う際には、必ず LogStore を指定する必要があります。

  • LogStore はログ収集の単位です。

  • LogStore はログの保存、処理、コンシューム、配信の単位です。

  • LogStore 内にインデックスを作成することで、ログのクエリおよび分析が可能です。

MetricStore

MetricStore は、Simple Log Service における時系列データの保存およびクエリ処理の単位です。各 MetricStore はプロジェクトに所属し、1 つのプロジェクトには複数の MetricStore を含めることができます。要件に応じて、プロジェクトごとに複数の MetricStore を作成できます。通常、異なる種類の時系列データに対して個別の MetricStore を作成します。たとえば、基本ホスト監視データ、クラウドサービスモニタリングデータ、ビジネスアプリケーション監視データを収集する場合、プロジェクト名として demo-monitor を指定し、そのプロジェクト内に host-metricscloud-service-metricsapp-metrics という名前の MetricStore をそれぞれ作成して、これらのデータタイプを別々に保存します。

時系列データの書き込み、クエリ、分析、コンシュームを行う際には、必ず MetricStore を指定する必要があります。

  • MetricStore は時系列データ収集の単位です。

  • MetricStore は時系列データの保存およびコンシュームの単位です。

  • PromQL、SQL-92、SQL+PromQL 構文を用いて、時系列データのクエリおよび分析が可能です。

EventStore

EventStore は、Simple Log Service におけるイベントデータの保存およびクエリ処理の単位です。各 EventStore はプロジェクトに所属し、1 つのプロジェクトには複数の EventStore を含めることができます。要件に応じて、プロジェクトごとに複数の EventStore を作成できます。通常、異なる種類のイベントデータに対して個別の EventStore を作成します。たとえば、インフラストラクチャの異常イベント、ビジネスアプリケーションのイベント、カスタムイベントなどを分類し、それぞれ異なる EventStore に保存・分析できます。

イベントデータの書き込み、クエリ、分析、コンシュームを行う際には、必ず EventStore を指定する必要があります。

  • EventStore はイベントデータ収集の単位です。

  • EventStore はイベントデータの保存およびコンシュームの単位です。

関連ドキュメント

LogGroup

LogGroup はログの集合体であり、読み取りおよび書き込み操作の基本単位です。LogGroup 内のすべてのログは、IP アドレスやソースなど、同一のメタデータを共有します。Simple Log Service へログを書き込んだり、ログを読み取ったりする際には、複数のログが 1 つの LogGroup にバンドルされて処理されます。この方式により、I/O 操作回数が削減され、効率が向上します。各 LogGroup の最大サイズは 5 MB です。

日志组

ログデータ

ログとは、システムの状態変化を時間軸上で抽象化した表現であり、特定のオブジェクトに対する操作とその結果から構成される順序付きコレクションです。ログデータは、テキストログ(LogFile)、イベント(event)、データベースのバイナリログ(BinLog)、時系列データ(metric)など、さまざまな形式で存在します。Simple Log Service では、半構造化データモデルを用いてログを定義しており、1 つのログには topic、time、content、source、tags の 5 つのデータフィールドが含まれます。以下の表に、各データフィールドのフォーマット要件を示します。

データフィールド

説明

フォーマット

Topic

Simple Log Service では、予約済みフィールド(__topic__)を用いてログのトピックを識別します。これにより、異なるサービス、ユーザー、またはインスタンスからのログを区別できます。たとえば、System A がフロントエンド HTTP リクエスト処理、キャッシュ、ロジック処理、ストレージといったモジュールを含む場合、各モジュールのログに対して http_modulecache_modulelogic_modulestore_module といった固有のトピックを設定できます。これらのログが同一の LogStore に収集された後は、トピックを用いてログの発生元を迅速に特定できます。トピックは、Logtail 構成グローバル設定 で設定する必要があります。

以下の図は、LogStore、トピック、シャード の関係を示しています。

長さ 0~128 バイトの任意の文字列(空文字列を含む)。

LogStore 内のログを区別する必要がない場合は、ログ収集時にトピックを空文字列として設定できます。空文字列は有効なトピック値です。

Time

ログの時刻を識別する予約済みフィールド(__time__)。詳細については、「予約済みフィールド」をご参照ください。

UNIX タイムスタンプ。

Content

ログの内容で、Key:Value 形式の 1 つ以上のコンテンツ項目から構成されます。

シンプルモード(シングルラインまたはマルチライン)で Logtail を使用してログを収集する場合、Logtail はログの内容を解析しません。生ログ全体が content フィールドに保存されます。

Key:Value ペアのフォーマットは以下のとおりです:

  • Key(キー):フィールド名。UTF-8 文字列で、長さは 1~128 バイトです。英字、アンダースコア(_)、数字を含めることができますが、数字で始めてはいけません。以下の予約済み名はキーとして使用できません。

    • __time__

    • __source__

    • __topic__

    • __partition_time__

    • _extract_others_

    • __extract_others__

  • Value(値):最大サイズ 1 MB の任意の文字列。

Source

ログのソース(例:ログを生成したサーバーの IP アドレスなど)を識別する予約済みフィールド(__source__)です。

長さ 0~128 バイトの任意の文字列。

Tags

ログのタグで、以下の種類があります:

  • カスタムタグ:API オペレーション PutLogs を呼び出してログを書き込む際に追加できます。

  • システムタグ:Simple Log Service がログに自動的に付与するタグで、__client_ip____receive_time__ などが含まれます。

文字列のキーと値のペアからなる辞書型データ。ログ内では、__tag__: プレフィックス付きで表示されます。

以下の例では、Web サイトのアクセスログを用いて、生ログと Simple 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
  • シンプルモードで Logtail を用いてログを収集した場合、生ログ全体が content フィールドに保存されます。

    日志样例

  • 正規表現モードで Logtail を用いてログを収集した場合、設定された正規表現に基づき、ログの内容が複数のキーと値のペアに構造化されます。

    日志样例

時系列データ(メトリック)

時系列データは、時系列 ID とデータポイントから構成されます。同一の ID を持つデータポイントは、1 つの時系列を形成します。Simple Log Service の時系列データタイプは、Prometheus の データモデル に準拠しています。MetricStore 内のすべてのデータは、時系列データとして保存されます。

image

時系列 ID

各時系列は、メトリック名および一連のラベルによって一意に識別されます。

  • メトリック名は、メトリックタイプを識別する文字列であり、正規表現 [a-zA-Z_:][a-zA-Z0-9_:]* に従う必要があります。たとえば、http_request_total は受信した HTTP リクエストの合計数を表します。

  • ラベルは、縦棒(|)で区切られたキーと値のペアで構成され、メトリックの属性を識別します。キーは正規表現 [a-zA-Z_][a-zA-Z0-9_]* に一致する必要があり、値には縦棒(|)を含めることはできません。たとえば、method の値が POSTURL の値が /api/v1/get となります。

データポイント

データポイントは、特定の時刻における時系列の値を表します。各データポイントはタイムスタンプと値から構成され、タイムスタンプはナノ秒精度、値は double 型です。

データ構造

時系列データの書き込みプロトコルはログと同じであり、Protobuf データエンコーディング 方式を使用します。時系列 ID およびデータポイントは、以下の表に示すように content フィールドに格納されます。

フィールド

説明

__name__

メトリック名。

nginx_ingress_controller_response_size

__labels__

ラベル情報は {key}#$#{value}|{key}#$#{value}|{key}#$#{value} のフォーマットです。

説明
  • ラベルのキーはアルファベット順に並べ替える必要があります。

  • 空の値を持つラベルの書き込みは推奨されません。たとえば、ラベル情報 app#$#|controller_class#$#nginx において、キー app のラベルを MetricStore に書き込まないでください。これは 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

説明

SDK を用いてデータを書き込む場合、MetricStore では上記の表に記載されたフィールド(topic、source、ログタグなど)以外のカスタムフィールドは保存されません。詳細については、「SDK を用いた時系列データの書き込み」をご参照ください。

指定された期間内における process_resident_memory_bytes メトリックのすべての生時系列データをクエリします。

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

image

イベントデータ

イベントとは、モニタリングアラートや定期的な検査ジョブの実行結果など、注目すべき価値ある発生事象の記録です。Simple Log Service のイベントデータは、CloudEvents 仕様に準拠しています。

フィールドタイプ

フィールド名

必須

データフォーマット

説明

プロトコルフィールド

specversion

はい

文字列

CloudEvents プロトコル仕様によると、デフォルト値は 1.0 です。

id

はい

文字列

イベント ID。イベントを一意に識別するには、source+id を使用できます。

source

はい

文字列

イベントが発生したコンテキスト(例:イベントソースやイベントを公開したインスタンスなど)。

type

はい

文字列

イベントタイプ(例:sls.alert)。

subject

いいえ

文字列

イベントの主題で、source フィールドを補足するものであり、たとえばイベントを実際にトリガーしたオブジェクトを説明するために使用されます。

datacontenttype

いいえ

文字列

イベントタイプ。デフォルト値は application/cloudevents+json です。

dataschema

いいえ

URI

data フィールドのスキーマ。デフォルト値は空です。

data

いいえ

JSON

イベントペイロード。フォーマットはイベントのソースおよびタイプに応じて異なります。

time

はい

タイムスタンプ

イベント時間。具体的なフォーマットについては、RFC 3339 をご参照ください。たとえば、2022-10-17T11:20:45.984+0800 です。

拡張フィールド

title

はい

文字列

イベントタイトル。

message

はい

文字列

イベントの説明。

status

はい

文字列

イベントステータス。有効な値は以下のとおりです:

  • 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 Access Error",
        "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 has had 49 GET request errors in the last five minutes",
            "title": "Nginx Access Error Alert Triggered"
        },
        "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 Access Error Alert Triggered",
    "message": "Nginx has had 49 GET request errors in the last five minutes",
    "status": "error"
}

トレースデータ

トレースとは、単一のリクエストの範囲内で発生する処理情報を記録したもので、サービス呼び出しや処理時間などを含みます。各トレースは、1 つのコールチェーンに対応します。データフォーマットの詳細については、「トレースデータフォーマット」をご参照ください。広義には、コールチェーンは分散システムにおけるトランザクションまたはプロセスの実行を表します。OpenTracing 標準では、トレースは複数のスパンから構成される有向非巡回グラフ(DAG)です。各スパンは、トレース内で継続的に実行される名前付き・時刻付きのセグメントを表します。