![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2023-03-15T00:48:50+00:00","default:admin","admin") #author("2023-03-15T08:02:15+00:00","default:admin","admin") -[[ログ管理のベストプラクティス:https://newrelic.com/sites/default/files/2022-09/new-relic-2022-log-management-best-practices-white-paper%202022-09-19%20JP.pdf]] *保存期間 [#v058d944] -[[「結局アクセスログってどれくらい保存しておけばいいの？」に答える関係法令:https://qiita.com/yamotuki/items/628f9bf399cc9b59f3cb]] -[[監査証跡の適切な保存期間はどれくらいか:https://www.weeds-japan.co.jp/column/20200528_518/]] *ログ記録 [#ad3fd225] -[[ログ管理のベストプラクティス:https://newrelic.com/sites/default/files/2022-09/new-relic-2022-log-management-best-practices-white-paper%202022-09-19%20JP.pdf]] **フルスタックオブザーバビリティのためのログ記録 [#o0914bf0] ***必要なものを記録する [#la8b7575] -最も重要な判断は、何をログに含めるかを選別すること -ログには、調査する際にイベントと根本原因の特定に役立つ全ての必要なメタデータを含めるべき -ログのメタデータの構成要素には、エラーメッセージまたはスタックトレースと、それらに関連する値、メトリクス、イベントなどが含まれる場合がある -組織のログの全てのデータには、目的を持たせるべき -データは、使用率であれ、ユーザーイベントであれ、アプリケーションのエラーと例外であれ、チームにとって価値があるべき -ログデータ情報の要件： --何らかの形ですぐに役立つ --根底にある原因を理解し、判断を下すために必要な詳細情報を提供する ***共通のシナリオを予想する [#s8251354] -共通のシナリオを幾つか念頭にログ記録を取ることにより、ログは組織に直接的な価値をもたらすようになる --ユーザー同士の行動に関するログは、顧客体験に関する重要な洞察をもたらす --システムログにより、問題やハードウェア障害を監視できる --アプリケーションに関する詳細なログは、パフォーマンスとメモリリークなどの潜在的な問題への洞察をもたらす ***有意義なメッセージを記録する [#a9c1ed66] -アプリケーションエラーの場合、メッセージはその命令行で何が起こっているかを伝える必要がある -トランザクションに関するデータを含むログは、トランザクションが失敗した理由を開発者やエンジニアが確認するのに役立つ -ログに簡潔な説明を加えると、トラブルシューティングの際に他の開発者やエンジニアの時間と労力を節約できる ***ログは常にシンプルで簡潔にする\ [#y1e524dc] -過剰で不必要なデータをメッセージに含めると、ログのストレージサイズとコストが膨れあがり、ログ の検索が遅くなり、本質的な問題から遠ざかり、デバッグがいっそう面倒なものになってしまうので注意 -ログには、不要なノイズを避けつつ、エラーが発生した理由を含めるべき -エラーの根本原因に関する情報を提供すべき --アプリケーションが内部APIに接続できずデータを取得できなかった場合、APIからのエラーメッセージまたは環境のネットワーク状態に関する情報をログに記録すると役立つことがある --アプリケーションが使用するメモリの量や実行中のアプリケーションの数を含める必要はない ***時刻の記録 [#g5d09436] -納得のいく最も細かいレベルを選択し、ログに出力する必要がある -潜在的に明白かつ重要な注意点は、全てのシステムを同時に同期させ、オブザーバビリティプラットフォームがタイムスタンプを使用して、ログイベントを他のテレメトリデータと関連付けられるようにすること **ログフォーマット [#hbcd39e3] ***解析可能なログフォーマットを使用する [#sbff6a9b] -一貫性のあるログ構造を維持できるログフォーマットを使用して、収集と集計を容易にすべき -構造化ログを推奨 ***ログレベル [#mf2d6fa4] -ログのレベルは、イベントの相対的重要性を説明し（デバッグ、情報、警告、エラー、致命的などの観点で）、ロギングフレームワークから得た情報の密度も説明してくれる -ログレベルを有効活用すれば、データ量を制限し、集中ログ管理ツールの使用コストを節約し、検索が迅速になる -チームはログレベル、特にデバッグログレベルを注意して使用すべき --特定の動作に伴う冗長なメッセージを取得するのにデバッグは大いに役立つが、不必要なデバ ッグは膨大な量のログをもたらし、付加価値を提供することなくログの取り込みと検索機能の速度を低下させる --規模の大きなチームとプロジェクトは、一貫性のあるグループ化、カテゴリー化、およびログ記録方法に関するログレベルの基準から恩恵を受けることがある **ログに加えるべきでないもの [#k88e8815] ***機密情報 [#s45b7173] -機密情報は慎重に取り扱う必要があります。個人識別情報（PII）およびクレジットカード番号などの規制データは、欧州連合の一般データ保護規則（GDPR）3および米国の医療保険ポータビリティおよび説明責任法（HIPAA）などの規制法に従って保護することが不可欠 -オープン・ウェブ・アプリケーション・セキュリティ・プロジェクト（OWASP）のロギングガイドラインには、記録すべきでないものが記載されている --例えば、アクセス用トークン、パスワード、機密情報、個人が明かしたくない情報など -特定のユーザーの行動またはイベントの追跡に際しては、匿名の識別子を使用する必要がある *構造化ログ [#eb230a40] -[[構造化ログとは？:https://qiita.com/KtheS/items/0c1a6938c9ecd9950d4a]] -[[Amazon CloudWatch Logs に出力するログは JSON 形式だと分析が楽になるかもしれない話:https://engineering.nifty.co.jp/blog/13997]] --CloudWatch Logs に格納するログは JSON 形式 (構造化ログ) にしたほうが、 Logs Insights のクエリが簡潔になり、検索・分析・データ抽出が楽になる --しかし、ログサイズの肥大化に伴い、コストが増えることもあるので、不必要なデータは出力しないなどの工夫が必要 **Pros&Cons [#oec1b83b] ***Pros [#p8a2c3c7] -ログフォーマットごとにパーザを用意しなくてもよくなる -各フィールドに名前がついているので、データそれ自体から意味を読み取りやすい (自己記述的である) -フィールドの追加が容易である -[[jq:https://stedolan.github.io/jq/]] や [[jr:https://github.com/yuya-takeyama/jr]] を活用することであらゆる UNIX コマンドと組み合わせることができる ***Cons [#kcfe7a44] -ログサイズの肥大化 **その他 [#d35fadcb] -[[JSON ログ - Site24x7:https://www.site24x7.jp/help/log-management/json-logs.html]] *フォレンジック [#v9342996] -[[【フォレンジックとは】セキュリティ担当者必見！ 意味や調査方法を解説:https://and-engineer.com/articles/YujtphAAACIAQldP]] -[[デジタルデータは裁判で使用できる？証拠能力を持たせる方法や注意点について徹底解説:https://cybersecurity-jp.com/column/43469]] -[[第2回 過去ログの“証拠力”と生ログの“予測力”:https://xtech.nikkei.com/it/article/COLUMN/20110621/361575/]] -[[テーマ2 意外に脆弱？セキュリティ担当者が見る企業システムの裏側:https://jpn.nec.com/cybersecurity/journal/02/discussion02.html]] -[[AWS 上でフォレンジック調査環境を構築する際の方策:https://aws.amazon.com/jp/blogs/news/forensic-investigation-environment-strategies-in-the-aws-cloud/]] *AWS [#i299536a] -ログをS3と監視SaaS両方に飛ばすなら、Kinesis Firehose を使うと良い --Cloudwatch Logs だとコストがかかってしまう
