オープンソースのログ集計ツール3選

6月 10, 2021

admin

メトリクス集計はログ集計とどう違うのですか？ログにメトリクスを含めることはできないのでしょうか？ログ集約システムはメトリクス集約システムと同じことができないのでしょうか？

これらは私がよく聞く質問です。また、ベンダーが、すべての観測可能性の問題に対するソリューションとして、ログ集約システムを売り込んでいるのを見たことがあります。ログ集約は貴重なツールですが、通常は時系列データのための良いツールではありません。

時系列メトリック集約システムにおけるいくつかの貴重な機能は、一定間隔と、時系列データ用に特別にカスタマイズされたストレージシステムです。定期的な間隔により、ユーザーは実際の数学的結果を一貫して導き出すことができます。ログ集計システムが定期的な間隔でメトリクスを収集している場合、同じように動作する可能性があります。しかし、ストレージ・システムは、メトリクス集計システムで典型的なクエリのタイプに対して最適化されていない。これらのクエリは、ログ集約ツールに見られるストレージシステムを使用して処理するため、より多くのリソースと時間がかかります。

では、ログ集約システムは時系列データには適していない可能性が高いとわかりましたが、何に向いているのでしょうか。ログ集計システムは、イベントデータを収集するのに適しています。これは不定期な活動で、重要なものです。例えば、Webサービスのアクセスログがそうです。いつ、何がシステムにアクセスしたかを知りたいので、これらは重要です。他の例としては、アプリケーション・エラーの状態があります。これは通常の動作状態ではないため、トラブルシューティングの際に貴重な情報となります。

ロギングに関するルールの一握りです。

DO include a timestamp
DO format in JSON
DON’T log insignificant events
DO log all application errors
Maybe log warnings
DO turn on logging
DO write messages in a human->DO write messages in a human->Logging のルール。読みやすい形式
DON’T log informational data in production
DON’T log anything that a human can’t read or react to

Cloud costs

ログ収集ツールを調査する場合、以下のようになります。クラウドは魅力的なオプションのように思えるかもしれません。しかし、それには大きなコストがかかります。ログは、何百、何千ものホストやアプリケーションに集約されると、膨大なデータ量になります。実際のシステムからの参照点として、約 500 台のノードと数百のアプリケーションの集合は、1 日あたり 200GB のログデータを生成します。そのシステムには改善の余地があるでしょうが、半分に減らすだけでも、多くの SaaS オファリングでは毎月 1 万ドル近くのコストがかかります。

これは、特に小規模な組織にとっては非常に価値のあるシステムであるため、これらのシステムの使用を阻止するものではありません。目的は、重大なコストが発生する可能性があることを指摘することであり、それが現実になると落胆する可能性があるということです。この記事の残りの部分では、セルフホスト型のオープンソースおよび商用ソリューションに焦点を当てます。

ツールオプション

ELK

ELKは、Elasticsearch、Logstash、およびKibanaの略で、市場で最も人気のあるオープンソースログアグリゲーションツールです。 Netflix、Facebook、Microsoft、LinkedIn、Ciscoで使用されています。この3つのコンポーネントは、すべてElastic社によって開発・保守されています。 Elasticsearchは基本的にNoSQL、Lucene検索エンジンの実装です。 Logstashはログパイプラインシステムで、データを取り込み、変換し、Elasticsearchのようなストアにロードすることができます。 Kibanaは、Elasticsearchの上にある可視化レイヤです。

数年前、Beatsが導入されました。 Beats はデータコレクターです。 Beats は、Logstash にデータを送信するプロセスを簡素化します。各タイプのログの適切な構文を理解する代わりに、ユーザーは、NGINX ログまたは Envoy プロキシログを適切にエクスポートするビートをインストールし、それらを Elasticsearch 内で効果的に使用できるようにすることができます。また、Logstash を後で説明する Fluentd に置き換えるのが一般的です。このシステムは運用が複雑なこともあり、初期には多くの問題や不満がありました。これらはほぼ修正されていますが、それでも複雑なシステムであることに変わりはないので、小規模な運用であれば試さない方がいいかもしれません。

そうは言っても、サービスがあるので心配は要りませんよ。 Logz.ioが運営してくれますが、データ量が多い場合は定価が少し高いです。もちろん、あなたは規模が小さいでしょうし、データ量も多くないかもしれません。 Logz.ioを買う余裕がない場合は、AWS Elasticsearch Service (ES)のようなものを見てみるとよいでしょう。 ESは、Amazon Web Services（AWS）が提供するサービスで、Elasticsearchを非常に簡単に素早く動作させることができます。また、LambdaとS3を使って、AWSのすべてのログをESに取り込むためのツールもあります。このスタックの親会社である Elastic は、オープンコアモデルを使用する、より堅牢な製品を提供しており、分析ツールやレポートに関する追加オプションを提供しています。また、Google Cloud PlatformまたはAWSでホストすることもできます。ツールとホスティング・プラットフォームのこの組み合わせは、ほとんどのSaaSオプションよりも安価なソリューションを提供し、なおかつ多くの価値を提供するので、これは最良の選択肢かもしれません。このシステムは、セキュリティ情報およびイベント管理 (SIEM) システムを効果的に置き換えるか、その機能を提供することができます。

ELK スタックは、Kibana を通じて優れた視覚化ツールも提供しますが、アラート機能が欠けています。 Elastic は、有料の X-Pack アドオン内でアラート機能を提供していますが、オープンソースシステムには何も組み込まれていません。この問題に対しては、YelpがElastAlertというソリューションを作成しており、おそらく他にもあると思われます。この追加ソフトウェアはかなり堅牢ですが、すでに複雑なシステムの複雑さを増大させます。

Graylog

Graylog は最近人気が出てきましたが、その始まりは Lennart Koopmann が 2010 年にそれを作成したときです。その2年後には、同じ名前の会社が誕生しています。利用者が増えているとはいえ、ELKスタックにはまだまだ及びません。これは、コミュニティが開発した機能が少ないということでもあるが、ELKスタックが使っているのと同じBeatsを使うことができる。 Graylog は、Go で書かれた Graylog Collector Sidecar の導入により、Go コミュニティで賞賛されるようになりました。

Graylog は Elasticsearch、MongoDB、および Graylog Server をフード下で使用します。このため、ELK スタックと同じくらい、あるいはもう少し複雑に動作します。しかし、Graylog には、ストリーミング、メッセージの書き換え、およびジオロケーションといった他のいくつかの注目すべき機能だけでなく、オープンソース版に組み込まれたアラート機能が付属しています。この機能により、ユーザーはすべてのデータベースエラーを 1 つのストリームで、Web サーバーエラーを別のストリームで見ることができます。新しいアイテムが追加されたときや、ある閾値を超えたときに、これらのストリームに基づいてアラートを出すことも可能です。ログ集計システムで最も大きな問題の一つである遅延は、Graylogではストリームがその問題を解決します。

メッセージ書き換え機能は、オープンソースのルールエンジンである Drools を使用します。これにより、すべての受信メッセージがユーザー定義のルールファイルに対して評価され、メッセージが削除されたり (ブラックリストと呼ばれます)、フィールドが追加または削除されたり、メッセージが修正されたりします。これはかなり一般的な機能で、Kibana でも利用できますが、特にこれを SIEM システムとして使用する場合は、多くの価値が追加されます。

Graylog社では、オープンソース版のサポートが必要な場合は、有料で提供しています。また、エンタープライズ版では、アーカイブ、監査ログ、および追加のサポートを提供するオープンなコアモデルを提供しています。サポートやホスティングのための他の選択肢はあまりないので、Graylog (会社) を使わないのであれば、おそらく自分でやることになるでしょう。

Fluentd

Fluentd は Treasure Data で開発され、CNCF はこれを Incubating プロジェクトとして採用しました。 CとRubyで書かれており、AWSやGoogle Cloudで推奨されています。 Fluentdは、多くのインストールでLogstashの代わりとしてよく使われるようになりました。これは、すべてのノードのログを収集し、中央のストレージシステムにそれらをオフに送信するローカルアグリゲータとして動作します。これは、ログ集約システムではない。

さまざまなデータソースやデータ出力と迅速かつ容易に統合するために、堅牢なプラグインシステムを使用している。 500 以上のプラグインが利用可能なので、ほとんどのユースケースはカバーされているはずです。

Fluentd は、その低いメモリ要件 (わずか数十メガバイト) と高いスループットにより、Kubernetes 環境において一般的な選択肢となります。 Kubernetes のように、各ポッドに Fluentd サイドカーがある環境では、新しいポッドを作成するたびにメモリ消費量が直線的に増加することになります。 Fluentdを使うとシステム利用率が激減してしまうのです。これは、メモリのオーバーヘッドが大きな問題になっていない、ノードごとに 1 つ実行することを目的とした Java で開発されたツールに共通の問題になってきています

。