created: 2019-09-27 24:00, tags: php, laravel, logging,
サーバアプリケーションのログを取る方針、脳死でも出来る事
PHP, Laravel を今扱ってるからとりあえず前提は PHP, Laravel で。 他の環境の時も別にやる事は変わらないと思う。
サーバ業務をやってると幸運な事に色々な設計を任せて貰えるんだけど、自分が直接担当しない時にログどうしましょうかと相談されたので、そういう時に伝える基本方針を書いておく。
というか、何も知らない人は頼むからこれだけは最低限やっておいてくれって感じの内容 (そこも人によって違うからあれだけど参考にして損はないはず)。
- Laravel5.6 のログについて: https://readouble.com/laravel/5.6/ja/logging.html
ログとは
ログと一括りにすると色々あるだろと突っ込みを貰う事になるので、ここではアプリケーション保守を念頭に置いたログの事を指す。 それも (ry みたいな話はあれど、OS に踏み込んだりはせず、サーバサイドアプリケーションエンジニア (長い…) が気にするポイントを書きだしておけば迷いは消える筈。
アクセスログを取る
別に PHP に限らない話になってきそうな気がすでにしてるけど、一旦無視して、前提として HTTPD (Apache や Nginx など) のアクセスログは取る。
アプリケーションログを取る
API のリクエスト時に送信されてくる POST 等のデータ変更系のメソッドは、リクエストデータ加工前にログを吐いておく。 また、レスポンスは有無を言わさず全て取る。
GET, POST, PUT, DELETE はそれぞれ取るようにしておく (POST で投げて _method: ‘delete’ を DELETE として扱うようなフレームワークの場合、そこの考慮も忘れずやる)。 パラメータは全て保存と言いたい所だけど、クレジットカードなどの平文保存がまずいものに関しては任意のフィールドをマスク (番号を xxxxx… と他の文字列で置き換えて戻せなくする) する事ができる仕組みを入れておく。
いつ誰がサーバに訪問したか、どういうリクエストを投げたのかという情報はサービス全ての起点になるため、これを取らなかったりすると調査が不可能になったりする。
ログレベルは INFO で脳死 (プロジェクト的に理由があって変える場合は違うログレベルで吐く)。
DB 接続とかその多詳細なプログラムレベルのログについて
DB 接続エラーとか、個々の要件毎のエラーケースみたいなものはサービスレベルでどういうログが欲しいとかがあるし、この変は脳死では対応できないので、深刻度に合わせて話して決めておく。
この辺りは INFO というよりはもっと上の深刻度の高いログの為、適切な対応が必要 (本当に脳死は良くない)。 ただ、そういう書き方をすると何も設定しない人がでてきたりするので、\Exception で catch して error 詳細と使ったパラメータを吐くくらいは入れとくと良い (そのままエラーを握り潰さないようにとりあえず同じ例外を再度 throw しておく)。
DEBUG を上手く使う
少し余談。
開発していると皆 dd 挟んだりブレークポイント入れたり工夫してデバッグするけど、止めて眺める系は作業効率は良くなかったりするし、一連のデータを俯瞰して見る事に適さないので、log で吐く事を覚えると幸せになれる。
不要なコードやログを入れたくないという意見がたまにあるけど、そもそもそれは DEBUG が担う部分なので、気兼ねなく Log::DEBUG を仕込むといい。 特に共通化しているような処理 (Model レベルでのデータ整形や Service 層、Job とか視認しづらい部分は特に) に前提にしているデータと加工後のデータや返却したデータなどを吐いておくとどこでおかしくなってるかが分かるようになるのでバンバン差し込んでおくこと。
ログローテーションは必ず動作確認する
未設定の場合は必ず設定する事。 吐く場所がどこかによって変わるけど、ボリュームの空きを使いきったら (usage 100% とか) サーバが動かなくなったり心あたりの無い挙動をする事になるので。 多分監視とか入れるだろうから基本的には大丈夫だと思うけど、たまにログで使いきって死ぬサーバがいる (そもそも log のボリューム分けてないのかという話はあるが、あくまでもリスクコントロールの話)。
またローテーション設計はログの回収、バックアップ頻度、ボリュームサイズなどインフラ依存のため、担当と相談して決める。
この辺りは使ってるフレームワークでローテーションが動いてる事を確認するのと、設定、変更方法を確認しておく (後から変更が難しい場合や、変更箇所が多い場合は先に決めてしまう)。
最後に
書いてると全部脳死って訳にはいかないなーという感想になったけど、とりあえず細かい所は置いておいて、最低ないとやばいのは書けたと思う。