インフラストラクチャのモニタリング
サーバーサイド タグ設定構成を本番対応の状態へとアップグレードした後は、積極的にデプロイメントをモニタリングしていく必要があります。
デプロイメントの状態は定期的にチェックする必要がありますが、以下のタイミングは特に重要なチェックポイントと言えます。
- 環境を初めてデプロイしたとき、およびその後の何日かまたは何週間か。流入するトラフィックに対して十分な演算能力を確保できているか確認しましょう。
- 既知のトラフィック急増期の前。季節性のキャンペーンの開始前や大規模リリースの前には注意が必要です。
Google Cloud Platform には、モニタリングに便利な機能が 3 つ用意されています。Cloud Run のレポート、Cloud Logging、そして Billing レポートです。
Cloud Run レポート
サーバーサイド タグ設定環境を Google Cloud Run で実行している場合は、Google Cloud Platform コンソールの Cloud Run セクションで便利なレポート群を利用できます。
Cloud Run サービスをクリックすると、タグ設定サーバーの総合的な健康状態を確認するのに便利なレポートがダッシュボードに表示されます。
- 期間を選択すると、対応するデータが表示されます。
- [リクエスト数] カードには、サービスに到達したリクエスト数が表示されます。数値は 60 秒間隔でサンプリングされ、さまざまな HTTP レスポンス コード（2XX、4XX、5XX）に分類されます。
- [コンテナ インスタンス数] カードには、その時点でデプロイされていたインスタンス数の推移が表示されます。インスタンス数が設定した最小値を下回っている場合、選択した Google Cloud リージョンでリソース可用性に問題が生じている可能性があります。
- [コンテナ CPU 使用率] カードには、サービスの合計 CPU 使用量が表示されます。各インスタンスの CPU 使用率が 0.6（60%）を超えた際、Cloud Run で追加のインスタンスが作成されていることがわかるようになります。合計 CPU 使用率が目標しきい値に頻繁に近付いている、あるいは超過している場合は、最小インスタンス数が足りていないことを意味します。
こういったグラフやレポートでなんらかの懸念材料が見つかった場合、有効なリカバリー策として、Cloud Run ユーザー インターフェースから新しいバージョンをデプロイすることが挙げられます。その際、必ずしも設定を変更する必要はありません。これにより、サーバーサイド タグ設定環境を強制的に再デプロイできます。
サービスが稼働している Google Cloud リージョン（デフォルトでは us-central1）でリソース可用性に問題が発生することもあります。これを確認するには、Cloud Logging（後述）や Google Cloud Service Health ダッシュボードが便利です。
Cloud Logging
Cloud Run では、運用中の環境の状態に関するさまざまな便利な情報のログが、Cloud Logging という Google Cloud のサービスに書き出されています。
サービスのログを確認するには、ログ エクスプローラを使用します。
- 期間を選択すると、対応するデータが表示されます。
- クエリを入力すると、ログをフィルタ抽出できます（便利なクエリの例を下で紹介しています）。
- ヒストグラムの表示をオンにすれば、ログの重大度（例: 情報、警告、エラー）の比率をすばやく確認できます。
- リストのログをクリックすれば、そのエントリの詳細が表示されます。
以下、構成をモニタリングするのに便利なクエリをいくつかご紹介します。
システムエラーの抽出
「severity = "ERROR"」というクエリを指定すると、サービスエラーに分類されるログエントリが抽出されます。インスタンスでサービス中断やその他の異常の発生が疑われる場合は、このクエリが便利です。たとえば、重大度が ERROR のログエントリに「ZONE_RESOURCE_POOL_EXHAUSTED」という説明が含まれる場合、要請したインスタンス数を Google Cloud Platform が提供できなかったことを意味します。
失敗した HTTP リクエストの抽出
「httpRequest.status >= 400」というクエリを指定すると、サーバーサイド タグ マネージャーがエラー ステータス（HTTP ステータス 400 以上）の応答を返した HTTP リクエストのログが抽出されます。
400 エラーは通常、サーバーサイド タグ設定エンドポイントにリクエストが送られたものの、そのリクエストを獲得するクライアントがなかったことを意味します。無視してかまわない bot やクローラーからのリクエストなら問題ありませんが、運用中のデータ ストリームで 400 エラーが出ている場合、サーバー コンテナのクライアントの構成を確認する必要があります。
5XX エラーは、Google Cloud のサービス自体に関する問題を示します。たとえばヘルスチェックの失敗やロードバランサ関連の問題が考えられます。環境でリソース枯渇が発生している場合、5XX エラーも増えてくることが一般的です。
標準出力ログの抽出
「logName: "stdout" 」というクエリを指定すると、サービスの標準出力ログが返されます。このログは、サーバーサイドのリソース（クライアント、タグ、変数）がサンドボックス API logToConsole を使って関連する情報をログ化している場合に便利です。
受信 HTTP リクエストの抽出
「logName: "logs/requests"」というクエリを指定すると、実際にサーバーに届いた HTTP リクエスト自体のログが返されます。これらのログを参照できるのは、シェル スクリプトの実行や他のログフィルタの追加によってリクエストのロギングを無効化していない場合に限られます。
リストの行をクリックするとそのリクエストの詳細が表示されますが、HTTP リクエスト ボディはログでは確認できないことに注意しましょう。表示されるのはリクエストの URL と追加のメタデータのみです。たとえば POST メソッドで送信されたリクエストの場合、内容はリクエスト ボディにエンコードされているため、ログでは参照できません。
おつかれさまでした！この学習コースはこれで修了です。
コースのさらなる改善のため、ぜひアンケートにご回答ください。
次のステップ
追加のタグを構成する必要がある場合は、サーバーサイド タグ設定のドキュメントをご覧ください。
サポートのご案内
測定タグの実装についてさらにサポートをご希望の場合は、認定パートナーにご相談いただくか、コミュニティにご質問ください。