30代からの再勉強日記(ビジネス系/IT系の一般論の理屈を考えてみる)

徐々に、新たなタスクを起こし任せる側になりました。将来検討のためにも、一般論やセオリーを勉強・考察し外部へ共有する事で学びを深めたいと思います。皆さんにも役立つ所があれば幸いです。※最近ミッション変更となり、更新頻度落が落ちます。

【IT勉強】 ログ設計方針の確認を求められた時に備えてみた (全部取れでは意味がないので)

 エラーが発生した際に、根本的な対応策の検討および改修するためには、その時エラーが発生した時の状況がわかるログを確認する必要があります。ただし、エラーが起きた後に当時のログ出力させる事はできないので、システム開発時にログをどのように残すべきか考える必要があると思います。実際の細かいログの設計はプロに任せるとして、発注側で考えるべき事をまとめてみました。

 

■備忘メモ

 ●大前提として、ログの役割を整理すること。

 -監視、エラー対応、マーケティング活用など、そもそもログを何の目的でとるか検討し、関連メンバで認識をあわせる事

 

 ●ログが必要な時に使えるように準備しておく事(消えない事)

 -あるハードに障害が起きて起動しなくなったとする、その際に、同一ハードにしかログがない場合はログが確認できず、原因が掴めない恐れがある。

 ※別途、ログ保存領域が具備されている物なら、ベンダなら拾える可能性はあるが・・・ログを見て対応する原因解析や説明根拠を用意する時間が長くなる。

 (ログ収集サーバでストレージを多く積んだサーバを別途用紙するのが通例)

 

 ●ログを見やすくする事

 -緊急度の基準を考え、特定の緊急度以上のログだけを表示するなど工夫する。

  例、Syslogの基準を参考にするならば、出すべきログを下記のように分け、それぞれ割り当てておく。  

      <Syslogの緊急度>

   debug デバッグ情報

   info 情報

   notice 通知

   warn 警告

   err 一般的なエラー

   crit 致命的なエラー

   alert 緊急に対処すべきエラー

   emerg システムが落ちるような状態

※また、crit以上なら、呼び出し、それ未満はメール通知等のエスカレ判断に使用。

 

 ●解析しやすように出力を工夫する事

 json形式にしておくなど後々解析しやすいようにな出力だと活用が楽になる。

 

 ●時刻を正確に記す事

 特に、エラー対応時にどの処理がどのように発生したのか時系列で追うためにも、時刻を正確に整えておく事。

 (ntp/sntp、特にntpの方がより正確なんですかね)

 

 ●5W1Hを意識して出力項目をととのえる事

 誰が、いつ、どこで、何を、どうしたのか、どのような処理かなど、そのログを見て目的とする事が可能ななのか確認する。

 

 ●ログ保存期間を定める事(保存しきれないので、上書きする)

 法律対応、監査対応、ユーザからの問い合わせ対応などを考慮して、ログ保存期間を決定する。それに応じて、ログ保存期間を超えた古いログは破棄する、最新のログで上書きするローテションを行い、不必要にストレージを使用しない。

 

 ●残してはいけないログを書かない事。

 個人情報など記載してはいけないログもある。設計に含まれていないか、本番稼働時に出力されていないか、確認する。

 

 ●改ざんされない事

 ログをいいように改ざんされると攻撃者を検知できなくなるので、セキュリティを担保すること。

 ※内部不正防止や監査としても必要ですね。

 

参考)Software Design 2014/08号

   Software Design 2020/07号

 

■まとめ   

 自分で一つ一つのシステムのログ設計を行う機会は、開発者以外は少ないと思いますが、後々に困らないように開発・運用側だけで設計してくれというのも負担が大きいので、ビジネスにも応用がきくように性能面を記録しておくとか、トラブル発生時に理由が説明できるようにさせておきたいなど、要望をつたえてそれを満たすしている設計かどうか確認する事がベターかなと思いました。

 勿論、これ以外の観点もあるかと思いますが、もし発注者側でログどうしますか?と問われた時や、質問ありますか?という時にログについても完全にお任せではなく、上記の考えで一緒によいシステムを開発できればと思います。

 ※細かい所までつっこんでくるな~と敬遠されるかも・・・