Rails でのロギングをマスターする:デバッグからプロアクティブなアラートまで

ほとんどの人は、ログが最も必要なときにのみログの必要性を認識します。しかし、アプリケーションが壊れ、ユーザーからの苦情が殺到し始め、それを修正する方法が見当もつかないとき、役立つかもしれないログ メッセージを追加しても手遅れです。

良い丸太は 10 倍の価値があります。これらを使用すると、これらの厄介なバグの診断が簡単になり、ログを正しく作成すれば、ユーザーが気づく前に問題を警告することができます。しかし、「ロギングを正しく行う」とはどういう意味でしょうか?

ロギングは始めるのは簡単ですが、マスターするのは困難です。この投稿では、Rails アプリケーションのログを最大限に活用する方法について詳しく説明します。

Rails へのログイン

まずは基本的なことからお話しましょう。新しい Rails アプリケーションを開始すると、ログ記録はすでに設定されています。 Rails は ActiveSupport::Logger の新しいインスタンスを初期化します。 アプリケーション内のどこでも使用できます。

Rails ロガーは標準出力または log/<environment>.log に書き込みます。 また、明示的に書き込んだログ メッセージに加えて、受信したリクエストや実行されたクエリも自動的に記録されます。

Rails のドキュメントで詳しく説明されているように、Rails ログを設定する方法は数多くあります。

ログを最大限に活用するために、私たちはログ レベルの設定とログのフォーマットに特に関心を持っています。

しかし、それに取り組む前に、なぜログを書く必要があるのかについて話しましょう。

良いロギング、悪いロギング

ログの目的は、システム イベントについて通知し、それに対応できるようにすることです。たとえば、エラーが発生した場合、ログ メッセージでそれについて理解できる方法で通知される必要があります。

ログメッセージをどの程度理解できるかは、それがどの程度説明され、文脈に沿っているかによって異なります。説明的なログ メッセージは、何が起こったかに関する関連情報を提供します。コンテキスト ログ メッセージには、システムがメッセージを書き込んだときのシステムの状態に関する情報が含まれます。

なぜ両方が必要なのかを理解するための簡単な例を考えてみましょう。以下は、ユーザーがリクエストを実行したときに外部 API を呼び出し、その応答を返すコードです。

ここで、顧客から問題が報告され、ヘルプを求めてログを調べる状況を想像してみましょう。次のような内容が表示されます。

これらのログ メッセージはいくつかの情報を提供しますが、十分ではありません。お客様が報告したエラーの原因を突き止める段階には至っておりません。これらのログ メッセージには説明とコンテキストが欠けています。それらはノイズです。どうすれば改善できるでしょうか?

Rails のログ レベル

デフォルトの Rails ロガーは、ログレベル DEBUG を提供します。 、INFO 、WARN 、および ERROR 。これらを使用すると、ログメッセージを関連性の異なるカテゴリにグループ化できます。これは、ログ メッセージをフィルタリングするのに役立つだけでなく、コンテキストも提供します。

どのログ レベルをいつ使用するかを決定するのは難しい場合があります。以下にいくつかの経験則を示します。

• DEBUG :システム内で発生したアクションに関する詳細情報を得るには、このログ レベルを使用します。デバッグ ステートメントは、メソッドの開始時または終了時、またはデバッグ中に付加価値があると思われるあらゆる場所で使用できます。
• INFO :システムの状態が変化するか、関連するイベントが発生するたびに、INFO に手を伸ばしてください。 レベル。 Rails アプリケーションのコンテキストにおける一般的な情報メッセージの例には、受信したリクエスト、外部 API に送信されたリクエスト、ジョブの開始と終了などがあります。
• WARN :このログは、予期しないことが起こったことを示すために使用します。これはまだ問題ではありません (アプリケーションで処理できるため) が、引き続き発生する場合は注意が必要になる可能性があります。
• ERROR :エラーが発生した場合は、このログ レベルを使用します。エラーはアプリケーションの無効な状態であり、できるだけ早く解決する必要があります。

それぞれの環境ファイルを変更することで、アプリケーションが書き込むログ メッセージの種類を変更できます。通常、Rails は DEBUG を破棄します。 運用環境ではメッセージが表示されますが、それは変更できます。

上記のログレベルの提案をコードサンプルに適用してみましょう。

デバッグ時に WARN を調べることで問題の根本原因を特定できるようになりました。 と ERROR メッセージ。残念ながら、ログメッセージはこれ以上詳しくはなっていません。

説明的なログ メッセージ

説明的なログ メッセージには解釈の余地がありません。何が起こったのかを読者に即座に伝えるために必要な詳細が提供されます。

'An error occurred' などのメッセージを読んだとき 、エラーが何なのか疑問に思うことになります。ログ メッセージを作成するときは、このような混乱を避けたいと考えています。説明的なログ メッセージを作成するときに最も重要なことは、ログ読み取り者の立場に立つことです。彼らはあなたのログを読むときに必要な情報をすべて取得できるでしょうか?

メッセージ 'An error occurred' を変更しましょう エラー自体と、そのメッセージを含めます。

それは改善ですね。この例で他のログ メッセージを確認してみましょう。 'Method entered' どのメソッドが呼び出されたのかはわかりません、'Response success' 実際の応答を省略し、'Response failure' 障害の性質に関する情報は提供されません。それを変えてみましょう。

メモ :ログで文字列補間を実行するときにブロック構文を使用していることに気づいたかもしれません。 it を使用すると、アプリケーションのログ レベルがログ メッセージのレベルよりも高い場合に、不必要な計算が回避されます。例:log.debug("Some #{concatenation}") 常に文字列の連結を実行しますが、log.debug { "Some #{concatenation}" } ログ レベルがデバッグに設定されている場合にのみ実行されます。

ログの読み取りが大幅に改善されました。各ログ メッセージが何を意味するかについては、ほとんど疑問の余地はありません。

ログ メッセージのさらなるコンテキスト

新しいログ メッセージは、何が起こったのかを明確に示します。これは単純な例であるため、特定のことが起こった理由もよく理解できます。実際には、通常はそれほど簡単ではありません。

システムが各メッセージを書き込んだコンテキストに関する追加情報を提供すると、デバッグに非常に役立ちます。

たとえば、リクエストまたはレスポンスをログに記録する場合、誰がリクエストを実行したかを知ると役立つ場合があります。エラーのスタック トレースを添付すると、エラーが発生した理由に関する追加情報を収集できる場合があります。

メモ :Rails のデフォルト ロガーを使用する場合、コンテキスト情報を含むログ メッセージを作成するのが面倒であることにおそらくお気づきでしょう。幸いなことに、Ougai や MrLogaLoga などのカスタム ロガーを使用すると、 これがはるかに簡単になります。

構造化ロギング

ログを人間が読めるようにしたら、次のレベルに進む準備が整います。ここで、ログをモニタリングやデータ分析に使用できるように、ログをマシンで読み取れるようにする必要があります。

私がよく使う形式は JSON ですが、使用するツールによっては、Logstash などの他のログ形式を好む場合があります。カスタム ログ フォーマッタを作成することで、ログ メッセージの形式を変更できます。

カスタム フォーマッタを自分で作成するのではなく、カスタム ログ フォーマッタを提供する多くの gem の 1 つを使用できます。 Lograge をお勧めします。これは、すぐに使えるフォーマットを提供するだけでなく、Rails のやや冗長なリクエストのフォーマットをクリーンアップして、非常に読みやすくします。

AppSignal を使用した Rails のロギング

ログが読みやすくなったので、さらにアクセスしやすくしたいと思います。結局のところ、SSH でマシンに接続して、そこでログを追跡または grep する必要はありませんよね?

幸いなことに、AppSignal は最近、ベータ版のロギング機能を開始しました。これにより、AppSignal Web インターフェースで直接 Rails ログを検査および分析できるようになります。

左側のメニューの [ロギング] タブからロギング ベータ版にアクセスできます。

Ruby ロギング ドキュメントの手順に従えば、AppSignal::Logger を使用するように Rails Logger を設定できます。 以下のコードを config/environment.rb に配置してクラスを作成します。 initialization より前のファイル :

JSON 形式または Lograge を使用して構造化ログを取り込むこともできます。

すべての設定が完了すると、Rails ログが AppSignal に表示されるはずです。

ログとエラーレポート

AppSignal ブログでこれを読んでいるあなたは、「すでに優れたエラー報告プラットフォームを使用しているのに、なぜログのことを気にする必要があるのでしょう?」と疑問に思うかもしれません。

良い質問ですね。エラー追跡ツールは、アプリケーション エラーに関する詳細情報を提供します。これらは、あらゆるアプリケーション エラーのフルスタック トレースをキャプチャし、すぐに使える多くのコンテキスト情報を提供します。

ただし、ほとんどのツールではエラー以外のイベントをキャプチャできますが、これらのツールで任意の量のメッセージを送信することは一般に不可能です。適切に作成されたログが提供する詳細な履歴情報を置き換えることはできません。

実際には、適切に作成されたログはエラー追跡ツールを強化し、サポートします。おそらく両方を使用する必要があります。

まとめ

この投稿では、ログを最大限に活用する方法を検討しました。 Rails へのログインを始めるのは簡単ですが、役立つログを書くのは難しい場合があることがわかりました。

説明やコンテキストが欠けているログは、価値がほとんどなく、ディスクをいっぱいにするだけになってしまいます。ただし、正しいログ レベルを使用し、読者に必要な情報を提供するログは、大きな資産となります。

優れたログ メッセージの作成をマスターしたら、さらに作業を進めて、ログ分析と簡単なフィルタリングを可能にする方法でログ メッセージをフォーマットすることができます。

また、AppSignal の新しいログ機能を使用してログに簡単にアクセスする方法についても検討しました。最後に、ログがエラー追跡ツールを置き換えるのではなく、どのように拡張すべきかについて触れました。

ログインを楽しんでください!

追記Ruby Magic の投稿を報道後すぐに読みたい場合は、Ruby Magic ニュースレターを購読して、投稿を 1 つも見逃さないようにしてください。

ハンス・イェルク・シュネドリッツ

ゲスト著者の Hans は、オーストリアのウィーン出身の Rails エンジニアです。彼はほとんどの時間をコーディングするかコーディングに関する読書に費やしており、時にはそれについてブログに書くこともあります。彼が画面の前に座っていないときは、おそらく彼が外で山に登っているのを見つけるでしょう。

Hans-Jörg Schnedlitz によるすべての記事