Stackdriver Logging でフィルタリングすべきログ メッセージの見分け方
Google Cloud Japan Team
ウェブ アプリケーションの仕事に携わっている方なら、こういったアプリケーションがいかにたくさんのログ メッセージを生成するかをよくご存じでしょう。個々の要求、データベース クエリ、モニタリング システムから複数のログ メッセージが生成されることも珍しくありません。
それらのデータをすべて分析し、理解していたのでは、貴重な時間とエネルギーを浪費することになります。特に、現在直面している問題とは関係ない “正常なノイズ” がたくさん含まれている場合はそうでしょう。
数年前、私たちはコミュニティとしてログをもっとうまく収集し、保管する必要があるという話をしました。いかに優れたツールであっても、数 TB のデータからの検索は、数 GB のデータからの検索よりも時間がかかるからです。
もっとも、それを解決する方法は簡単です。単純に、何でもかんでもログに残さなければよいのです。重要な意味がありそうなものだけを選んでログに残し、ノイズをログに書かないようにするのです。
Stackdriver Logging には最近、ログに何を含めるかを選別するのに役立つ Logging Exclusion Filters という新機能が追加されました。これを使えば、特定の製品からのログ メッセージや、特定の基準にマッチするメッセージを完全に除外できます。また、特定のメッセージをサンプリングし、Stackdriver のログ ビューアに表示されるメッセージが一定の割合になるように設定することも可能です。Logging Exclusion Filters の使い方の詳細はこちらを参照してください。
必ずロギングすべきものは何か、サンプリングしたり完全に除外したりしても安全なのはどんなメッセージなのかは、アプリケーションによってまちまちです。しかし、フィルタリングすることを検討すべきメッセージのタイプはある程度共通する、というのが私たちの考えです。ここではそれを紹介しましょう。
モニタリング システムからのログ メッセージ
多くのウェブ アプリケーションは所定の形で稼働時間の監視が行われています。私の場合を例にとると、Stackdriver Monitoring で自分のアプリケーションを監視しており、毎分 5 つ以上の場所でアプリケーションが動いていることを確認しています。私のアプリケーションはすべての要求をロギングしているので、私のログは毎分 5 つずつメッセージが増えます。しかし、稼働時間のチェックに失敗したら Stackdriver Monitoring でわかるので、ログ メッセージはほとんど無意味です。そこで私は、Stackdriver の稼働時間チェック機能からの全メッセージを取り除くフィルタを作りました。
App Engine でアプリケーションを実行していたり、Container Engine や Compute Engine でホスト健全性のチェック機能を使っていたりする場合は、それらのメッセージの除外も検討するとよいでしょう。除外後に健全性チェックで問題が起きたときには、デバッグ中に限り、この種のログ メッセージを一時的に有効にすればよいのです。
成功を示すログ メッセージ
すべてがうまく動いていることを示すメッセージも、安全に除外できることが多いタイプです。たとえば、200 番台のステータス コードを持つ HTTP リクエストがこれに当たります。リダイレクトのログ メッセージも、ほとんどの場合は安全に除外できるでしょう。成功したデータベース クエリのログ メッセージについても、除外できるか、あるいはサンプリングで済ませられるはずです。
これらはほんの一例です。アプリケーションのログを調べれば、基本的に “成功スパム” だと言えるものがほかにも見つかるでしょう。この種の成功メッセージは、ログで最もよく見かけるタイプのメッセージでもあります。これらを取り除けば、ログはかなりスリムになります。無駄なログによる経済的コストと認知コストの両方を削減できるでしょう。
非本番システムからのログ メッセージ
ステージング段階のシステムと本番システムのログをはっきり分けるべきだということは、ほとんど誰もがわかっていることです。しかし、本番環境でたまにしか使わないツールや、試しに使っている新製品のログは、さほど重要ではありません。そのような場合は、リソース タイプ全体でログをオフにすることができます。たとえば、BigQuery を一時的な分析タスクでしか使っていないならば、BigQuery のログを Stackdriver での分析対象から外してしまえば、チェックしなければならないログの量を減らせます。
スループットの高いエンドポイントからのログ メッセージ
スループットの高いエンドポイントからのログ メッセージも、削減を検討すべきタイプです。私の話になりますが、キャリアの初期のころに、トラフィックの 80 % が 1 つのエンドポイントに集中するアプリケーションを担当していました。私たちはその URL だけで毎日数 GB ものデータを生成していました。データがあまりにも多かったので、そのトラフィックのロギングを 100 % から 50 % に、あるいはそれ以下に抑えても問題はなかったはずです。とにかく要求が多かったので、2 つのメッセージのうち 1 つだけをログに出力したとしても、エラーをキャッチできたでしょう。
静的なトラフィックであっても、しばしばスループットが高くなります。アプリケーションがメッセージを出力している場合、スタイルシートやファビコンのダウンロード メッセージの一部だけをロギングするようにすれば、無駄を省けるかもしれません。
もし必要になったら?
上で挙げたことは、手に負えなくならない程度にログを削減するためにできることのごく一部です。アプリケーションのログを実際に見て、よく出てくるタイプのエラーについて調べれば、ログの量を削減するためのアイデアはもっとたくさん浮かんでくるでしょう。それにしても、ログを減らそうとする人が少ないのはなぜでしょうか。私が最もよく耳にする理由は「だって必要になったらどうするの?」というものです。Logging Exclusion Filters なら、メッセージの除外機能をオフにすることで、すべてのトラフィックをログ ビューアに表示できます。問題に気づいたら、デバッグのためにロギングを調整するのです。
また、デバッグやその他の目的で完全な過去ログが必要な場合は、除外しているものも含めて、すべてのメッセージを BigQuery や Google Cloud Storage にエクスポートできます。
Stackdriver Logging と Logging Exclusion Filters は強力です。実際に使ってみて、コストを下げ、効率よくリソースを使うために役立つかどうかを確かめることをお勧めします。詳しくはこちらをご覧ください。
* この投稿は米国時間 8 月 30 日、Developer Advocate である Aja Hammerly によって投稿されたもの(投稿はこちら)の抄訳です。
- By Aja Hammerly, Developer Advocate