Guance VS ELK、EFK¶

ELK、EFK と Guanceの概要¶

近年、あらゆるソフトウェアシステムの複雑性が高まっており、通常、ログはサーバーによって生成され、システムログ、アプリケーションログ、セキュリティログなど、さまざまなファイルに出力されます。これらのログは異なるマシンに分散して保存されています。システム障害が発生した場合、エンジニアは各サーバーにログインし、grep / sed / awk などの Linux スクリプトツールを使用してログから障害原因を調査する必要があります。ログシステムがない場合、まずリクエストを処理したサーバーを特定し、そのサーバーに複数のインスタンスがデプロイされている場合は、各アプリケーションインスタンスのログディレクトリにあるログファイルを探す必要があります。また、各アプリケーションインスタンスにはログローテーションポリシー（例：1日1ファイルの生成）やログ圧縮・アーカイブポリシーなどが設定されています。この一連のプロセスにより、障害の調査や原因の迅速な特定が非常に困難になります。

クラウド上にデプロイすると、各ノードにログインして各モジュールのログを確認することは、基本的に不可能になります。非効率であるだけでなく、セキュリティ上の理由からエンジニアが各物理ノードに直接アクセスできない場合もあるからです。さらに、現在の大規模ソフトウェアシステムは基本的にクラスター方式でデプロイされており、各サービスに対して複数の同一の POD が起動してサービスを提供し、各コンテナが自身のログを生成します。生成されたログだけを見ても、どの POD が生成したのかはまったくわからず、分散ログの確認はさらに困難になります。

したがって、これらのログを一元的に管理し、集中検索機能を提供できれば、診断の効率が向上するだけでなく、システム全体の状況を包括的に把握し、事後対応の受動的な状態を回避できます。

ELK¶

では、ELK とは一体何でしょうか？ 「ELK」は、Elasticsearch、Logstash、Kibana という3つのオープンソースプロジェクトの頭文字をとったものです。Elasticsearch は検索・分析エンジンです。Logstash はサーバーサイドのデータ処理パイプラインであり、複数のソースから同時にデータを収集し、変換して、Elasticsearch などの「リポジトリ」に送信できます。Kibana を使用すると、ユーザーは Elasticsearch 内のデータをグラフやチャートで可視化できます。

Elasticsearch¶

Elasticsearch は、JSON ベースの分散型検索・分析エンジンです。RESTful Web サービスインターフェースからアクセスでき、スキーマの少ない JSON（JavaScript Object Notation）ドキュメントを使用してデータを保存します。Java プログラミング言語で記述されているため、Elasticsearch はさまざまなプラットフォームで実行できます。ユーザーは非常に高速に大量のデータを検索できます。

主な特徴¶

• 分散型リアルタイムファイルストレージ。各フィールドがインデックス化され、検索可能です。
• 分散型リアルタイム分析検索エンジン。
• 数百台のサーバーに拡張可能で、PB 級の構造化データまたは非構造化データを処理できます。

Logstash¶

これはデータフロー用のオープンソースのストリーミング ETL エンジンであり、数分でデータフローパイプラインを構築でき、水平方向のスケーラビリティと復元力、適応型バッファリングを備え、200 以上の統合機能とプロセッサを備えたプラグインエコシステムを有し、Elastic Stack を使用してデプロイメントを監視および管理します。

主な特徴¶

• ほぼあらゆるデータにアクセス可能
• さまざまな外部アプリケーションと連携可能
• 弾力的な拡張をサポート

Logstash の構成¶

• 入力（inputs）: inputs は主にデータ受信ルールを提供します。例えば、ファイル内容の収集などに使用します。
• フィルター（filters）: filters は主に転送されるデータをフィルタリングします。例えば、grok ルールを使用したデータフィルタリングなどです。
• 出力（outputs）: outputs は主に受信したデータを定義された出力モードに従って出力します。例えば、Elasticsearch への出力などです。

Kibana¶

Kibana はオープンソースのデータ分析・可視化プラットフォームであり、Elastic Stack のメンバーで、Elasticsearch と連携するように設計されています。Kibana を使用すると、Elasticsearch インデックス内のデータの検索、表示、対話操作が可能です。グラフ、表、マップを使用してデータを多様に分析・表示できます。

Kibana はビッグデータをわかりやすくします。シンプルでブラウザベースのインターフェースにより、動的データダッシュボードを迅速に作成・共有し、Elasticsearch のリアルタイムデータの変化を追跡できます。

EFK¶

EFK はソフトウェアではなく、ソリューションのセットです。EFK は 3 つのオープンソースソフトウェア、Elasticsearch、Fluentd、Kibana、または Elasticsearch、Filebeat、Kibana の頭文字をとったものです。Elasticsearch はログ分析とストレージを担当し、Fluentd と Filebeat はログ収集を担当し、Kibana はインターフェース表示を担当します。これらは相互に連携して動作し、シームレスに連携することで、多くの場面のアプリケーションに効率的に応え、現在主流のログ分析システムソリューションの 1 つです。

Fluentd¶

Fluentd はオープンソースのデータコレクターであり、データストリームの処理に特化して設計され、JSON をデータ形式として使用します。プラグインアーキテクチャを採用しており、高い拡張性と可用性を備え、信頼性の高い情報転送も実現します。使用時には、さまざまな異なるソースからの情報をまず Fluentd に送信し、次に Fluentd が設定に従ってさまざまなプラグインを介して情報をファイル、SaaS プラットフォーム、データベース、さらには別の Fluentd など、さまざまな場所に転送できます。

主な特徴¶

• インストールが簡単
• 占有スペースが小さい
• 半構造化データのログ記録
• 柔軟なプラグインメカニズム
• 信頼性の高いバッファリング
• ログ転送

Fluentd の構成¶

Fluentd の Input / Buffer / Output は、Flume の Source / Channel / Sink に非常に似ています。

• Input: Input はデータの受信または能動的なデータ取得を担当します。syslog、http、file tail などをサポートします。
• Buffer: Buffer はデータ取得のパフォーマンスと信頼性を担当し、ファイルやメモリなどのさまざまなタイプの Buffer を設定できます。
• Output: Output はデータをファイル、AWS S3、またはその他の Fluentd などの宛先に出力することを担当します。

Filebeat¶

Filebeat は Golang で実装された軽量ログコレクターであり、Elasticsearch stack の一部でもあります。基本的にエージェントであり、各ノードにインストールして、設定に従って対応する場所のログを読み取り、適切な場所に報告できます。

Filebeat は信頼性が非常に高く、ログの At least once の報告を保証し、ログの断点からの読み取り再開、ファイル名の変更、ログの切り詰めなど、ログ収集におけるさまざまな問題も考慮しています。

Filebeat は Elasticsearch に依存せず、単独で存在できます。Filebeat を単独で使用してログの報告と収集を行うことができます。Filebeat には、kafka、Elasticsearch、redis などの一般的な Output コンポーネントが組み込まれており、デバッグ目的で console や file に出力することもできます。既存の Output コンポーネントを使用してログを報告できます。もちろん、Output コンポーネントをカスタマイズして、Filebeat がログを希望の場所に転送するようにすることもできます。

Filebeat は実際には elastic/beats の一部であり、filebeat の他に HeartBeat、PacketBeat があります。これらの beat はすべて libbeat フレームワークに基づいて実装されています。

Filebeat の構成¶

• 収集ハーベスタ（harvester）: 収集ハーベスタの主な役割は、単一ファイルの内容を読み取ることです。各ファイルを読み取り、コンテンツを出力（the output）に送信します。ファイルごとに 1 つのハーベスタが起動され、ハーベスタはファイルのオープンとクローズを担当します。つまり、実行時にファイル記述子は開かれたままになります。読み取り中にファイルが削除または名前変更された場合、Filebeat はファイルの読み取りを続行します。

• 探索プロスペクター（prospector）: 探索プロスペクターの主な役割は、ハーベスタを管理し、読み取るすべてのファイルソースを見つけることです。入力タイプがログの場合、プロスペクターはパスに一致するすべてのファイルを検索し、各ファイルに対してハーベスタを起動します。各プロスペクターは独自の Go ルーチンで実行されます。

注: Filebeat prospector はローカルファイルのみを読み取ることができ、リモートホストに接続して保存されたファイルやログを読み取る機能はありません。Filebeat の適用範囲は非常に限られているため、この記事では Filebeat の詳細な比較は行いません。

Guance¶

DataKit¶

DataKit はユーザーのローカルマシン上で実行される基本的なデータ収集ツールであり、主にシステム実行のさまざまなメトリクス、ログなどのデータを収集し、それらを Guance に集約するために使用されます。Guanceでは、ユーザーは自身のさまざまなメトリクス、ログなどのデータを表示および分析できます。DataKit は Guanceの中核となるデータ収集コンポーネントであり、Guance内のすべてのデータは DataKit から取得されます。

1. DataKit は主に定期的な収集方法でさまざまなメトリクスを収集し、定期的かつ定量的に HTTP(s) を介してデータを DataWay に送信します。各 DataKit には、異なるユーザーを識別するための対応するトークンが設定されます。
2. DataWay はデータを受信後、Guanceに転送します。Guanceに送信されるデータには、API 署名が含まれています。
3. Guanceは正当なデータを受信後、データタイプに応じて、それぞれ異なるストレージに書き込みます。

収集タイプのデータ業務では、一般的に、一部のデータ損失が許容されます（データ自体が間欠的に収集されるため、間欠期間内のデータは一種のデータ損失と見なせます）。現在、データ転送チェーン全体で以下の損失保護が行われています。

1. DataKit が何らかのネットワーク理由で DataWay への送信に失敗した場合、DataKit は最大 1000 ポイントのデータをキャッシュします。キャッシュデータがこの量を超えると、キャッシュはクリアされます。
2. DataWay が何らかの理由で Guanceへの送信に失敗した場合、またはトラフィックが多くて Guanceに送信できない場合、DataWay はこれらのデータをディスクに永続化します。その後、トラフィックが低下するかネットワークが回復したときに、これらのデータを Guanceに送信します。遅延送信されたデータは、タイムスタンプがキャッシュデータに付加されているため、即時性に影響しません。

DataWay では、ディスクを保護するために、このディスクの最大使用量も設定可能で、ノードのストレージが満杯になるのを防ぎます。使用量を超えたデータについては、DataWay はデータを破棄することを選択します。ただし、この容量は通常、大きめに設定されます。

DataKit の構成¶

上から下へ、DataKit 内部は主に 3 つの層に分かれています。

• 最上層: プログラムエントリモジュールといくつかの共通モジュールを含みます。
• 設定読み込みモジュール: DataKit は自身のメイン設定（conf.d/datakit.conf）に加えて、各コレクターの設定は個別に設定されます。これらをまとめると、設定ファイルが非常に大きくなり、編集が不便になるためです。
• サービス管理モジュール: 主に DataKit サービス全体の管理を担当します。
• ツールチェーンモジュール: DataKit はクライアントプログラムとして、データ収集以外にも、ドキュメントの表示、サービスの再起動、更新など、多くの周辺機能を提供しており、これらはツールチェーンモジュールで実装されています。
• Pipeline モジュール: ログ処理において、Pipeline スクリプト（Grok 構文）を使用してログを解析し、非構造化ログデータを構造化データに変換します。その他の非ログタイプのデータでも、対応するデータ処理が可能です。
• 選挙モジュール: 多数の DataKit がデプロイされている場合、ユーザーはすべての DataKit の設定を同じにし、自動バッチデプロイメントを介して設定を各 DataKit に配布できます。選挙モジュールの重要性は、クラスター内で、特定のデータの収集（例：Kubernetes クラスターメトリクス）は1つだけの DataKit が実施すべきである点にあります（そうしないとデータが重複し、収集対象に負荷がかかります）。すべての DataKit の設定が同じクラスターでは、選挙モジュールを介して、任意の時点で最大 1 つの DataKit のみが収集を実施するようにできます。
• ドキュメントモジュール: DataKit のドキュメントはインストール時に同梱され、ユーザーは http://localhost:9529/man ページからドキュメント一覧にアクセスできます。また、コマンドラインからドキュメントを参照することもできます。
• 転送層: ほぼすべてのデータの入出力を担当します。
• HTTP サービスモジュール: DataKit はサードパーティデータの取り込みをサポートしています（例：Telegraf/Prometheus）。今後、さらに多くのデータソースを取り込む予定です。現在、これらのデータはすべて HTTP を介して取り込まれます。
• IO モジュール: 各データ収集プラグインは、収集が完了するたびにデータを IO モジュールに送信します。IO モジュールは、統一されたデータ構築、処理、送信インターフェースをカプセル化しており、各コレクタープラグインが収集したデータを取り込みやすくしています。また、IO モジュールは一定のリズム（定期的、定量的）で、HTTP(s) を介してデータを DataWay に送信します。
• 収集層: さまざまなデータの収集を担当します。収集タイプに応じて、2 つのカテゴリに分類されます。
• 能動的収集型: これらのコレクターは、設定された固定頻度で収集を行います（例：CPU、ネットワークインターフェーストラフィック、クラウド Synthetic テストなど）。
• 受動的収集型: これらのコレクターは通常、外部データ入力によって収集を実現します（例：RUM、Tracing など）。これらは通常 DataKit の外部で実行され、DataKit が公開するデータアップロード API を介して、データを一定の標準化処理した後、Guanceにアップロードします。

Guance プラットフォーム¶

強力なデータ収集能力に基づき、「Guance」は、インフラストラクチャ、コンテナ、ミドルウェア、データベース、メッセージキュー、アプリケーションリンクトレーシング、フロントエンドアクセス、システムセキュリティ、ネットワークアクセスパフォーマンスに至るまでの全リンクのオブザーバビリティを構築します。Guanceの標準製品に基づき、ユーザーが DataKit 収集を正しく設定すれば、自社プロジェクトの完全なオブザーバビリティ構築を迅速に実現できます。同時に、Line Protocol や Guanceのシナリオ構築機能に基づき、ユーザーは観測したいメトリクスをカスタム定義して簡単に統合し、さらなるオブザーバビリティを実現できます。

「Guance」は、オブザーバビリティを指向した完全な技術製品として、非常に多くの技術的ハードルを内包しています。さまざまなオープンソースソリューションと比較して、Guanceは当初から、ユーザーが製品を使用するための学習コストを効果的に削減し、使いやすさを向上させる方法を強く重視してきました。そのため、DataKit のインストールとデプロイメント、およびすべての設定可能な機能において、「Guance」は可能な限りユーザーの設定の難易度を下げ、ほとんどのプログラマーや運用保守エンジニアの習慣に適合させると同時に、UI 全体の使いやすさと専門性を高め、ユーザーが製品のユーザーとその価値をすぐに理解できるようにしています。

実行プラットフォームの比較¶

Logstash の当初の利点の 1 つは、JRuby で記述されているため、Windows 上で実行できることです。 Fluentd は最近まで Windows をサポートしていませんでしたが、Linux プラットフォーム中心のイベントライブラリに依存しなくなったため、現在は Windows をサポートしています。また、in_windows_eventlog プラグインを使用して Windows イベントログを追跡することもできます。 DataKit は、Guance製品が公式に提供するデータコレクターであり、複数のデータソース収集スクリプトを内蔵し、複数のデータ入力をサポートし、Windows、Linux、Mac オペレーティングシステム、ARM、X86 などの複数のシステムタイプをサポートし、ログ収集においては全プラットフォームとの互換性を実現しています。

Logstash¶

Linux および Windows

Fluentd¶

Linux および Windows

DataKit¶

全プラットフォームをサポートし、クライアントでの視覚的な設定管理をサポートしているため、インストール、デプロイメント、複雑な設定の学習コストを大幅に削減します。

イベントルーティングの比較¶

イベントルーティング設定に関して、Fluentd の方法はより宣言的であり、Logstash の方法は手続き的です。したがって、手続き型プログラミングのトレーニングを受けた開発者は、Logstash の設定の方が習得しやすいと感じるかもしれません。また、Fluentd のタグベースのルーティングにより、複雑なルーティングを明確に表現できます。しかし、Guanceは、完成された製品ロジックと強力な製品コンポーネントに基づき、イベントアラートやデータブラウジングなどの機能を他の製品に依存せずに実現でき、真の観測のクローズドループを実現し、データの安全性を確保しながら、複雑な設定を避け、優れたユーザーエクスペリエンスを提供します。

Logstash イベントルーティング¶

Logstash はすべてのデータを 1 つのストリームにルーティングし、if-then ステートメントを使用して目的の宛先に送信します。以下は、本番環境のエラーイベントを PagerDuty に送信する例です。

output {
  if [loglevel] == "ERROR" and [deployment] == "production" {
    pagerduty {
      ...
    }
  }
}

Fluentd イベントルーティング¶

Fluentd はタグに依存してイベントをルーティングします。各 Fluentd イベントには、Fluentd にルーティング先を指示するタグがあります。本番環境でエラーイベントを PagerDuty に送信する場合の設定は次のとおりです。

<source>
  @type forward
</source>

<filter app.**>
  @type record_transformer
  <record>
    hostname "#{Socket.gethostname}"
  </record>
</filter>

<match app.**>
  @type file
  # ...
</match>

DataKit プロキシ¶

DataKit は Guanceの強力な製品コンポーネントの一部として、データを直接クラウド上の Guanceプラットフォームに報告し、観測・分析を行います。LogStash や Fluentd のように、イベントルーティングを提供してデータを他のツールに転送して分析、キャッシュなどを行う必要はありません。もちろん、DataKit はユーザーデータの安全性を確保し、DataKit がインターネットにアクセスできない内部ネットワーク環境にデプロイされ、プロキシサーバーを使用してインターネットにアクセスする必要がある場合に対処するために、DataKit のプロキシ設定は非常に簡単で、プロキシオプションを有効にするだけで、豊富な製品機能を簡単に体験できます。

[[inputs.proxy]]
  ## default bind ip address
  bind = "0.0.0.0"
  ## default bind port
  port = 9530

プラグインエコシステムの比較¶

Logstash、Fluentd、DataKit はすべて、多くの入力システム（ファイルや TCP/UDP など）、フィルター（フィールドによる分割やフィルタリング）をカバーする豊富なプラグインエコシステムを備えています。

Logstash プラグイン¶

Logstash はすべてのプラグインを GitHub リポジトリで管理しており、inputs、filter、output プラグインは合計 200 以上ありますが、ユーザーが共同でメンテナンスしており、公式のメンテナンスやホスティングは不足しています。

Fluentd プラグイン¶

Fluentd には、入力、パーサー、フィルター、出力、フォーマッタ、ストレージ、サービスディスカバリ、バッファの 8 種類のプラグインがあり、合計 500 以上のプラグインが含まれていますが、公式がホストしているのはそのうちの 10 個のみで、残りはユーザーが共同でメンテナンスしており、公式のメンテナンスやホスティング、テクニカルサポートが不足しています。

¶

DataKit プラグイン¶

DataKit には、動的 grok 構文クエリデバッグ、独自開発の DQL 構文に基づく高速データクエリ、リアルタイムの inputs 収集実行監視、エッジコンピューティング機能、ビジュアルクライアント方式での設定・収集ソースのデプロイなど、強力な組み込み機能が含まれています。同時に、200 以上の公式メンテナンスのデータソース接続とテクニカルサポートをサポートし、Telegraf、Beats、Logstash、Fluentd などのさまざまな外部データ入力との互換性も備えています。ユーザーにとってさらに便利なのは、クライアントで視覚的にプラグインとエージェントを管理でき、データ収集状況をリアルタイムで確認できることです。

キューの比較¶

Logstash は永続的な内部メッセージキューを欠いています。現在、Logstash には 20 イベント（固定サイズ）を保持できるメモリキューがあり、再起動時の永続化ストレージのために Redis などの外部キューに依存しています。Fluentd には設定可能なバッファシステムがあり、メモリ上またはディスク上に配置できますが、その信頼性を設定するのは複雑になる可能性があります。DataKit には組み込みのキャッシュメカニズムがあり、サーバー設定に応じて簡単なパラメータを変更するだけでデータキャッシュ効果を実現できます。

Logstash キュー¶

Logstash は組み込みの永続性を持つメッセージキューを欠いているため、組み込みのキューモデルは非常にシンプルで、永続化を保証するために Redis などの外部キューが必要です。

Fluentd キュー¶

Logstash と比較して、Fluentd は組み込みの信頼性を備えていますが、設定が比較的複雑で、ユーザーの学習コストが高くなります。

DataKit キュー¶

DataKit には組み込みのキャッシュメカニズムがあり、DataKit をデプロイしたサーバーが何らかのネットワーク理由で DataWay への送信に失敗した場合、DataKit はデフォルトで最大 1000 ポイントのデータをキャッシュしてデータ損失を防ぎます。また、DataKit 設定ファイルを変更することで最大キャッシュ量を制御でき、設定は簡単で使用ハードルも低く、学習コストはほぼゼロです。

ログ解析の比較¶

ログ分析は企業内で非常に基本的な中核技術であり、セキュリティチームだけでなく、IT 開発チームやビジネスチームでも使用されています。セキュリティの観点では、セキュリティチームがログ分析を抽出する主な目的は、未知のセキュリティイベントを発見し、既知のセキュリティイベントのトレーサビリティ分析を行うことです。もう 1 つの重要な目的は、国家レベルの規制遵守要件です。IT 開発の観点では、企業内の非セキュリティ技術チームがログ分析を行う主な目的は、位置の問題を発見し、既知の問題を分析することであり、主にシステム監視、APM（APM には開発チームが注目するすべての監視項目が含まれます）に集中しています。ビジネスの観点では、ビジネスチームのログ分析に対するニーズは、リスク管理、運用プロモーション、ユーザー属性分析、サイト属性分析などに集中しています。つまり、ログはハードディスクに保存されているだけでは価値がなく、ログ分析技術によってログ情報の価値を実現できます。ログの価値が高ければ高いほど、会社の技術力の高さを反映することにもなります。

一般的に使用される Logstash には、任意のテキストを解析・構築する grok、イベントフィールドに通常の変換を実行する mutate、イベントを完全に削除する drop、イベントのコピーを作成する clone、IP アドレスの地理位置情報を追加する geoip などの一般的なパーサーが含まれています。Fluentd のログ解析では、一般的な操作として、1 つ以上のフィールドの値を検索してイベントをフィルタリングしたり、新しいフィールドを追加してイベントをリッチ化したり、プライバシーとコンプライアンスのために特定のフィールドを削除またはマスクしたりします。プラグインは比較的少なく、record_transformer、filter_stdout、filter_grep、parser、filter_geoip の 5 つのみです。DataKit のログ解析には、非構造化テキストデータを解析するため、または構造化テキスト（JSON など）から部分情報を抽出するための Pipeline、glob ルールを使用したログファイルのより簡単な指定と自動検出・ファイルフィルタリング、grook の使用ハードルを下げる使いやすい対話型 Grok マッチングツール、データ形式をより柔軟にする多数のスクリプト関数など、より多くの機能が含まれています。

Logstash ログ解析¶

Grok は現在、Logstash で非構造化ログデータを構造化されクエリ可能なコンテンツに解析する最良の方法です。現在、Logstash には 120 種類の grok 解析テンプレートが組み込まれていますが、Logstash が GitHub リポジトリで管理する grok 解析テンプレートはユーザーが共同でメンテナンスしており、公式のテクニカルサポートが不足しており、grok テンプレートのパフォーマンスチューニングなどの多くのビジネス要件はユーザー自身が調査する必要があります。

Fluentd ログ解析¶

Fluentd のログ解析形式は Logstash と似ていますが、設定方法はより柔軟です。ただし、対応する grok 解析テンプレートは提供されておらず、いくつかの設定例のみが提供されているため、ユーザーはドキュメントの例に基づいて解析機能を自分で設定する必要があり、ハードルは比較的高くなります。設定中に発生する問題に対するテクニカルサポートは不足しており、ユーザーは自分で Google などで解決する必要がある可能性が高くなります。

同じように設定されたサーバー環境で、Nginx の access log をサンプルとして、以下のような 365 バイトのログを 14 のフィールドに構造化します。

以降のテストでは、さまざまな負荷をシミュレートして、このログをファイルに繰り返し書き込みます。各ログの time フィールドは現在のシステム時刻を取得し、その他の 13 のフィールドは同じです。

実際のシナリオと比較して、シミュレーションシナリオではログ解析に違いはありません。1 つの違いは、データ圧縮率が高いとネットワーク書き出しトラフィックが減少することです。

logstash¶

logstash-7.1.0 バージョンで、grok を使用してログを解析し、kafka（組み込みプラグイン、gzip 圧縮有効）に書き出します。

ログ解析設定:

grok {
  patterns_dir=> "/home/admin/workspace/survey/logstash/patterns"

  match=>{ "message"=>"%{IPORHOST:ip} %{USERNAME:rt} -
\"%{WORD:method} %{DATA:url}\" %{NUMBER:status} %{NUMBER:size} \"%{DATA:ref}\" \"%{DATA:agent}\" \"%{DATA:cookie_unb}\" \"%{DATA:cookie_cookie2}\" \"%{DATA:monitor_traceid}\" %{WORD:cell} %{WORD:ups} %{BASE10NUM:remote_port}" }

  remove_field=>[ "message"]
}

テスト結果:

fluentd¶

td-agent-4.1.0 バージョンで、正規表現を使用してログを解析し、kafka（サードパーティプラグイン fluent-plugin-kafka、gzip 圧縮有効）に書き込みます。

ログ解析設定:

<source>
  type tail
  format /^(? <ip>\S+)\s(?<rt>\d+)\s-\s\[(?<time>[^\]]*)\]\s"(?<url>[^\"]+)"\s(?<status>\d+)\s(?<size>\d+)\s"(?<ref>[^\"]+)"\s"(?<agent>[^\"]+)"\s"(?<cookie_unb>\d+)"\s"(?<cookie_cookie2>\w+)"\s"(?
  <monitor_traceid>\w+)"\s(?<cell>\w+)\s(?<ups>\w+)\s(?<remote_port>\d+).*$/
  time_format %d/%b/%Y:%H:%M:%S %z
  path /home/admin/workspace/temp/mock_log/access.log
  pos_file /home/admin/workspace/temp/mock_log/nginx_access.pos
  tag nginx.access
</source>

テスト結果:

DataKit¶

DataKit-1.1.8-rc3 で、Pipeline を使用して非構造化テキストデータを解析します。

# access log
grok(_, "%{NOTSPACE:ip} %{NOTSPACE:rt} - \"%{NOTSPACE:method} %{NOTSPACE:url}\" %{NOTSPACE:status} %{NOTSPACE:size} \"%{NOTSPACE:ref}\" \"%{NOTSPACE:agent}\" \"%{NOTSPACE:cookie_unb}\" \"%{NOTSPACE:cookie_cookie2}\" \"%{NOTSPACE:monitor_traceid}\" %{NOTSPACE:cell} %{NOTSPACE:ups} %{NOTSPACE:remote_port}")

cast(status_code, "int")
cast(bytes, "int")

default_time(time)

ログ収集アーキテクチャの比較¶

ELK ソリューション¶

ソリューション 1¶

これは最もシンプルな ELK アーキテクチャの方式です。利点は、構築が簡単で習得が容易なことです。欠点は、Logstash のリソース消費が大きく、実行時の CPU とメモリの使用率が高いことです。また、メッセージキューによるキャッシュがないため、データ損失のリスクがあります。ユーザーは Logstash、ElasticSearch、Kibana に十分精通している必要があり、さまざまな複雑なビジネス問題を解決するために熟練して運用する必要があります。また、LogStash クラスターと ElasticSearch クラスターの保守担当者は、クラスターのパフォーマンス最適化とリソース管理に十分精通している必要があり、ビジネスが正常に動作することを保証する必要があります。

このアーキテクチャでは、Logstash が各ノードに分散して関連するログやデータを収集し、分析・フィルタリングした後、リモートサーバー上の Elasticsearch に送信して保存します。Elasticsearch はデータをシャード形式で圧縮保存し、ユーザーがクエリや操作を行うためのさまざまな API を提供します。ユーザーは Kibana Web を設定することで、より直感的にログをクエリし、データに基づいてレポートを生成することもできます。

ソリューション 2¶

これは比較的成熟した ELK アーキテクチャです。利点は、Kafka を導入することで、遠隔地の Logstash クラスターが障害で停止した場合でも、データが先に保存されるため、データ損失を防げることです。欠点は、構築が複雑で、技術スタックが複雑なため習得が比較的難しく、Logstash のリソース消費が大きく、CPU とメモリの使用率が高いことです。Kafka クラスターを別途保守する必要があり、大規模なシナリオでは Zookeeper クラスターも別途保守する必要がある可能性があります。ユーザーは Logstash、ElasticSearch、Kafka、Kibana に十分精通している必要があり、さまざまな複雑なビジネス問題を解決するために熟練して運用する必要があります。また、LogStash クラスター、Kafka クラスター、ElasticSearch クラスターの保守担当者も、クラスターのパフォーマンス最適化とリソース管理に十分精通している必要があり、ビジネスが正常に動作することを保証する必要があります。

このアーキテクチャでは、メッセージキュー機構が導入されています。各ノードの Logstash Agent が最初にデータやログを Kafka（または Redis）に渡し、キュー内のメッセージやデータを間接的に Logstash に渡します。Logstash がフィルタリング・分析した後、データを Elasticsearch に渡して保存します。最後に Kibana がログとデータをユーザーに表示します。Kafka（または Redis）を導入したことで、遠隔地の Logstash server が障害で停止した場合でも、データが先に保存されるため、データ損失を防げます。

EFK ソリューション¶

ソリューション 1¶

これはより柔軟な EFK アーキテクチャです。利点は、より柔軟で、Logstash と比較してリソース消費が少なく、拡張性が高いことです。欠点は、ログを LogStash クラスターに報告して集中処理するには、大規模な LogStash クラスターの計算能力が必要であり、ユーザーは Logstash、ElasticSearch、Kibana に十分精通している必要があり、さまざまな複雑なビジネス問題を解決するために熟練して運用する必要があることです。また、LogStash クラスターと ElasticSearch クラスターの保守担当者も、クラスターのパフォーマンス最適化とリソース管理に十分精通している必要があり、ビジネスが正常に動作することを保証する必要があります。

このアーキテクチャでは、収集側の logstash を Filebeats に置き換え、同時に Logstash および Elasticsearch クラスターを設定して、大規模クラスターシステムの運用ログデータの監視とクエリをサポートできます。

ソリューション 2¶

ELK をベースに、ログ収集側として Filebeat を採用しています。利点は、ELK のアーキテクチャのように Logstash をログ収集側として使用する場合、各サーバーに Java 環境をインストールする必要がありますが（Logstash は Java ベースであるため）、Filebeat は依存関係がなく、インストール後に設定ファイルを変更してサービスを起動するだけで使用できる点です。欠点は、技術スタックが複雑なため習得が比較的難しく、Logstash のリソース消費が大きく、CPU とメモリの使用率が高いことです。Kafka クラスターを別途保守する必要があり、大規模なシナリオでは Zookeeper クラスターも別途保守する必要がある可能性があります。ユーザーは FileBeats、Logstash、ElasticSearch、Kafka、Kibana に十分精通している必要があり、さまざまな複雑なビジネス問題を解決するために熟練して運用する必要があります。また、LogStash クラスター、Kafka クラスター、ElasticSearch クラスターの保守担当者も、クラスターのパフォーマンス最適化とリソース管理に十分精通している必要があり、ビジネスが正常に動作することを保証する必要があります。

このアーキテクチャでは、収集側がログファイルを収集する際に、Filebeat の input で fields を定義し、log_topic フィールドを定義して、指定されたパス下のログファイルを 1 つのカテゴリに分類します。Output では、Kafka への出力を指定します。Kafka はメッセージキューとして、Filebeat クライアントが収集したすべてのログを受信し、ログの種類（nginx、php、system など）に応じて分類して転送します。Kafka では、inout でカスタム定義されたログタイプに基づいて、異なる topic を作成します。Logstash は Kafka メッセージキューからのメッセージを受信し、Kafka 内の異なる topic に基づいて、ログを分類して Elasticsearch に書き込みます。Kibana は Elasticsearch 内のインデックスにマッチングし、ログ内容の分析、検索、グラフ表示を行うことができます（もちろん、自分でグラフを設計する必要があります）。

ソリューション 3¶

ログ収集側として Fluentd を採用しています。利点は、Fluentd のリソース消費が LogStash クラスターよりもはるかに少なく、アーキテクチャをよりシンプルで柔軟にできることです。欠点は、Fluentd の設定が比較的複雑で、使用ハードルが高く、習得が難しく、設定ファイルが比較的複雑で変更が面倒なことです。ユーザーは Fluentd、ElasticSearch、Kibana に十分精通している必要があり、さまざまな複雑なビジネス問題を解決するために熟練して運用する必要があります。また、ElasticSearch クラスターの保守担当者も、クラスターのパフォーマンス最適化とリソース管理に十分精通している必要があり、ビジネスが正常に動作することを保証する必要があります。

このアーキテクチャでは、Fluentd がプログラムのログを収集し、ログを elasticsearch クラスターに保存し、最後に kibana で elasticsearch を関連付けてログのクエリを実現します。

Guance アーキテクチャ¶

収集用の DataKit は基本的なデータ収集ツールであり、主にシステム実行のさまざまなメトリクス、ログなどのデータを収集し、DataWay を介して Guance に集約します。Guanceでは、ユーザーは自身のさまざまなメトリクス、ログなどのデータを表示および分析できます。DataKit は Guanceの中核となるデータ収集コンポーネントであり、Guance内のすべてのデータは DataKit から取得されます。

DataKit のデプロイ設定は非常にシンプルで明確であり、視覚的なクライアントを通じてユーザーが DataKit を管理するのに役立ちます。DataKit はログデータだけでなく、APM データ、インフラストラクチャ、コンテナ、ミドルウェア、ネットワークパフォーマンスなども収集できます。DataKit は LogStash や Fluentd のように Elasticsearch や Kafka などのコンポーネントに依存してビジネス機能を補完する必要はありません。Guanceはこれらの問題をまったく考慮する必要がなく、ユーザーは本当に自分のビジネス最適化だけに集中できます。DataKit は、ユーザーが複雑な技術スタックを習得したり、高い学習コストを支払ったりする必要はなく、簡単な設定だけで Guanceと組み合わせてさまざまな複雑なビジネス問題を解決できます。ELK や EFK は全体的な運用コストが莫大であり、Elasticsearch クラスターだけでも多額の費用がかかり、コスト削減のためにホット/コールドデータを考慮するとさらに頭痛の種になります。Guanceを使用すれば、これらの問題を考慮する必要はなく、すべての注意をビジネスに集中させるだけで済みます。

ハードウェアコストの比較¶

価格は誰もが非常に関心を持つ要素です。ここでは、クラウドサービスを使用して、ELK、EFK、Guanceの間のコストを比較します。

ELK コスト¶

Elastic の基本コンポーネントはすべてオープンソースであり、主なコストはハードウェアコストから発生します。ここでは、異なるアーキテクチャ構成で 10 台のサーバーのログを収集し、各サーバー毎日 1G のログ量としてコストを計算します。

LogStash クラスター + Kafka クラスター + ElasticSearch クラスター + Kibana

• LogStash クラスター

• Kafka クラスター

• ElasticSearch クラスター

• Kibana ノード

ビジネス規模が大きくない場合のストレージとサーバー構成で価格を計算すると、LogStash + Kafka + ElasticSearch + Kibana の 1 か月の総費用は 5175.4 元です。

シンプルなアーキテクチャ（Kafka クラスターを使用しない）の LogStash + ElasticSearch + Kibana の 1 か月の総費用は 2511.4 元です。

EFK コスト¶

Elastic の基本コンポーネントはすべてオープンソースであり、主なコストはハードウェアコストから発生します。ここでは、異なるアーキテクチャ構成で 10 台のサーバーのログを収集し、各サーバー毎日 1G のログ量としてコストを計算します。

Fluentd + ElasticSearch クラスター + Kibana

• Fluentd

Fluentd は単独でクラスターとしてデプロイする必要はないため、Fluentd のコストは考慮せず、ElasticSearch + Kibana のみを計算します。

• ElasticSearch クラスター

• Kibana ノード

同様に、同じビジネス規模でストレージとサーバー構成を計算すると、Fluentd + ElasticSearch + Kibana の 1 か月の総費用は 2028 元です。

Guance コスト¶

Guance自体は製品費用を請求せず、ストレージ使用量に応じてのみ課金されます。DataKit コレクター数、ログタイプデータ数、バックアップログデータ数、1 日あたりのタスクスケジュール回数、単一 DataKit の時系列数、RUM の 1 日あたりのセッション数、APM のトレース数に基づいて価格が計算されます。同様に、10 台のサーバーのログを収集し、各サーバー毎日 1G のログ量としてコストを計算します。

10 台のサーバーに DataKit をインストールし、ログ収集は各サーバー毎日 1G、1 ログあたり 4K として計算します。

同様に、同じビジネス規模で Guance の 1 か月の総費用は 1825 元です。

運用コストの比較¶

運用コストについて言えば、クラスターの完全性を保証するためには関連する運用が不可欠であることは誰もが知っています。それでは、各ソリューション間のコストの違いを一緒に分析してみましょう。

ELK 運用コスト¶

Elastic の基本コンポーネントはすべてオープンソースであるため、ユーザー自身でクラスターを構築して運用管理を行う必要があります。複雑なアーキテクチャの ELK には、LogStash クラスター + Kafka クラスター + ElasticSearch クラスター + Kibana ノードが含まれる可能性があります。まず、ユーザーのビジネスログ量が多く、計算ロジックが複雑な場合、LogStash クラスター、Kafka クラスター、ElasticSearch クラスターの規模と構成に対する要件は非常に高くなります。次に、異なる規模のクラスターに対する運用担当者のスキル要件も高く、大規模なクラスターではさまざまな問題が発生する可能性があり、リソース利用率を最大化するには、パフォーマンスチューニングの十分な経験が必要です。最後に、運用担当者の技術スタックに関する要件は不可欠です。

EFK 運用コスト¶

ELK と同様に、EFK もオープンソースコンポーネントに基づいており、ユーザー自身でクラスターを構築して管理する必要があります。ELK より良い点は、EFK が Fluentd をコレクターとして使用してデータを収集する場合、LogStash クラスターを省くことができ、リソース消費も少ないことです。ただし、ビジネス規模に応じて ElasticSearch クラスターの規模を動的に拡張する必要がある点は同じであり、大規模クラスターでは運用担当者のスキル要件が高く、最適化が難しいという問題に直面します。また、Fluentd の設定は Logstash よりも難しく、運用担当者の経験に頼らざるを得ません。スクリプトの最適化が適切でない場合、ログ解析時にサーバー上の既存のビジネスに影響を与える可能性もあります。オンラインビジネスの安定稼働を保証するためには、運用担当者に対する要件はさらに高くなる可能性があります。

Guance 運用コスト¶

Guanceは SaaS 型の可観測性プラットフォームであり、ユーザーはデータを収集したいサーバーに DataKit をデプロイし、リモートビジュアル管理機能を有効にするだけで、収集側の設定管理をリモートで視覚的に行うことができます。Guanceプラットフォームは最適なログ解析テンプレートを提供し、サーバーへの負荷を最小限に抑えながらパフォーマンスを最大限に活用し、簡単な設定でビジネスログを解析できるように支援し、ユーザーはビジネスの最適化と拡張に集中できます。収集側やログ解析クラスターの最適化に労力を費やす必要はもうありません。また、Guanceはオンラインで完全な可観測性機能を提供し、インフラストラクチャ、コンテナ、ミドルウェア、データベース、メッセージキュー、アプリケーションリンクトレーシング、フロントエンドアクセス、システムセキュリティ、ネットワークアクセスパフォーマンスの全リンクを観測でき、ビジネス要件に基づいて独自の観測シナリオを実現できます。未成熟なオープンソース製品を調査したり改造したりする必要はなくなり、真の意味で運用コストゼロでビジネス発展に集中できる効果を実現します。

学習コストの比較¶

ログ分析システムの構築や使用において、学習コストは不可欠な要素です。使いこなすにはまず学習する必要があります。それでは、各ソリューションの習得難易度を見てみましょう。

ELK 学習コスト¶

Elastic のコンポーネントはすべてオープンソースであるため、ユーザー自身でクラスターを構築する必要があります。まず、ELK を使用してログを分析処理する場合、ELK の環境準備や ELK コンポーネントの設定使用方法の学習は不可欠です。例えば、Elasticsearch の理解、Elasticsearch の基礎知識の習得、Elasticsearch のインデックス操作の習得、Elasticsearch クラスターの計画、オープンソース版の LogStash や ElasticSearch のパフォーマンス設定の最適化などが必要です。

EFK 学習コスト¶

ELK と同様に、EFK でもこれらの内容を学習する必要があります。さらに、Fluentd は LogStash よりも設定が柔軟であり、それに伴う学習コストも高くなります。パフォーマンス最適化は使用経験にさらに依存するようになります。LogStash が 120 以上の grok テンプレートを提供しているのに対し、Fluentd ではユーザーがドキュメントを参照して多くの学習を行い、ようやく実際に使いこなせるようになります。

Guance 学習コスト¶

Guanceでは、ユーザーは DataKit のみを環境にデプロイしてデータ収集を行います。ユーザーが必要とするデータ収集の設定について、公式は基本的に設定の参考情報や使用ガイドを提供しています（現在 200 以上のテクノロジースタックをサポート）。ユーザーがログ分析、ビジネス観測、リンクトレーシングなどを行う場合、Guanceプラットフォームの対応するモジュールの製品使用方法を学習し、DataKit の収集項目を有効にするだけで、ビジネストレーシングなどの要件を実現できます。ログ分析などの要件を実現するためにオープンソースクラスターを構築する必要はなく、多数の技術を学習する必要もなく、ユーザーはオープンソースクラスターの稼働を維持するために多くの時間を費やすのではなく、ビジネス上の問題の処理により多くの時間を費やすことができます。

使用体験の比較¶

製品の使用体験の比較も重要です。同じ機能を実現する場合に、ユーザーにどのような違いをもたらすのでしょうか？

ELK 使用体験¶

ELK でログ分析を行うには、まず LogStash、Kafka、ElasticSearch クラスターと Kibana 表示ノードを構築する必要があります。次に、特定のコンポーネントのデータ収集と解析を実現するには、既存の 120 以上の解析テンプレートの中に使用できるものがあるかどうかを確認し、なければ、テストを重ねてデータ収集と解析を実現する必要があります。収集時のパフォーマンス消費が大きすぎたり、解析処理が遅すぎたりした場合のデバッグは、さらに面倒なプロセスです。同時に、ログの増分が多すぎる場合は、Elasticsearch のクエリインデックスの最適化やクラスターの頻繁な拡張に直面することになります。最後に、特定のビジネスを表示したい場合は、Kibana の KQL を学習してデータクエリと表示を行う必要があります。データのリアルタイム追跡とアラートをさらに行うには、他のオープンソースコンポーネントに依存する必要があるかもしれません。使用プロセスでは、要件の提出から解決までに 80% 以上の時間をオープンソースコンポーネントのさまざまな問題の解決に費やし、最終的にビジネス分析と最適化に実際に費やす時間はごく一部になります。

EFK 使用体験¶

EFK でログ分析を行う場合も、ElasticSearch クラスターと Kibana 表示ノードの構築は避けられません。Fluentd のより柔軟な設定には、ユーザーはデータの収集と解析を正常に完了するために、より多くの設定とデバッグの時間を必要とする可能性があります。同様に、ElasticSearch クラスターを使用する場合、ElasticSearch のインデックス最適化やクラスターの拡張も避けられません。最後に、Kibana を学習してデータクエリと表示を行う必要があります。同様に、ユーザーは使用プロセスにおいて、要件の提出から解決までに 80% 以上の時間をオープンソースコンポーネントのさまざまな問題の解決に費やし、最終的にビジネス分析と最適化に実際に費やす時間はごく一部になります。

Guance 使用体験¶

Guanceを使用したログ分析などの要件の実現は、非常にユーザーフレンドリーです。まず、Guanceのデータ収集側である DataKit のインストールと設定は非常に簡単で、1 つのコマンドでインストールと設定を完了できます。次に、ユーザーのコンポーネントログやデータ収集要件に対して、Guanceは 200 以上の主流テクノロジースタックをサポートしており、インフラストラクチャ、コンテナ、ミドルウェア、データベース、メッセージキュー、アプリケーションリンクトレーシング、フロントエンドアクセス、システムセキュリティ、ネットワークアクセスパフォーマンスなど、あらゆる側面を全方位的にサポートします。また、充実したドキュメント体系を持ち、すべてのユーザー使用要件はドキュメントに基づいて解決できます。さらに、コレクター DataKit にはビジュアルクライアント方式が提供されており、ユーザーの使用困難を軽減します。同時に、Guanceプラットフォームは、ユーザーが自身のビジネスの健全性をより良く観測できるように、多数の公式シナリオビューを提供しています。

Guanceは、インフラストラクチャ、コンテナ、ミドルウェア、データベース、メッセージキュー、アプリケーションリンクトレーシング、フロントエンドアクセス、システムセキュリティ、ネットワークアクセスパフォーマンスの全リンクのオブザーバビリティを構築します。Guanceの標準製品に基づき、ユーザーが DataKit を正しく設定すれば、自社プロジェクトの完全なオブザーバビリティ構築を迅速に実現できます。同時に、Line Protocol や Guanceのシナリオ構築機能に基づき、ユーザーは観測したいメトリクスをカスタム定義して簡単に統合し、さらなるオブザーバビリティを実現できます。

簡単な DataKit インストール¶

1 つのコマンドだけで DataKit のインストールを完了できます。

便利な収集項目管理¶

DataKit クライアントへのアクセスを有効にすると、DataKit クライアントで収集項目を変更できるようになります。同時に、多数のテンプレートが組み込まれているため、ユーザーは収集したい内容に応じて対応する設定を有効にするだけで、データ収集を完了できます。

豊富な公式コンポーネントサポート¶

DataKit には、動的 grok 構文クエリデバッグ、独自開発の DQL 構文に基づく高速データクエリ、リアルタイムの inputs 収集実行監視、エッジコンピューティング機能、ビジュアルクライアント方式での設定・収集ソースのデプロイなど、強力な組み込み機能が含まれています。同時に、200 以上の公式メンテナンスのデータソース接続とテクノロジースタックをサポートし、Telegraf、Beats、Logstash、Fluentd などのさまざまな外部データ入力との互換性も備えています。

より強力な製品機能¶

Guanceは、インフラストラクチャ、コンテナ、ミドルウェア、データベース、メッセージキュー、アプリケーションリンクトレーシング、フロントエンドアクセス、ログ、システムセキュリティ、ネットワークアクセスパフォーマンスの全リンクのオブザーバビリティを構築します。Guanceの標準製品に基づき、ユーザーが DataKit を正しく設定すれば、自社プロジェクトの完全なオブザーバビリティ構築を迅速に実現できます。同時に、複数のテクノロジースタックの異常検出ライブラリなどの機能をサポートしており、ユーザーは複雑なビジネス問題に対してより多くの選択肢を得ることができます。