ログは何に使うのか詳細に
○: デバッグ、トラブルシューティング(事後)
△: 予見: 検知 -> 主にメトリクスの役割
デバッグやトラブルシューティングに使える情報を出しましょう！
SRE本によると、Googleは常にサーバのデバッグログ全開らしい。
UT時にもデバッグに使える。
Underutilized testing strategy: test your log output. This forces you to do several things you should be doing anyway:
— ✕✕✕✕✕ (@peterbourgon) July 18, 2019
- Loggers are dependencies, not globals
- Routable log output (to in-mem buffers)
- Well-defined log schemas (structured logging)
- Deterministic components
メトリクスとの違い
- 出力物の大きさ
- 頻度。メトリクスは統計なので比較すると少ない。
ログは常時出力されます。ログ内で統計取ると負荷が厳しいことに
ログに必要な項目
コンテキスト重要
なるべくそのログ1つだけ見れば理解できるように。
ログを突き合わせるのではなく、完結させる。
L7レベルで出そう。sentryが参考になります
コンテキストを付与すれば付与するほど後で属性ごとに分析集計しやすくなります。
high cardinalityな項目が一番です。
なんとなく分解してみる。
Who: e.g. ユーザーID, UA, 会社名
Where: どのエンドポイント、どのボタン(ユーザー行動)、どのメソッド、スレッド名
Why: スタックトレース。
What: どの外部リソース/3rd party tool , バージョン(API, アプリ),コミットID
When: 時間。JST/UTCわかるように。そもそもどのタイミングでの時間か
How: リクエストパラメータ, featureフラグ(あれば), trace id 、(いわゆる)ログレベル。PCの状況(とれれば)
tips
多くの言語でスレッド名を動的につけることができる。
デフォルトだとよくわからないのでデバッグしやすい名前にするとよい。
AWSインスタンス名あたりは集約サーバ側で付与することもできる。
どういうときに出すか-> サービスやDBの呼び出しといった外部接続部分がわかりやすい
形式
構造化ログであること。だいたいJSON
メリット
- 項目が可変にできる。csvからjsonへ。並び替え自由、追加も自由、試してみて不要なら削除可能
- 例外のバックトレースなど複数行にまたがるものも対応できる
- 解析しやすい。grepからクエリ言語へ
- どうせログフォワーダーや集約基盤では構造化される
項目名は長くなっても良いので注釈無しで理解できるように、
単位やウィンドウを記載しましょう。
閲覧&可視化方法
閲覧方法まで揃って初めて役に立ちます。
ログ基盤に集約しましょう。
例
- グラフ化
- アドホック検索
- パターン分析
- またがった検索(join)
- ドリルダウン
- ブックマーク
- ライブログ(tail)
などなど。
開発環境やローカルのログも投入できると開発効率が上がります。
ツールの制約
ログ基盤は大量データを扱うことになるので原理上お値段がそこそこかかります。
似てるけど違うもの
行動ログ
用途が違うので閲覧方法を分けたほうが良いです。
閲覧とアーカイブ
アーカイブ要件と閲覧用件は異なります。
法対応で数年間の保存が義務付けられているなら、例えばS3のコールドストレージに仕舞って放置しましょう。3年分のelasticsearchはそれだけで技術的な挑戦です
注意事項
- 個人情報はログ出力の段階でマスクしましょう
- 非同期で出力しましょう
- stringの扱いに注意しましょう。string結合のタイミングでパフォーマンス劣化もありえる
- Observabilityの項目のうちロギングは比較的侵襲的な操作です。ログで障害を起こさないように！
Q&A
構造化ログだとパフォーマンスやサイズが気になります。
伝統的なログはログファイルに書き出していたので、
I/Oの負荷やローテーションの問題がありました。
Twelve-Factor Appにあるとおり、STDOUTに出すべきでしょう。
そしてログ基盤にネットワーク転送する。
そうすればパフォーマンス問題が少なくなります。
サイズもログ基盤側で圧縮されるので非構造化に比べてそこまで気にしなくて良いです。
Sentryとの使い分けは？
- フロントJSエラーを拾う
(※とはいってもnewrelicは既に対応済み。datadogは直近で対応予定) - エラーログのチケット管理に使う
- より詳細なエラーのコンテキスト確認(それがsentryの売り)
あたりでしょうか。
参考資料
日本語ではいいものがあまりないです