Google Cloud Loggingの料金は、取り込んだログ1GiBあたり0.5ドル。プロジェクトごとに50GiBの無料枠があります。通常はわずかな金額に収まりますが、状況によってはコストが一気に跳ね上がることもあります。Googleはこれまで比較的寛容に対応し、返金に応じてくれるケースも少なくありませんが、その方針がいつ変わるか分からない以上、自分の手でしっかりコントロールしておくべきです。
ロギングのコストが急増する理由
これは何度も見てきた光景です。開発者がデバッグログの詳細度を上げた新バージョンをデプロイする。あるいは新しいHTTPロードバランサーを作成した際、アクセスログをストリーミングするデフォルト設定を無効化し忘れる。気づいたときには、Loggingの使用量が100倍に膨れ上がり、コストも同じペースで跳ね上がっています。
プロジェクトのコストを日常的にモニタリングしていれば、こうしたロギングコストの急増には数日以内に気づけるでしょう。しかし、そうでなければ、おなじみの「請求額ショック」を味わうことになります。
ログの取り込み量を評価する方法
他の多くのGoogle Cloudサービスと同様、LoggingもMonitoringサービスから参照できる有用なメトリクスを提供しています。
まず注目すべきは「Log bytes ingested(取り込まれたログのバイト数)」というメトリクスです。
このメトリクスのチャート例がこちらです。
取り込まれたログのバイト数をサービス別に分解 — 直近1時間
直近1時間だけを見ても明確なパターンは浮かび上がらず、異常を検出するのは困難です。
表示期間を1か月に広げると、平日(月〜金)に大量のログが生成されるという明確なパターンが見えてきます。
取り込まれたログのバイト数をサービス別に分解 — 直近1か月、青い枠が平日
これは把握可能なパターンであり、いずれかの時系列がこのパターンから外れた場合、該当サービスで過剰なログ出力が発生している可能性があると判断できます。
ログメトリクスをさらに掘り下げるには
すべてのGCPリソースが「Log bytes」メトリクスを発行しているため、たとえばApp Engineのログ出力レートだけを切り出したい場合は、次のようなチャートを描画できます。
App Engineのログ出力をドリルダウン
分析はわかった。では、どう監視する?
ご想像のとおり、誰も一日中チャートを眺めて異常が現れるのを待ちたくはありません。では、ログ出力レートを能動的に監視するにはどうすればよいでしょうか。
ログ出力レートが一日を通じて一定であれば、Monitoringのアラートポリシーを作成するだけで済みます。これにより、時系列の値が設定したパーセンテージを超えて増加するたびにアラートが発火します。
一方、ログ出力が周期的な場合、監視は少し厄介になります。ログ出力は一日のうちで変動するため、時系列の増減は想定内であり、それを基準にアラートを設定すると誤検知が頻発する原因になります。
これを回避するには、集計期間を調整して周期性を平滑化する方法があります。
時系列の周期性をならす
より長い期間で集計すれば、プロットされるデータをならすことができます。たとえば、集計期間が1分のときに次のように見えるチャートは、
取り込まれたログのバイト数 — 集計期間は1分
…集計期間を1日にするとこのようになり、
取り込まれたログのバイト数 — 集計期間は1日
…集計期間を1週間にするとこうなります。
取り込まれたログのバイト数 — 集計期間は1週間
最後のチャートであれば、いずれかの時系列が一定のパーセンテージを超えて増減したタイミングでアラートを発するのに十分使えそうです。
残念ながら、Google Cloud Monitoringは現在、アラートポリシーで25時間を超える集計期間に対応していないため、Cloud Monitoring上でこうしたアラートを組み立てることはできません。
そこで私たちはGoogleに対し、時系列が周期的な場合でもログ出力を適切にアラート化できるよう、25時間という制限の撤廃を提案しました。 機能リクエスト はすでに提出済みです。この機能に関心のある方はぜひスターを付けてください。
お読みいただきありがとうございました。 最新情報は DoiT Engineering Blog 、 DoiT LinkedInチャンネル 、 DoiT Twitterチャンネル でフォローしてください。採用情報は https://careers.doit-intl.com をご覧ください。