AWS Lambdaのプログラミング

第7章 ロギング、メトリック、トレース

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この章では、ロギング、メトリクス、トレーシングを通してLambda関数の可観測性を高める方法を探る。 ロギングを通して、Lambda関数の実行の流れで発生する特定のイベントから情報を得る方法を学ぶ。 Platform とビジネスメトリクスによって、サーバーレスアプリケーションの運用の健全性を知ることができる。 最後に、分散トレーシング によって、アーキテクチャを構成するさまざまなマネージドサービスとコンポーネントへのリクエストの流れを確認することができる。

第5章のWeather APIを使用して、AWS上のサーバーレスアプリケーションで利用可能な多種多様なロギング、メトリック、トレースオプションを探索する。第6章で行ったデータパイプラインの変更と同様に、Weather APIのLambda関数がaws-lambda-java-events ライブラリを使用するようにリファクタリングされていることに気づくだろう。

ロギング

以下のログメッセージがあったとして、それを生成したアプリケーションの状態について何が推測できるか？

Recorded a temperature of 78 F from Brooklyn, NY

我々はいくつかのデータ（温度測定と位置）の値を知っているが、他はあまり知らない。 このデータはいつ受信されたのか、あるいは処理されたのか？ 我々のアプリケーションの大きな文脈の中で、どのようなリクエストがこのデータを生成したのか？ どのJavaクラスとメソッドがこのログメッセージを生成したのか？ 他の、おそらく関連するログメッセージとどのように関連づけることができるのか？

根本的に、これは役に立たないログメッセージだ。 コンテキストと具体性に欠けている。 このようなメッセージが何百回、何千回と繰り返されれば（おそらく温度や位置の値が違えば）、意味を失うだろう。 ログメッセージが散文的（例えば、文章やフレーズ）な場合、正規表現やパターンマッチングに頼らずに解析するのは難しくなる。

Lambda関数でのロギングを検討する際には、価値の高いログメッセージの特性をいくつか覚えておこう：

データが豊富

実現可能で費用対効果の高いデータをできるだけ多く取得したい。データが多ければ多いほど、後戻りしてロギングを追加することなく、より多くの質問をすることができる。

高いカーディナリティ

特定のログメッセージを一意にするデータ値は、特に重要である。 例えば、リクエストIDのようなフィールドは、多くの一意な値を持つだろうが、スレッドプライオリティのようなフィールドは、そうではないかもしれない（特に単一のLambda関数では）。

マシン可読

JSONや、（カスタム解析ロジックなしで）簡単にマシンが読める他の標準化された形式を使用することで、下流のツールによる解析が容易になる。

クラウドウォッチのログ

CloudWatch Logs は、その名前からも分かるように、AWSのログ収集、集約、処理サービスである。様々なメカニズムを通じて、アプリケーションや他のAWSサービスからログデータを受け取り、そのデータにウェブコンソールやAPIを通じてアクセスできるようにする。

CloudWatch Logsの2つのメイン組織コンポーネントは、ロググループとログストリームである。 ...