2023年は「Cloud Run を触って覚える」をテーマとした ひとりアドベントカレンダー を開催しており、Cloud Run のさまざまな機能や Cloud Run でよく使う構成などをご紹介しています。
23日目は Cloud Run のモニタリングとロギングの基本的な機能について紹介します。モニタリングとロギングの機能は多機能ですが情報量も多いので、全体感が掴めるようにまとめてみました。
Cloud Run の概要は「gihyo.jp」で解説していますので、こちらもぜひご覧ください。
Cloud Run コンソールで簡単にログやメトリクスを確認できる
Cloud Run では、アプリケーションへのカスタマイズを行わずとも、自動的に出力されるログや自動的に収集されるメトリクスがあります。そのため、モニタリングのための特別な設定や構成は必要ありません。
そしてそれらの情報は Cloud Run のコンソールからアクセスできます。つまり Cloud Run は Cloud Run コンソールから最小限のモニタリング・アラートが可能になっているということです。
Cloud Run コンソールの各メトリクスの確認
全体の構成
Cloud Run では Google Cloud の運用のためのサービス群 オペレーション スイート に含まれる Cloud Logging や Cloud Monitoring、Cloud Trace といったサービスと連携しており、ログやメトリクスはこれらのサービスに送信されています。Cloud Run のコンソールから確認できるログやメトリクスは、Cloud Logging や Cloud Monitoring で収集したデータが表示されています。
モニタリングとロギングの全体構成
オペレーション スイートでは、ログやメトリクスについてより柔軟な設定が可能です。カスタム ダッシュボードを作ったり、アラートを設定したり、ログを元にメトリクスを作ったりすることができます。
ひとまずシンプルに稼働状況を確認したい場合は Cloud Run コンソールで見ておき、より柔軟なモニタリングをしたい場合はオペレーション スイート (Cloud Logging や Cloud Monitoring など) を使用するようにしましょう。
ログ
Cloud Run にはリクエストログとコンテナログの 2 種類のログがあります。ログについては、次のドキュメントもあわせて確認してください。
リクエストログ
Cloud Run サービスに送信されたリクエストのログです。自動的に記録されるため、自分で設定を行う必要はありません。
リクエストログの一例
ペイロードには HTTP ステータスコードやユーザーエージェントなど、リクエストとレスポンスに含まれる一般的な情報が含まれています。リクエストログを使って、エラーレスポンス率を集計したり、リクエスト・レスポンスに関連する問題の調査などを行うことができます。
コンテナログ
コンテナ インスタンスから出力されたログです。コンテナ インスタンス内で以下のいずれかに出力されていれば、Cloud Logging によって自動的に収集されます。
- 標準出力 (
stdout) または標準エラー (stderr) ストリーム /var/log- syslog (
/dev/log) - Cloud Logging クライアントライブラリ (SDK) 経由で作られたログ
フレームワークなどを使っている場合は、上記のいずれかに出力されるような仕様であればフレームワークのログも自動的に収集されます。そうではない場合は上記の場所に出力する設定が必要です。
メトリクス
モニタリングやアラートに必要とされるメトリクスの多くは標準で収集されています。そのため最初から独自で収集する必要はありません。
例えば次のようなメトリクスです。
| メトリクス | 名前 | サービス | ジョブ |
|---|---|---|---|
| 課金対象のコンテナ インスタンス時間 | container/billable_instance_time |
✅ | ✅ |
| コンテナの起動時のレイテンシ | container/startup_latencies |
✅ | ✅ |
| コンテナの CPU 使用率 | container/cpu/utilizations |
✅ | ✅ |
| コンテナのメモリ使用率 | container/memory/utilizations |
✅ | ✅ |
| 送信バイト数 | container/network/sent_bytes_count |
✅ | ✅ |
| 受信バイト数 | container/network/received_bytes_count |
✅ | ✅ |
| リクエスト数 | request_count |
✅ | |
| リクエストのレイテンシ | request_latencies |
✅ | |
| コンテナ インスタンス数 | container/instance_count |
✅ | |
| 最大同時リクエスト数 | container/max_request_concurrencies |
✅ | |
| 完了した実行 | job/completed_execution_count |
✅ | |
| 処理中の実行 | job/running_executions |
✅ | |
| 完了したタスクの試行 | job/completed_task_attempt_count |
✅ | |
| 処理中のタスクの試行 | job/running_task_attempts |
✅ |
これらのメトリクスについて、グラフを作ったり、あるしきい値に達したら通知するアラートを設定したりできます。
モニタリングやアラートを設定する上では、まず「なるべく標準のメトリクスを活かして行いたいモニタリングの要件が満たせるか」考えた方が、手間もかからずに済むため良いでしょう。
全ての標準で収集されるメトリクスの一覧と説明は、次のページを参照してください。
メトリクスのモニタリング方法については、次のドキュメントもあわせて確認してください。
カスタム メトリクスの作成
標準のメトリクスでは収集されない独自のメトリクスを収集したい場合は、OpenTelemetry サイドカーを使って収集する方法がおすすめです。
サイドカー (マルチ コンテナ) は今年 (2023年) にリリースされた Cloud Run の新しい機能です。サイドカーを使って構築することで、メトリクスを収集する処理をアプリケーションとは別なコンテナとして動かすことができます。
設定方法は次のドキュメントを参考にしてください。
ログベースのメトリクスの作成
Cloud Monitoring では、特定の条件に合致するログを集計し、メトリクス化することができます。この機能によって、特定の期間における特定のログの発生頻度を条件としたグラフやアラートを設定することができます。
ログベースのメトリクスを使うと、例えば「特定の期間に "あるログ" がしきい値以上の件数発生した」といったようなアラートを設定することもできます。
設定方法は次のドキュメントを参照してください。
アラート
アラートは Cloud Monitoring で設定することができます。アラート ポリシー (条件) を設定し、条件が満たされた場合にインシデントが作成され、通知チャネルに通知されます。
詳しくは次のドキュメントを参照してください。
アラート ポリシーは大きく分けて 2 種類のポリシーがあります。
メトリクスベースのアラート ポリシー
メトリクスと時系列を組み合わせた条件を作り、アラートを飛ばすことができます。具体的には「1 時間のうちに 10 件以上の 500 エラーが発生したらアラートを飛ばす」といった条件を作ることができます。
メトリクスを時系列予測する機能も現在プレビューで提供中です。過去のメトリクスから時系列予測し、しきい値を超えることが予測されたらアラートを飛ばすといったことができます。例えば「トラフィックの増加に前もって対応する」といったようなユースケースに役立ちます。
ログベースのアラート ポリシー
ログに特定のメッセージが含まれていたらアラートを飛ばすといった設定が行えます。
ログベースのメトリクスと似ていますが、ログベースのアラート ポリシーは条件に合致するログが 1 件でも発生したらアラートが飛びます。「条件に合致したログの件数がしきい値以上だったら」というアラートを設定したい場合はログベースのメトリクスを使うようにします。
合成モニタリング (外形監視)
合成モニタリングは外形監視とも呼ばれる、サービスの外側から正常に稼働しているかどうかをチェックする機能です。Cloud Run サービスを実際にリクエストし、そのレスポンスを確認し正常に稼働しているかどうかをチェックします。
合成モニタリングには 3 つの設定を提供しています。
- 稼働時間チェック : HTTP、HTTPS、TCP のエンドポイントを定期的にリクエストします。プライベート エンドポイントもチェックできます。
- 合成モニター : HTTP または HTTPS のエンドポイントへのテストを Cloud Functions 経由で実行できます。テストコードは自由にカスタマイズできます。
- 無効なリンクチェッカー (プレビュー) : URI を定期的にリクエストし、URI で構成可能なリンク数をチェックします。
SLO モニタリング
Cloud Monitoring では、各メトリクスを使用して SLO (サービスレベル目標) を基準としたモニタリングが行えます。SLO をダッシュボードで確認したり、しきい値を下回ったらアラートを飛ばすといった設定が行えます。
Cloud Run では、標準で収集しているログ・メトリクスを使って SLO モニタリングを簡単に設定することができるようになっています。細かくメトリクスを指定する必要がないため、クイックに SLO モニタリングを始めることができます。
次のブログでは、SLO モニタリングの使い方を解説しています。ぜひご確認ください。
まとめ
Google Cloud ではオペレーション スイートを通してモニタリング・ロギングの機能を数多く提供しています。使い方は多岐に渡りますが、この記事を読んで全体感をなんとなく掴めることができたら嬉しく思います。
色々な手法はありますが、まずは何といっても手軽にチェックできる Cloud Run コンソールからグラフやログをチェックするところから始めてみて、より細かくチェックしたくなったらオペレーション スイートの機能に触れていくのがおすすめです。
Discussion