サービスへのログの転送
項目一覧
Overview
アプリケーションのサーバー側ログを MongoDB コレクションに自動的に保存したり、外部サービスに送信したりするようにログフォワーダーを構成できます。 Atlas App Services は、作成時にログを個別に転送したり、ログをバッチしてオーバーヘッドを削減したりできます。
ログフォワーダーは、次のコンポーネントで構成されています。
App Services がログを転送する方法と場所を制御するアクション。
App Services が転送するログを制御するフィルター。
App Services がログをバッチするか、個別に転送するかを制御するポリシー。
ログ転送を構成する必要がある理由
次のいずれかを実行する必要がある場合は、ログフォワーダーの設定を検討してください。
App Services の保持期間の 10 日より長くログを保存します。
ログを外部ログ サービスに統合する
Atlas Search、Atlas Online Archive、Charts のアクセス ログ
ログ転送の課金の方法
ログ転送アクションの呼び出しごとに(個々のログまたはバッチで)、1 つのApp Services リクエストとして課金されます。
ログフォワーダーを設定する
1. ログフォワーダーを作成する
新しいログフォワーダーを作成するには、 Logsページに移動し、 Forwardingタブを選択します。 次に、 Create a Log Forwarderボタンをクリックします。
次の画面で、ログフォワーダーの一意の名前を指定します。
新しいログフォワーダーを作成するには、アプリの log_forwarders
ディレクトリに新しい構成ファイルを追加します。 ファイル名は構成のname
フィールドの値と一致する必要があります。
{ "name": "<name>" }
2. 転送するログを選択する
App Services は、アプリのすべてのログを転送することも、そのサブセットのみをターゲット コレクションまたはサービスに送信することもできます。 このサブセットは、ログタイプのフィルターを定義することで、各ログフォワーダーに対して制御します(例: 関数、同期など)とステータス( 成功した場合は)、フォワーダーのアクションを呼び出します。
[ Log Type ] ドロップダウンで転送するログのタイプを 1 つ以上選択します。
Log Statusドロップダウンで転送するステータスを 1 つ以上選択します。
一致して転送するフォワーダーの 1 つ以上のタイプと 1 つ以上のステータスを指定します。
{ "name": "<name>", "log_types": [ "<type>", ... ], "log_statuses": [ "<status>", ... ] }
App Services は、次のログの種類の転送をサポートしています。
auth
endpoint
function
graphql
push
schema
service
sync
trigger
trigger_error_handler
App Services は、次のログ ステータスの転送をサポートしています。
error
success
重要
App Services は、フィルターでタイプとステータスの両方が指定されている場合にのみ、特定のログを転送します。
たとえば、 error
ステータスを持つsync
ログをフィルタリングするフォワーダーを考えてみましょう。
フィルターは、次のログを転送します。
{ "type": "sync", "status": "error", ... }
フィルターは、次のログを転送しません。
{ "type": "sync", "status": "success", ... } { "type": "schema", "status": "error", ... }
3. ログバッチの構成
App Services では、1 つのバッチ処理されたリクエストに複数のログを組み合わせてオーバーヘッドを削減できます。 App Services がログをバッチにグループ化する方法は、バッチ ポリシーによって制御されます。
App Services は次のバッチ ポリシーをサポートしています。
バッチ処理なし: App Services は、対応するリクエストが発生するたびにログを個別に転送します。
バッチ処理:フォワーダーはドキュメントが発生するたびにバッチにグループ化します。 各バッチには最大 100 個のログ エントリを含めることができます。 バッチがいっぱいになると、App Services は 1 回のリクエストでバッチ全体を転送します。 App Services は、現在のバッチ内のログの数に関係なく、少なくとも 1 分に 1 回ログを転送します。
バッチ処理を構成するには、 ポリシーまたはNo batch Batchingポリシーのいずれかを選択します。
バッチ処理を構成するには、 policy
フィールドにポリシータイプ( single
またはbatch
のいずれかを指定します。
{ "name": "<name>", "log_types": [ "<type>", ... ], "log_statuses": [ "<status>", ... ], "policy": { "type": "<single|batch>" } }
5. アクションを定義する
ログフォワーダーは、リンクされた MongoDB コレクションにログを自動的に保存したり、ログを外部サービスに送信するカスタム関数を呼び出したりすることができます。
MongoDB コレクションでのログの保存
ログをコレクションに保存するには、 To Collectionアクションを選択し、転送されたログを保持するリンクされたクラスター、データベース、コレクションの名前を入力します。
ログをコレクションに保存するには、転送されたログを保持する連結クラスター、データベース、コレクションの名前を含むcollection
のaction
を指定します。
{ "name": "<name>", "log_types": [ "<type>", ... ], "log_statuses": [ "<status>", ... ], "policy": { "type": "<single|batch>" }, "action": { "type": "collection", "data_source": "<data source name>", "database": "<database name>", "collection": "<collection name>" } }
カスタム関数でログを転送
ログを外部サービスに転送するには、ログオブジェクトの配列を受け入れ、API、SDK、またはライブラリ経由でサービスを呼び出す関数を記述します。
注意
バッチ ポリシーとログ頻度によっては、App Services が最大 100 のログ オブジェクトを含むログ転送関数を呼び出す場合があります。
この関数は、次の例と同じ署名を持つ必要があります。
exports = async function(logs) { // `logs` is an array of 1-100 log objects // Use an API or library to send the logs to another service. await context.http.post({ url: "https://api.example.com/logs", body: logs, encodeBodyAsJSON: true }); }
ログ転送関数を書き終えたら、名前を使用してログフォワーダーに割り当てることができます。
ログフォワーダーに関数を割り当てるには、 To Functionアクションを選択し、ドロップダウン入力から関数を選択します。
ログフォワーダーに関数を割り当てるには、ログ転送関数の名前を含むタイプfunction
のaction
を指定します。
{ "name": "<name>", "log_types": [ "<type>", ... ], "log_statuses": [ "<status>", ... ], "policy": { "type": "<single|batch>" }, "action": { "type": "function", "name": "<function name>" } }
6. 変更を保存して配置する
ログフォワーダーを構成したら、[ Save ] をクリックします。 配置案を有効にしている場合は、変更を必ず配置してください。
ログフォワーダーを構成したら、構成ファイルを保存し、更新されたアプリ構成をプッシュします。
appservices push
停止したログフォワーダーの再起動
ログフォワーダーは、ネットワークの中断やログを保存する基礎のクラスターの変更など、継続を妨げるイベントに応答して一時停止することがあります。 一時停止されると、フォワーダーを呼び出すことができなくなり、ログが転送されません。
中断されたログ フォワーダーは、App Services UI のLogs > Forwarding画面から再起動できます。
注意
ログフォワーダーが停止した場合、App Services はプロジェクト所有者に問題を警告するメールを送信します。