DataKit ログ処理の概要

この記事では、DataKit がログを処理する方法を紹介します。別の書類では、DataKit がログを収集する方法を紹介しました。これら 2 つのドキュメントは一緒に読むことができます。皆さんがログ処理全体をより包括的に理解できることを願っています。

主な質問:

ログ収集の設定が複雑なのはなぜですか?
ログデータの処理方法

ログ収集の設定が複雑な理由¶

この文書からは、ログソースが多様であるため、ログの構成方法も多様であることがわかります。皆さんにわかりやすくするためには、ここで整理する必要があると思います。

ログ収集プロセス中に、DataKit にはアクティブとパッシブという 2 つの主な収集方法があります。

アクティブなコレクション
- ディスクファイルログを直接収集
- コンテナによって生成されたログを収集します
受動的収集
- HTTP、TCP/UDP、Websocket を通じて DataKit にログを挿入します。

これらのさまざまな形式のログ収集方法の中で、それらはすべて同じ中心的な問題 (DataKit はこれらのログを次に何をしますか?) を解決する必要があります。

この中心的な問題は、次のようなサブ問題に分類できます。

source が何であるかを確認します。後続のすべてのログ処理はこのフィールドに依存します (追加の service フィールドがありますが、指定しない場合、その値はsource値と同じに設定されます)。
Pipelineの設定方法: 設定は必須ではありませんが、広く使用されています。
追加のタグ構成: 構成する必要はありませんが、特別な機能がある場合があります。
複数行のログを分割する方法: ターゲットログが各ログを分割する方法を DataKit に指示する必要があります (DataKit のデフォルトでは、空白以外の文字で始まる各行に新しいログが作成されます)。
特別な無視戦略はありますか。DataKit によって収集されたすべてのデータを処理する必要があるわけではありません。特定の条件を満たしている場合は、収集しないこともできます（収集条件は満たしていますが）
その他の特殊な設定: カラー文字のフィルタリング、テキストのエンコード処理など。

現在、取得したログの処理方法を DataKit に指示する方法がいくつかあります。

ログコレクターの conf 構成

ログコレクターでは、conf経由で設定するに収集されるファイル (またはログストリームを読み取る TCP/UDP ポート) がリストされます。 confではsource/Pipeline/複数行解析/追加タグなどの各種設定が可能です。

データが TCP/UDP 形式で DataKit に送信される場合、後続のログ処理は、logging.conf を通じてのみ設定できます。これは、TCP/UDP プロトコルは、追加の説明情報を添付するには不便であり、単純なログストリームデータの送信のみを担うためです。

この形式のログ収集が最も理解しやすいです。

コンテナコレクターの conf 構成

現時点では、コンテナーコレクターの設定はログの最も表面的な設定 (コンテナー/ポッドイメージ名に基づく) のみを行うことができ、その後のログの処理 (Pipeline/source設定など) はここでは設定できません。これは、この設定は 現在のホスト上のすべてのログ の収集を目的としており、コンテナー環境ではホスト上にさまざまなログがあり、ここで 1 つずつ設定することはできません。

リクエスト内で DataKit にログ処理の構成方法を指示する

HTTP 経由で DataKit の Log Streaming サービスをリクエストし、リクエストにさまざまなリクエストパラメータを含めて、受信したログデータの処理方法を DataKit に指示します。

収集されたオブジェクト (コンテナ/ポッドなど) に特定のアノテーションを作成して、生成されるログの処理方法を DataKit に指示します。

前述したように、コンテナーのコレクター設定で単純にログ収集を構成するのは、粒度が粗すぎて、詳細な構成に役立たないためです。ただし、コンテナ/ポッドにラベルを付けるに設定すると、DataKit が 率先してこれらの注釈を見つけてください になり、各コンテナ/Pod ログの処理方法がわかります。

設定の優先順位¶

通常の状況では、コンテナ/ポッドのアノテーションが最も高い優先度を持ち、conf/Env の設定をオーバーライドします。次に、Env の優先順位は中程度であり、conf 内の設定を上書きします。 conf 内の設定の優先順位は最も低く、その設定は Env またはアノテーションの設定によっていつでも上書きされる可能性があります。

現在、ログの収集/処理に直接関連する Env はありませんが、将来的に関連する環境変数が追加される可能性があります。

例として、container.conf で、「my_test」という名前のイメージをログ収集から除外すると仮定します。

container_exclude_log = ["image:my_test*"]

現時点では、DataKit はイメージ名に一致するすべてのコンテナーまたはポッドを収集しません。ただし、対応するアノテーションが対応するポッド上でマークされている場合は、次のようになります。

apiVersion: apps/v1
kind: Pod
metadata:
  name: test-app
  annotations:
    datakit/logs: |   # <----------
      [
        {
          "source": "my-testing-app",
          "pipeline": "test.p",
        }
      ]

spec:
   containers:
   - name : mytest
     image: my_test:1.2.3

Container.conf でワイルドカード my_test.* を使用してすべてのイメージを除外した場合でも、Pod には特定のラベル (datakit/logs) があるため、DataKit は引き続き Pod のログを収集し、Pipeline などの多くの設定を構成できます。

ログデータの処理方法¶

DataKit では現在、ログは次の処理段階を経ます (処理順にリストされています)。

収集ステージ

収集フェーズでは、外部からログを読み込んだ（受信した）後、基本的な処理を行います。これらのプロセスには、ログのセグメント化 (テキストの大きなセクションを複数の独立した裸のログに分割する)、エンコードとデコード (UTF8 エンコードへの統合変換)、一部の干渉するカラー文字の削除などが含まれます。

個々のログの解析

対応するログがPipeline解析で構成されている場合、各ログ (単一行および複数行のログを含む) がPipelineによって解析されます。Pipelineは主に 2 つのステップに分かれています。

Grok/JSON 解析: Grok/JSON を通じて単一の Raw ログを構造化データに解析します。
抽出されたフィールド (完全な IP 情報、ログの非感作など) を慎重に処理します。
ブラックリスト (フィルター)

フィルターはフィルターのセットです。一連の構造化データを受け取り、特定の論理的判断を通じてデータを破棄するかどうかを決定します。 Filter は、センターによって発行される (DataKit によってアクティブにプルされる) 論理的な操作ルールのセットです。その形式はおおよそ次のとおりです。

{ source = 'datakit' AND bar IN [ 1, 2, 3] }

センターがログブラックリストを構成する場合、100 個の解析ログのうち 10 個がここの条件を満たすと仮定すると (つまり、sourceが datakit で、フィールド bar の値が後続のリストに表示される)、これらの 10 個のログは Guance に報告されず、サイレントに破棄されます。廃棄統計は DataKit Monitor で確認できます。

レポート Guance

以上の手順を経て、最終的にGuanceにログデータが報告され、ログ閲覧ページでログデータが確認できるようになります。

通常の状況では、ログが生成されてから収集が成功し、ページにデータが表示されるまでに約 30 秒の遅延が発生します。この期間中、DataKit 自身のデータは最大でも 10 秒に 1 回しか報告されず、最終的にデータベースに保存されるまでにセンターでも一連のプロセスを経る必要があります。

DataKit ログ処理の概要

ログ収集の設定が複雑な理由¶

設定の優先順位¶

ログデータの処理方法¶

関連資料¶

このページは役に立ちましたか？

DataKit ログ処理の概要

ログ収集の設定が複雑な理由¶

設定の優先順位¶

ログデータの処理方法¶

関連資料¶

このページは役に立ちましたか？ ×

このページは役に立ちましたか？