log aggregationとは何か? 集中logの解説

log aggregationとは、logを個々のマシンに散在させたままにするのではなく、多くのソースからのlogを単一の集中された検索可能なシステムに集める実践です。

自明でないあらゆるシステムでは、logは多くの場所で同時に生成されます。サービス、コンテナ、そして仕事を終えると消える一時的なマシンをまたいでです。log aggregationはそのすべてを一箇所に集め、システム全体をまたいで検索できるようにし、logを書いたマシンが消えた後もlogが残るようにします。

散在したlogの問題

logが生成したマシン上にしか存在しないと、問題の調査は多くのホストにログインして手作業で相関づけることを意味し、一時的なインスタンスが終了するとlogは消えます。現代の分散された短命なインフラにとって、ローカルのみのlogは事実上使い物になりません。

aggregationの仕組み

収集: agentやshipperが、書き込まれた各ソースからlogを読みます。
転送: logがネットワーク越しに中央のpipelineへ送られます。
処理: エントリが取り込み時にパースされ、構造化され、拡充されます。
保存と検索: logがバックエンドでインデックスされ、すべてのソースを一度にまたいでクエリできます。

システム全体をまたぐ検索

集中化の狙いは、一つの問いを立てて、すべてにまたがる答えを得ることです。あるreleaseからのすべてのエラー、一つのrequest IDを運ぶすべてのlog、fleet全体でのエラー率など。その横断的な検索は、logがマシンごとにサイロ化されていると不可能です。

CI/CDにおけるlog aggregation

CIのrunnerは通常一時的です。jobが終わると、マシンとそのローカルのlogは消えます。build logをaggregatorに送ることで、それらを保存し、実行をまたいで検索でき、失敗したbuildを過去の成功と比較したり、特定のエラーがpipelineの全履歴でどれだけ頻繁に現れるかを数えたりできます。

一般的なスタック

よく知られたaggregationのスタックには、ELKすなわちElasticスタック、Grafana Loki、そしてDatadogやSplunkのようなベンダーのマネージドなlogging機能が含まれます。それらはコストモデルやインデックス戦略で異なりますが、すべて同じ中核の問題を解きます。どこからのlogでも収められる一つの検索可能な住処です。

重要なポイント

log aggregationは、検索のために多くのソースからのlogを集中させます。
一時的なマシンが消えた後も、そのlogを保存します。
サイロ化されたlogでは不可能な、システム横断のクエリを可能にします。
CI/CDでは、一時的なrunnerのlogを実行をまたいで検索可能に保ちます。