はじめに

この記事ではGoogle Cloud上でアプリケーションが強制終了した際の特定方法について記述します。

アプリケーションが強制終了した場合のログはわかりにくくなる

なんらかのエラーが発生した場合、trace idやrequest idをもとにリクエストに関するログを絞り込むと関連するログだけ表示されて非常に便利ではあるが、
このやり方でアプリケーションが強制終了してしまった場合の原因を特定をしようとしてもログにはなにも表示されていないか表示されていても処理が中断された旨のログしか表示されていない場合が多いです。

強制終了した場合はログ全体を確認する

アプリケーションが強制終了した際にはtrace idやrequest idでフィルタリングせずに対象サービスのログをすべて表示させるようにして上げると良いです。
これはエラーの原因がリクエスト自体ではなくその環境に依存するものが多いからです。
例としてApp Engineのメモリ消費量がインスタンスクラスで設定されたものを超過した場合のメッセージは以下のようになります。

Exceeded hard memory limit of XXX MiB with XXX MiB after servicing X requests total. Consider setting a larger instance class in app.yaml.

しかし、このエラーメッセージはtrace idに関連付けられていないログメッセージであるので、(そもそもこのエラーメッセージはアプリケーションによる出力ではなくプラットフォーム側で出力されているメッセージになります)
trace idで絞り込みを行うと例えばGoアプリケーションの場合は以下のようになります。(実装方法により出力のされ方は異なります)

context canceled

このようにtrace idの絞り込みでログを表示してしまうと本来表示したかったエラーメッセージにたどり着けない場合があります。
規模が小さいアプリケーションなら頑張って探せば見つけられますが、ログが頻繁に出力されるようなアプリケーションだと探すのは大変です。
加えて例に上げたメモリ消費量の超過エラーメッセージはログレベルがERRORではなくINFOで出力されるためより見つけにくい状態になっていました。

まとめ

• trace idでログを絞り込むと本来たどり着きたかったエラーメッセージにたどり着けない場合がある
• サービスの全体ログに出力されている場合があるが、INFOログであるため見つけにくい
• trace idでのログ絞り込みはログを見やすくするという意味では有用で、なにかおかしいなと思ったらサービス全体のログを確認するで良い

---

GI Cloudは事業の拡大に向けて一緒に夢を追う仲間を募集しています

当社は「クラウドで日本のIT業界を変革し、世の中をもっとハッピーに」をミッションに掲げ、Google Cloudに特化した技術者集団として、お客様にコンサルティングからシステム開発、運用・保守まで一気通貫でサービスを提供しています。

まだ小規模な事業体ですが、スタートアップならではの活気と成長性に加えて、大手総合商社である伊藤忠グループの一員としてやりがいのある案件にもどんどんチャレンジできる環境が整っています。成長意欲の高い仲間と共にスキルを磨きながら、クラウドの力で世の中をもっとハッピーにしたい。そんな我々の想いに共感できる方のエントリーをお待ちしています。

採用ページ