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

Simple Log Service:ストアの管理

最終更新日:Nov 05, 2025

ストアは Simple Log Service におけるデータストレージおよびクエリの基本単位です。Simple Log Service は、さまざまなデータ型を処理するために、Logstore、MetricStore、EventStore の 3 種類のストアを提供しています。

ストアタイプの選択方法

Simple Log Service は、Logstore、MetricStore、EventStore の 3 種類のストアを提供しています。これらのストアタイプの主な違いは、さまざまなデータ型との互換性です。データに合ったストアタイプを選択してください。特別な要件がない場合は、デフォルトで Logstore を使用できます。

ストアタイプ

シナリオ

Logstore

  • ログデータ (Log): システム内の経時的な変更を抽象的に表現したものです。その内容は、指定されたオブジェクトに対する操作の順序付きコレクションと、それらの操作の結果です。広義には、これはほぼすべての種類のデータを含みます。デフォルトでは、Logstore を使用できます。

  • トレースデータ (Trace): サービス呼び出しや処理時間など、単一リクエストの処理情報を記録します。

MetricStore

時系列データ (メトリック): メトリック識別子とデータポイントで構成されます。同じメトリック識別子を持つデータは時系列を形成します。時系列データを保存する必要がある場合は、MetricStore を使用します。

EventStore

イベントデータ (イベント): イベントとは、注目に値する価値のあるデータのことです。例としては、アラート監視データや定期的な検査ジョブの結果などがあります。イベントデータを保存する必要がある場合は、EventStore を使用します。

Logstore

Logstore は、Simple Log Service でログデータを保存およびクエリするための単位です。各 Logstore はプロジェクトに属します。必要に応じて、プロジェクト内に複数の Logstore を作成できます。通常、同じアプリケーションの異なる種類のログに対して、別々の Logstore を作成します。たとえば、App A の操作ログ (operation_log)、アプリケーションログ (application_log)、およびアクセスログ (access_log) を収集するには、app-a という名前のプロジェクトを作成できます。このプロジェクトでは、operation_log、application_log、access_log という名前の Logstore を作成して、各ログタイプを個別に保存できます。

ログの書き込み、クエリ、分析、処理、消費、または配信を行う際には、Logstore を指定します。詳細は次のとおりです。

  • Logstore はログ収集の単位として使用されます。

  • Logstore はログのストレージ、処理、消費、および配信の単位として使用されます。

  • ログのクエリと分析のために、Logstore にインデックスが作成されます。

MetricStore

MetricStore は、Simple Log Service で時系列データを保存およびクエリするための単位です。各 MetricStore はプロジェクトに属します。必要に応じて、プロジェクト内に複数の MetricStore を作成できます。通常、異なる種類の時系列データに対して、異なる MetricStore を作成します。たとえば、基本的なホスト監視データ、クラウドサービス監視データ、およびビジネスアプリケーション監視データを収集するには、demo-monitor という名前のプロジェクトを作成できます。次に、このプロジェクトで、host-metrics、cloud-service-metrics、app-metrics という名前の MetricStore を作成して、これらのデータタイプを個別に保存できます。

時系列データの書き込み、クエリ、分析、または消費を行う際には、MetricStore を指定します。詳細は次のとおりです。

  • MetricStore は時系列データ収集の単位として使用されます。

  • MetricStore は時系列データのストレージと消費の単位として使用されます。

  • MetricStore 内の時系列データは、Prometheus Query Language (PromQL)、SQL-92、または SQL+PromQL 構文を使用してクエリおよび分析できます。

EventStore

EventStore は、Simple Log Service でイベントデータを保存およびクエリするための単位です。各 EventStore はプロジェクトに属します。必要に応じて、プロジェクト内に複数の EventStore を作成できます。通常、異なる種類のイベントデータに対して、異なる EventStore を作成します。たとえば、インフラストラクチャの異常なアクティビティ、ビジネスアプリケーションイベント、カスタムイベントごとにデータを分類し、ストレージと分析に異なる EventStore を使用できます。

イベントデータの書き込み、クエリ、分析、または消費を行う際には、EventStore を指定します。詳細は次のとおりです。

  • EventStore はイベントデータ収集の単位として使用されます。

  • EventStore はイベントデータのストレージと消費の単位として使用されます。

リファレンス

LogGroup

ロググループ (LogGroup) はログのコレクションであり、ログの書き込みと読み取りの基本単位です。LogGroup 内のログは、IP アドレスやソース情報などの同じメタデータを共有します。Simple Log Service にログを書き込んだり、Simple Log Service からログを読み取ったりすると、複数のログが LogGroup にパッケージ化されます。このメソッドは、読み取りおよび書き込み操作の数を減らし、効率を向上させます。各 LogGroup のサイズは最大 5 MB です。

日志组

ログデータ (Log)

ログデータは、システム内の経時的な変更を抽象的に表現したものです。ログは、指定されたオブジェクトに対する操作の順序付きコレクションと、それらの操作の結果で構成されます。ログファイル、イベント、データベースバイナリログ (BinLog)、および時系列データ (メトリック) はすべて、ログのさまざまな形式です。Simple Log Service は、半構造化データモデルを使用してログを定義します。ログは、トピック、時間、コンテンツ、ソース、タグの 5 つのデータドメインで構成されます。Simple Log Service には、データドメインごとに異なるフォーマット要件があります。次の表に要件を示します。

データドメイン

説明

フォーマット

Topic

Simple Log Service は、予約済みフィールド (__topic__) を使用してログの Topic を識別します。これにより、さまざまなサービス、ユーザー、またはインスタンスからのログを区別できます。たとえば、システム A にフロントエンド HTTP リクエスト処理、キャッシュ、ロジック処理、およびストレージ用のモジュールがある場合、http_module、cache_module、logic_module、store_module のように、各モジュールのログに Topic を設定できます。ログが同じ Logstore に収集された後、Topic を使用してソースをすばやく識別できます。ログの Topic は、コレクション構成Global Settings で設定できます。

Logstore、トピック、および シャード の関係は次のとおりです。

空の文字列を含む、サイズが 0〜128 バイトの文字列。

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

イベント時間

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

UNIX タイムスタンプ。

ログコンテンツ

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

Logtail をシンプルモード (単一行または複数行) で使用してログを収集する場合、Logtail はログのコンテンツを解析しません。生のログ全体が content フィールドにアップロードされます。

Key:Value 形式は次のとおりです。

  • キー: フィールド名。キーは、文字、アンダースコア、数字のみを含む 1〜128 バイトの UTF-8 文字列である必要があります。キーを数字で始めることはできません。キーは、次の予約済みフィールドのいずれにもできません。

    • __time__

    • __source__

    • __topic__

    • __partition_time__

    • _extract_others_

    • __extract_others__

  • 値: フィールド値。値は、最大 1 MB の任意の文字列にすることができます。

ログソース

予約フィールド (__source__) は、ログを生成したサーバーの IP アドレスなど、ログのソースを識別します。

サイズが 0〜128 バイトの文字列。

ログタグ

ログタグ。以下が含まれます:

  • カスタムタグ: 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
  • シンプルモードで収集されたログ。生のログ全体が content フィールドに保存されます。

    日志样例

  • 正規表現モードで収集されたログ。ログのコンテンツは、構成された正規表現に基づいてコンテンツを複数のキーと値のペアに抽出することによって構造化されます。

    日志样例

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

時系列データは、メトリック識別子とデータポイントで構成されます。同じ識別子を持つデータは時系列を形成します。Simple Log Service の時系列データ型は、Prometheus データモデルに従います。MetricStore 内のすべてのデータは時系列データとして保存されます。

image

メトリック識別子

各時系列には、メトリック名とラベルで構成される一意の識別子があります。

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

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

データポイント

データポイントは、特定の時点での時系列の値を表します。各データポイントは、タイムスタンプと値で構成されます。タイムスタンプはナノ秒の精度で記録され、値は double 型です。

データ構造

時系列データの書き込みプロトコルは、ログ書き込みプロトコルと同じであり、Protobuf データエンコーディング メソッドを使用します。次の表に示すように、メトリック識別子とデータポイントは両方とも 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

指定された時間範囲内で 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

はい

文字列

デフォルト値は 1.0 で、CloudEvents 仕様に準拠しています。

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.aliyun.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"
}

トレースデータ (Trace)

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