Log Service の理解と使用方法をわかりやすくするために、いくつかの基本概念について説明します。

リージョン

リージョンは Alibaba Cloud のサービスノードです。 異なる Alibaba Cloud リージョンにサービスをデプロイすることにより、サービスを顧客に近づけ、アクセスレイテンシを短縮させ、ユーザーエクスペリエンスを向上させることができます。 現在、Alibaba Cloud は 全国に複数のリージョンを提供しています。

プロジェクト

プロジェクトは Log Service の基本管理単位で、リソースの分離と制御に使用されます。 プロジェクトを使用して、1 つのプロジェクトのアプリケーションおよび関連するログソースを管理できます。

Logstore

Logstore はログを収集、格納、消費するための Log Service の 単位です。 Logstore はそれぞれ 1 つのプロジェクトに属します。複数の Logstore を各プロジェクトに作成することができます。 実際のニーズに応じて、プロジェクト用に複数のログストアを作成できます。 一般的な方法は、1 つのアプリケーション内の各タイプのログに対して独立した Logstore を作成することです。 たとえば、「big-game」 というゲームアプリケーションがあって、 サーバー上に 3 種類 (operation_log、application_log、access_log) のログがあるとします。 まず最初に「big-game」という名前のプロジェクトを作成します。 次に、このプロジェクトの中に作成した 3 つのタイプの Logstore をそれぞれ収集、格納、消費することができます。

ログ

ログは、Log Service で処理される最小データ単位です。 Log Service は半構造化データモードを使用してログを定義します。 具体的な形式は次のとおりです。
  • Topic:複数のログをマークするために使用するユーザー定義フィールド。 たとえば、サイトに応じてアクセスログにマークを付けることができます。 このフィールドは、デフォルトで空文字列です (空文字列も有効なトピックです)。
  • Time:ログの生成時刻 (1970-1-1 00:00:00 UTC 以降の秒数) を示すために使用するログの予約フィールド。 通常このフィールドはログの時間に基づいて直接生成されます。
  • Content:特定のログコンテンツを記録するために使用するフィールド。 コンテンツは 、Key-Value ペアで構成される 1 つまたは複数のコンテンツ項目で構成されます。
  • Source:ログのソースを示すために使用するフィールド (ログを生成するマシンのIPアドレスなど)。 このフィールドはデフォルトで空白です。

Log Service は次のように異なるフィールドの値に対して異なる要件をもちます。

表 1. ログフィールド
データドメイン 要件
time 標準の UNIX 時刻形式の整数。 単位は秒です。
topic 最大 128 バイトの UTF-8 エンコード文字列。
source 最大 128 バイトの UTF-8 エンコード文字列。
content 1 つ以上の Key-Value ペア。 キーは 128 バイト以内の UTF-8 でエンコードされた文字列で、文字、アンダースコア、および数字のみ使用できます。数字で開始することはできません。 値は 1024*1024 バイトまでの UTF-8 でエンコードされた文字列です。
コンテンツのキーに次のキーワードを使用することはできません。 __time____source____topic____partition_time___extract_others___extract_others__

トピック

1 つの Logstore 内のログは、ログトピック別にグループ化できます。 ログを書き込むときにトピックを指定できます。 たとえば、プラットフォームユーザーは、ユーザー ID をログトピックとして使用し、ログに書き込むことができます。 1 つの Logstore でログをグループ化する必要がない場合は、すべてのログで同じログトピックを使用できます。

ヌル文字列は有効なログトピックです。 デフォルトのログトピックはヌル文字列です。

実際のアプリケーションシナリオでは、さまざまなログ形式が使用されます。 理解しやすいように、元の Nginx access_log をログサービスのログデータモデルにマップする方法について説明します。 使用する Nginx サーバーの IP アドレスが 10.10.10.1 であると仮定します。 このサーバーの元のログは以下の通りです。

10.1.1.1 - - [01/Mar/2012:16:12:07 +0800] "GET /Send? AccessKeyId=<yourAccessKeyId> HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2"

元のログを次のように Log Service ログデータモデルにマップします。

表 2. Log Service ログデータモデル
データドメイン 項目 説明
topic “” デフォルト値 (ヌル文字列) を使用します。
time 1330589527 正確なログ生成時間 (秒単位)。元のログのタイムスタンプから変換されます。
source “10.10.10.1” サーバーの IP アドレスをログソースとして使用します。
content Key-value pair 特定のログコンテンツ

ログの元のコンテンツを抽出し、それらをキーと値のペアに結合する方法を決定することができます。 次の表が例として示されています。

表 3. カスタム
キー
ip “10.1.1.1”
method “GET”
status “200”
length “5”
ref_url “-“
browser “Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firef

ログ

Span ログのコレクション。

Loggroup

ログのグループ

LogGroupList

結果を返すために使用されるロググループの収集

エンコード方法

現在、以下のコンテンツエンコード方法がサポートされています。 RESTful API レイヤーは Content-Type で示されます。

表 4. サポートされているエンコード方法
意味 Content-Type
Protobuf The data model is encoded by ProtoBuf. application/x-protobuf

ログの時刻形式の詳細については、「データエンコード方法」をご参照ください。

Protobuf では、キーと値のペアが一意である必要はありません。 そのような状況を避けなければなりません。 そうでない場合、動作は未定義になります。

Protobuf はフィールド番号の順序に従って 1 つのメッセージのフィールドをエンコード化します。 そうでない場合、データ解析が失敗する場合があります。