こんにちは。 今回は、「Google Cloud Monitoringを使って、サクッと監視環境を作ってみよう！」と意気込んでみたものの、予想以上に高い壁にぶつかった話を共有したいと思います。

これから同じような構成で監視を検討している方の、「やめとけ」あるいは「こうすればいいよ」という参考になれば幸いです。

今回のレギュレーション

まず、今回の検証における前提条件（レギュレーション）は以下の通りです。

  • Google Cloud 内のサービスのみを使用すること
  • アクロバットな構成は避ける（Cloud Functions や Pub/Sub を駆使すればできるかもしれないが、運用負荷が高くなる非現実的な方法はNG）
  • New Relic 等の代替としての想定（設定の手数が増えすぎては本末転倒）

第一の壁：コネクション監視（VMインスタンス ↔ Cloud SQL）

やりたかったことは非常にシンプルです。 「VMインスタンス から Cloud SQL への疎通（ポート監視・コネクション監視）を確認したい」 というものでした。

しかし、結論から言うと、標準の Cloud Monitoring のメトリクスには、直接的にこの接続を監視できるものは見当たりませんでした。

そこで、いくつかのアプローチを試みました。

策1：接続テスト（Connectivity Tests）

AIと壁打ちしたところ、「ネットワーク インテリジェンス センターの『接続テスト』を作成し、その結果をアラート通知すればいい」という案が出ました。

実際にコンソールから [ネットワーク インテリジェンス] > [接続テストを作成] と進み、送信元の VMインスタンス と送信先の Cloud SQL を指定すると、確かに接続状況の確認はできます。

 

しかし、これには致命的な問題がありました。

  1. 都度手動実行が必要： このテストは一度設定すれば常時監視してくれるわけではなく、チェックしたい時に都度実行する必要があります。
  2. メトリクスが存在しない： このテスト結果を直接 Cloud Monitoring のメトリクスとして拾う方法が見つかりませんでした。

「Cloud Functions を使って定期的にテストを実行させて…」という案もありましたが、それは今回の「アクロバットなことはしない」というレギュレーションに反するため却下となりました。

策2：稼働時間チェック（Uptime Checks）

次に目をつけたのが、Cloud Monitoring の「稼働時間チェック」です。 Cloud Monitoringでは「稼働時間チェック」という機能があるようです
詳細は省きますが、稼働時間チェックには「パブリック」「プライベート」の2種類あり、「パブリック稼働時間チェック」を使いたい場合はCloud SQLにパブリックIPアドレスの付与が必要になるので、今回は「プライベート稼働時間チェック」を使用することになります

結論から言えば、この試みは失敗しました。なぜなら、公式ドキュメント（Service Directory リソースを構成する）を見ると、対象リソースとして以下が挙げられています。

  • プライベート ネットワークの VM
  • L4 内部ロードバランサ（ILB）

「Cloud SQL」の文字はありません。 しかしこの時の私はそれに気づかず、結局七転八倒することとなります。

しかし、せっかくの検証したので、ここに記録を残しておこうと思います。

実際に行った設定手順（※結果的に失敗します）

プライベート稼働時間チェックを行うには、監視対象（今回はCloud SQL）を Service Directory に登録する必要があります。

1. Service Directory の構成

まず、Cloud Console の [ネットワーク サービス] > [Service Directory] から設定を行います。

  • 名前空間の作成： 任意の名前とリージョンを指定して作成します。

  • サービスの登録： 作成した名前空間を選択し、サービスを登録します。

  • サービス タイプ：スタンダード
  • サービス名：任意の名前
  • エンドポイントの作成： サービスの詳細画面から「エンドポイントを追加」します。

  • IP アドレス： Cloud SQL のプライベート IP
  • ポート： 3306
  • ネットワーク： Cloud SQL が存在する VPC

 

2. ファイアウォール ルールの設定

Google Cloud の稼働時間チェック サーバーからのアクセスを許可する必要があります。

  • 送信元 IP 範囲： 35.199.192.0/19 （稼働時間チェックの IP 範囲）
  • ターゲット： ネットワーク上のすべてのインスタンス
  • ※Cloud SQL インスタンスにはネットワークタグを付けられないため、このように設定します。
  • プロトコルとポート： tcp:3306 を許可

3. 稼働時間チェックの作成

いよいよ [Monitoring] > [稼働時間チェック] > [稼働時間チェックの作成] から設定します。

  • ターゲット：
  • プロトコル：TCP
  • リソースの種類：Internal IP（重要）
  • 適用先：先ほど作成した Service Directory の「リージョン」「名前空間」「サービス」を選択
  • ポート：3306
  • アラートと通知： 任意の通知チャンネルを設定

結末

設定画面の最後にある「接続テスト」ボタンを、祈るような気持ちでクリックしました。

結果は…… エラー（接続失敗）。

IPアドレスを変えてみたりしましたが、やはり（というか当然ながら）、Cloud SQL 向けにこの設定を行うことはできませんでした。
公式ドキュメントに「VM と ILB が対象」と明記されている通り、Cloud SQL のエンドポイントを Service Directory 経由で無理やり指定しても、稼働時間チェックからは認識されない（または疎通できない）ようです。

散々回り道して、この方法は「Cloud SQL には使えない」ということが実証されました。

第二の壁：監視対象の絞り込みと可読性

監視設定をしていく中で、UI やメトリクスの探しにくさにも苦戦しました。

メトリクスどれ選ぶの問題

例えば「Compute Engine の CPU 使用率を見たい」と思った時、「CPU」で検索すると大量の候補が出てきます。 うっかりリソース全体の使用率を選んでしまうと、個別のインスタンスの状態が見えません。正しくは instance カテゴリの CPU 使用率を選ぶ必要があるなど、慣れが必要です。

例えば、Compute EngineのCPU使用率を監視したい、と言うときに、なんとなく「CPU」からメトリクス探すか〜としてしまうと、

こんな感じでCompute Engineの状態ごとのCPU使用率が出てきてしまいます。

正しくは、「instance」のCPU使用率を選ぶ必要があります。

リソース特定しづらい問題

また、New Relic などの専用ツールであれば、ラベルやタグでグルーピングして「リソース名」で直感的に表示できますが、Cloud Monitoring の場合、デフォルトではインスタンス ID（1171... のような数字の羅列）で表示されることがあります。

一目で「どのサーバーのグラフか」が判別しづらく、クエリを書いてカスタマイズすれば解決するとはいえ、初見でとりあえずコンソールポチポチで手軽に設定したい、という層にはハードルが高いと感じました。

第三の壁：情報が見つからない

これが今回一番伝えたかったことかもしれませんが、「特定のユースケースに沿った監視ノウハウ」の情報が非常に少ない と感じました。

もちろん、公式ドキュメントは存在しますし、それが正義です。しかし、公式ドキュメントはいわば「哲学書の原著」のようなもので、「読んだけど、で、私はどうすればいいの？」と感じる難解な記述も多々あります。 私たちが知りたいのは、Youtubeなどに大量にアップされている「3分で分かるニーチェ」のような、噛み砕かれた実践的な「やってみた」情報なのです。

これがないと、「Cloud SQL のポート監視を Cloud Monitoring だけでやる方法」といったニッチな要件の場合、検索してもヒットせず、情報がないゆえにAIと壁打ちしてもなんだか正しくない…ということになりがちです。

最後に

監視にせよ構築にせよ、最終的には適切な設定や判断は案件に携わるエンジニア自身が行う必要があります。 とはいえ、もう少し「こういう構成ならこの設定がベストプラクティス」といった判断材料が世の中に転がっていても良いのではないか…と、今回の検証を通じて強く感じました。

また、当然と言えば当然ですが、個人的には初見で「とりあえずCloud Monitoring触ってみよう」くらいの勢いで手をつけてしまったのが良くなかったので、次回以降はもっとしっかり要件や手順を確認してから臨もうと思いました。

何はともあれ、今回の失敗談が、同じ壁にぶつかっている誰かの助けになれば幸いです。