アドオンパートナーとしてのアプリケーションログへの書き込み

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2024年02月06日(火)

アドオンパートナーは、アプリのログストリームにデータを挿入することによって、アドオンの開発エクスペリエンスを向上させることができます。この記事では、Logplex​ 経由でアプリのログストリームにサービスを接続する方法について説明します。

アドオンとしてアプリケーションログを読み取る​場合は、代わりにこのドキュメント​を参照してください。

セットアップ

アプリの Logplex エンドポイントへのアクセス (これにより、アプリのログストリームに書き込む機能が与えられる) を取得するには、まず、アドオンのプロビジョニングリクエストで送信されるその URL を保存する必要があります。この URL は、マニフェストの requires​ フィールドに "log_input"​ 値を追加した後、初期のプロビジョニングリクエストとアプリ情報 API で使用できます。プロビジョニングリクエストのより詳細な情報は、アドオンパートナー API の仕様​で見つけることができます。以前にプロビジョニングリクエストの log_input_url​ を保存していない場合は、アプリ情報 API​ を使用してこれに対してクエリを実行できます。

トランスポート

データは、HTTP 経由で Logplex に配信する必要があります。キープアライブ接続と高密度のペイロードを使用して、顧客のログのすべてを HTTP 経由で Logplex に効率的に配信できます。単純な HTTP リクエストを示す cURL の例を次に示します。

$ URL="https://token:t.01234567-89ab-cdef-0123-456789abcdef@1.us.logplex.io/logs"
$ curl $URL \
  -d "89 <190>1 2013-03-27T20:02:24+00:00 01234567-89ab-cdef-0123-456789abcdef app procid - - foo89 <190>1 2013-03-27T20:02:24+00:00 01234567-89ab-cdef-0123-456789abcdef app procid - - bar" \
  -X "POST" \
  -H "Content-Length: 130" \
  -H "Content-Type: application/logplex-1" \
  -A 'MyAddonName (https://elements.heroku.com/addons/my-addon-name; Ruby/2.1.2)'

アドオンを一意に識別する文字列が含まれた User-Agent​ ヘッダーを必ず設定するようにしてください。

上記の例にある URL が純粋に説明のためのものであることに注意してください。この URL はアプリによって異なる場合があり、常に異なる資格情報が与えられます。これらの URL は、必要に応じてログを書き込んだり、アプリ情報 API​ からそれをフェッチしたりする必要があるインストールされたアドオンごとに保存する必要があります。

特定のアプリの log_input_url​ フィールドは変更される場合があります (資格情報をローテーションする必要がある場合など)。HTTP リクエストが 4xx​ 応答コードを取得した場合は、アプリ情報 API​ を使用して、アプリの log_input_url​ が変更されたかどうかを確認してください。その場合は、アプリのレコードを更新して再試行します。

形式

リクエストのヘッダーには Content-Length​ と Content-Type​ が含まれている必要があります。Content-Length​の値は、本体のバイト長の整数値である必要があります。Content-Type​の値は application/logplex-1​ である必要があります。

HTTP リクエストの本体には、長さで区切られた Syslog パケットが含まれている必要があります。Syslog パケットは RFC5424​ で定義されています。次の行は、RFC プロトコルを要約しています。

<prival>version time hostname appname procid msgid structured-data msg

prival​ には <190>​ (local7.info) を、version には 1​ を使用できます。time​ フィールドは、このログ行が rfc3339​ 形式で作成された時刻に設定する必要があります。hostname​ は、アドオンが関連付けられたアプリの ID に設定する必要があります。appname​ フィールドは常に app​ に設定する必要があります。procid​ は Logplex では使用されませんが、heroku-postgres​ などのログを出力しているプロセスを識別するための優れた方法です。同様に、msgid と structured-data も Logplex では使用されず、値 -​ を使用する必要があります。最後に、msg は、ログメッセージを保存できるパケットのセクションです。

メッセージの規則

ログメッセージは、人間の読みやすさとマシンの解析可能性の両方のために最適化された方法で書式設定する必要があります。それを念頭において、ログデータは次のようにすべきです。

  • 1 つのメッセージで構成されるようにします。
  • 形式 status=delivered​ のキーと値のペアを使用します。
  • マシンまたは環境を区別するためのログ行には source​ のキーと値のペアを使用します (例: ​source=us-east measure#web.latency=4ms​)。
  • 具体性の低いものから高いものへの順に、ドットで階層を示します (例: ​measure#queue.backlog=​)。
  • 単位は数値のすぐ後に置く必要があり、a-zA-Z​ のみで構成されている必要があります (例: ​10ms​)。

頻度の高いイベント

これらは、ログコンシューマーによる統計的な集計でメリットが得られるログイベントです。

measure#elb.latency.sample_count=67448s source=elb012345.us-east-1d

事前に集計された統計

サービスが定期的に、ユーザーのログストリームに事前に集計されたメトリクスを挿入することがあります。 このイベントには、データベーステーブルの合計数、アクティブな接続数、キャッシュの使用状況が含まれている可能性があります。

sample#tables=30 sample#active-connections=3
sample#cache-usage=72.94 sample#cache-keys=1073002

Postgres でのログ記録の経験では、1 分に 1 回が集計メトリクスを報告するための妥当な 頻度であることが示されています。これより頻度が高いと、雑音が多すぎるか、 ストレージ/分析のコストが高くなりすぎる可能性があります。アドオンのメトリクスを定期的に記録する ことを選択する場合は、この点に注意してください。

増分カウンタ

count#db.queries=2 count#db.snapshots=10