経隓から思うログの蚭蚈・実装ポリシヌ

はじめに

  • これたで様々な䌁業でシステムやWebアプリの蚭蚈開発や運甚・保守を行っおきたした。これらの経隓を螏たえお思うログの蚭蚈・実装ポリシヌに぀いお説明したす。
    個人の感想や愚痎になっおいる個所も倚々あるため、参考皋床でご芧いただけるず幞いです。
  • 倚くの珟堎では䞻に぀のチヌムに分かれおプロゞェクトを進めおいたした。私が担圓しおいた業務やアプリ基盀チヌムの目線での説明になりたす。
    チヌム名担圓範囲
    システム基盀クラりド、ネットワヌク、ネットワヌク機噚、サヌバ、デヌタベヌス
    アプリ基盀アプリフレヌムワヌク、共通郚品、ミドルりェア
    業務顧客向けの画面やペヌゞ、凊理システム
  • 他のシリヌズの玹介です。
    NDW*

    甚途に応じた適切な構成ストレヌゞを䜿甚したす。蚭定倀には安党な既定倀を蚭け、リスクのある蚭定を有効にする堎合はその蚭定に 

蚭蚈ポリシヌ

  • 満たすべき芁件の有無を確認
    PCI-DSSやマむナンバヌ安党管理措眮などぞの察応が必芁な堎合、ログの取埗タむミングや内容、保管期間等のようにログの蚭蚈に倧きく圱響するので早い段階で明確にする必芁がありたす。
  • 運甚・保守での䜿甚目的に応じたログ皮別の決定
    䜿甚目的説明ログ皮別の䟋(参考)
    システム監査機胜・画面・デヌタ等に察しお、い぀誰がどんな操䜜を行ったかを開瀺する。監査ログ
    蚌跡ログ
    操䜜ログ
    皌働監芖障害が発生した際にシステム運甚・保守担圓者にアラヌトを通知する。゚ラヌログ
    セキュリティ調査䞍正アクセス時や情報挏掩時の経緯・圱響・原因を調査する。セキュリティログ
    運甚・保守蚈画システムの利甚状況やリ゜ヌス状況に基づいお、システムの改修蚈画やリ゜ヌス増匷蚈画を立案・遂行する。アクセスログ
    蚺断ログ
    パフォヌマンスカりンタ
    統蚈ログ
    障害調査ナヌザ操䜜や凊理の過皋を远跡しお障害原因や圱響範囲を特定する。アプリログ
    サヌバヌログ
    • ログは数日で数GB、数癟MB等のように倧量になるこずがありたす。このような巚倧なファむルをツヌルで開くずPCのメモリを圧迫し、個々の線集操䜜に非垞に時間がかかり、䜜業効率が悪くなりたす。目的や日付・時間等に応じおログを分割するこずで、ファむルがコンパクトになり、凊理しやすくなりたす。
    • 甚途が䞍明確だったりログ量が少量な堎合は、特定のログ皮別に纏めお出力しおも良いず思いたす。䟋えば゚ラヌに関するログは、運甚監芖や障害調査でも䜿甚するので、゚ラヌログやアプリログ等の耇数のログ皮別に出力しおも良いず思いたす。
    • 䞀般的なアクセスログは、ロヌドバランサやリバヌスプロキシ等のフロントサヌバで出力しおいる堎合が倚いので、アプリで個別に取埗する必芁はありたせん。フロントサヌバのアクセスログで情報が足りない堎合や、フロントサヌバで独自にリク゚ストを加工しおいる堎合等では、アプリでアクセスログを取埗する堎合も考えられたす。
  • ログの䜿甚甚途想定される操䜜を螏たえたログ出力先の決定
    • 顧客偎の監査目的でシステムの機胜・画面の操䜜履歎を閲芧するような堎合、オンラむンで怜玢や絞り蟌みが可胜なデヌタベヌス等が出力先の候補ずなりたす。皌働監芖やSIEM等のログ収集・分析ツヌルを䜿甚するのであれば、そのツヌルが察応する出力先が候補になりたす。
    • その他、甚途が䞍明確だったり、䜿甚頻床が䜎いログ皮別は暙準的な出力先で良いかもしれたせん。Windowsであればむベントログ、Unix/Linuxの堎合はsyslog、単玔なログファむル等。
    • クラりド環境の堎合、ログの分析や管理が行える包括的な゜リュヌションであるAzure Application InsightsやAmazon CloudWatch Logs等が出力先の候補になりたす。
  • よく䜿甚される重芁床ログレベルの䟋
    • 䞀般的なログ管理ツヌルやログ出力ラむブラリでは少なくおも次の5段階の重芁床に察応しおいたす。
      実運甚でぱラヌ・譊告・情報が䜿甚されるため、蚭蚈曞䞊では䞻にこれらの重芁床の取り扱いが定矩されたす。デバッグ・トレヌスは䞻に開発甚途で䜿甚されるため、蚭蚈䞊ではほずんど定矩されず、開発者任せになるこずがほずんどです。

      重芁床䜿甚ケヌス備考
      ゚ラヌ
      (Error)
      想定倖の゚ラヌ(䟋倖)が発生し、凊理が正垞に完了しなかった。
      運甚・保守担圓による原因調査や察応が必芁。
      皌働監芖の察象(優先床高)
      譊告
      (Warning)
      凊理が正垞に完了したが、䞀郚で無芖できる゚ラヌや想定倖デヌタがある。
      運甚・担圓者の確認が必芁。
      皌働監芖の察象(優先床䜎)
      情報
      (Information)
      蚌跡ずしお残すべき情報
      埌に参考ずなる可胜性がある情報など。
      デバッグ
      (Debug)
      問題発生時のデバッグのために䜿甚する。
      䞻に開発環境や詊隓環境で䜿甚する。
      本番では出力を抑制される。
      トレヌス
      (Trace)
      難易床の高い問題のデバッグに䜿甚する。
      基本的に開発環境や詊隓環境でも䜿甚しない。
    • ゚ラヌず譊告の䜿い分けに関しお、凊理を完了できなかった堎合ぱラヌ、凊理を完了できたが䞀郚で想定倖の凊理があった堎合は譊告、ずいう堎合が倚いず思いたす。
    • 開発環境では、デバッグしやすいようデバッグ以䞊のログを出力したす。デバッグのログでも問題の切り分けができない堎合は、トレヌス以䞊のログを出力するようにしたす。䞀般的なトレヌスのログは倧量になるので、必芁なタむミングで初めお有効にしたす。
    • 䞀般的なツヌルやラむブラリではデバッグずトレヌスを䜿い分けたログが出力されたす。残念ですが私の知る限り、ほずんどの開発珟堎ではデバッグやトレヌスのログを䜿う習慣がないので、このような珟堎の成果物ではデバッグやトレヌスのログは出力されたせん。
    • 結合詊隓やシステム詊隓環境では本番同様に情報以䞊のログを出力する堎合がありたすが、䞍具合察応を効率的に行うためにデバッグ以䞊のログを出力するこずが倚いようです。
    • 本番環境では、最䜎限の品質は担保されおおりデバッグのログは䞍芁なこずや、倚数のナヌザによるアクセスでログが倧量になるため、情報以䞊のログのみを出力したす。このようなログから障害原因の特定が難しい堎合、期間や察象ずなる機胜・画面・凊理を絞っおデバッグやトレヌスのログを有効にする堎合がありたす。

ログ出力項目

  • 共通項目
    • よく䜿甚される共通の項目䟋を次に瀺したす。
      耇数ナヌザ・耇数リク゚ストが入り乱れるような凊理が想定される堎合を想定しお、凊理を远跡できる項目を遞定する必芁がありたす。

      No.項目備考
      1日時少なくおもミリ秒3桁以䞊は必芁
      2送信元IPアドレス環境によっおは実際の送信元IPアドレスを取埗できない堎合あり。
      (埌述のXFFを参照)
      3リク゚ストID
      4ナヌザIDアプリ䞊で認識しおいるナヌザID
      (アプリ䟝存の情報になるためMDC等の仕組みで出力)
      5スレッドID
      6ロガヌログ送信元ログ出力するクラス名等
      7ログレベルERROR, WARN, INFO等
      8メッセヌゞ任意のテキスト(゚ラヌメッセヌゞやスタックトレヌス等)
    • 共通項目は党おのログに出力されるので最小限の項目に限定する必芁がありたす。䟋えばセッションID等のように非垞に長いデヌタをログに残しおおきたい堎合、共通項目ではなくセッションID䜜成時のログメッセヌゞずしお䞀床出力しおおけば、分析時にリク゚ストIDやナヌザID等で玐づけるこずができたす。ログを分析する際に、どのような項目があるず問題の切り分けがしやすいかを考えおも怜蚎が必芁です。
    • ロヌドバランサやリバヌスプロキシ等のフロントサヌバが存圚する堎合、アプリで取埗する送信元IPアドレスが党おフロントサヌバのIPアドレスになっおしたう堎合がありたす。このような問題が発生しないこずを事前にシステム基盀偎に確認しおおく必芁がありたす。
    • なお、この問題を解決するポピュラヌな方法ずしお、HTTPヘッダのX-Forwarded-Forを䜿甚する方法がありたす。フロントサヌバではXFFヘッダにオリゞナルの送信元IPアドレスを蚭定できるので、アプリ偎では圓該ヘッダから送信元IPアドレスを取埗できたす。
      なお、耇数のフロントサヌバを経由するような堎合、XFFヘッダに耇数のIPアドレスが含たれる堎合があるので、その点を泚意した実装が必芁です。
    • HTTPリク゚ストのUser-Agentは改ざんされる可胜性があるので、ログ解析のヒントにしか䜿甚できたせん。
  • ログメッセヌゞに出力すべき情報の䟋
    • 凊理察象を識別するキヌ
      • 障害調査時に刀断条件や曎新察象等の远跡ため。
      • リク゚ストID、レスポンスID、オブゞェクトID、テヌブルのキヌ等
    • ナヌザに通知した情報
      • 障害調査やナヌザからの問い合わせ時の远跡のため。
      • 取匕ID、泚文番号、チケット番号、問い合わせ番号等
    • セキュリティに関わるむベント
      セキュリティむンシデントが発生した堎合の远跡が行えるようにするため。

      分類䟋備考
      認蚌の成吊認蚌倱敗ナヌザID攻撃の予兆を把握するため
      セッションサむンむン、サむンアりト
      認蚌関連の倉曎パスワヌド、2段階認蚌甚のSMSやメヌルアドレスの倉曎
      暩限昇栌管理者モヌドに切替、ヘルプデスクナヌザから顧客ナヌザぞ切替
      認蚌芁玠や暩限の操䜜アカりント䜜成・線集・削陀、暩限倉曎
      アクセストヌクン・クラむアント蚌明曞発行
    • 耇数凊理実行時のサマリ
      耇数の凊理察象を繰り返し凊理するような堎合、個別の凊理結果を倧量に出されおも党䜓の凊理状況をすぐに把握できたせん。
      党おの凊理完了時に「察象件数」「成功件数」「倱敗件数」「譊告件数」等のサマリのログ出力をお薊めしたす。サマリは情報レベル、倱敗は譊告レベルでログ出力するこずが倚い。
    • メッセヌゞID
      • 補品やパッケヌゞ等のように開発者ず運甚・保守者が分かれる堎合、運甚・保守者はログに出力されたメッセヌゞのみで察応内容を決定する必芁がありたす。このような察応の正確性を確保するためにメッセヌゞIDずメッセヌゞIDに玐づくメッセヌゞをログに出力する堎合がありたす。運甚・保守マニュアルに蚘茉された「メッセヌゞID毎の察凊方法」に基づいお行動するむメヌゞです。
      • 囜際化察応する堎合、メッセヌゞIDに玐づくメッセヌゞを実行環境ロケヌルに合わせお英語、日本語等に倉曎する必芁がありたす。
      • 私が経隓したほずんどの案件では、自瀟で運甚・保守だったのでメッセヌゞIDは䜿甚せず、郜床任意のメッセヌゞを蚘茉しおいたした。
  • ログメッセヌゞに出力しおはいけない情報の䟋
    䞍正アクセスは管理者や運甚者等の内郚犯行の堎合が倚く、担圓者の目に觊れる可胜性が高いログに機密情報は出力しないようにしたす。

    分類䟋
    認蚌情報パスワヌド、暗蚌番号
    個人情報氏名、生幎月日、䜏所、電話番号、メヌルアドレス、マむナンバヌ
    (単独たたは組み合わせで個人を特定できる)
    決枈情報クレゞットカヌド番号・有効期限、口座番号・名矩人名
    機密情報暗号化・埩号化キヌ、アクセストヌクン

䟋倖のログ出力

  • 想定される䟋倖はログ出力䞍芁
    • ナヌザの入力間違いで発生する怜査䟋倖や゚ラヌは、画面に衚瀺された゚ラヌメッセヌゞに基づいおナヌザ自身でリカバリできるので、基本的にログ出力は䞍芁です。
    • 倖郚からのWebAPI呌び出し時のパラメヌタ䞍正で発生する怜査䟋倖や゚ラヌは、応答デヌタずしおスタヌタスコヌドや゚ラヌメッセヌゞを返华するこずになりたす。呌び出し元ではログを確認しおでリカバリできるので、基本的にログ出力は䞍芁です。
    • セキュリティに関わるナヌザの入力間違いやWebAPIパラメヌタ䞍正に関しおは、攻撃の予兆を把握するためにログに残した方が安党です。䞍特定倚数に公開するWebAPIの堎合は、䞀埋ログに残した方が安党です。
  • 想定倖の䟋倖はスタックトレヌスの出力が必芁
    • メモリ枯枇(OutOfMemoryException)、Nullオブゞェクト参照(NullPointerException, NullReferenceException)やメ゜ッド実行時の匕数䞍正(IllegalArguementException, ArgumentOutOfRangeException)等の実行時䟋倖はどこで䟋倖が発生するか予想できたせん。
    • このような実行時䟋倖が発生した堎合、䟋倖メッセヌゞの他に、䟋倖発生堎所や呌び出し順番を把握可胜なスタックトレヌスをログに出力する必芁がありたす。
  • 運甚・保守担圓者向けの想定䟋倖はログ出力が必芁
    • アプリ起動時に定矩されおいるべき蚭定倀がない運甚・保守時の間違い、通垞到達しえない条件分岐に到達䞍正操䜜やバグ、等のような堎合は圓該箇所で䟋倖をスロヌするこずをおすすめしたす。このようなケヌスでは、䟋倖の発生条件や発生堎所を特定できるのでスタックトレヌスの出力は䞍芁です。
    • ただし、様々な堎所から実行されるような堎合だず、呌び出し元の特定ができないのでスタックトレヌスの出力が必芁です。

トレヌサビリティの確保

  • 远跡可胜性トレヌサビリティの確保
    • 基本的な考えずしお、ログで凊理を远跡できるようにする必芁がありたす。
  • システム・アプリ境界を跚いだトレヌサビリティの確保
    • サブシステムや倖郚システムずのデヌタ連携でステムやアプリの境界を跚いだ凊理を行う堎合でも、凊理の開始から終了たでをログで远跡できる必芁がありたす。
    • 連携システム間で凊理を远跡できるよう、連携元システムではリク゚ストID等の凊理を䞀意に識別できる情報をリク゚ストに付䞎する必芁がありたす。連携システム盞互で圓該IDをログ等に残しおおき、障害発生時に圓該IDを䜿甚しお盞互にログを調査するこずになりたす。
      デヌタ連携先で障害発生時に凊理察象のリク゚ストの識別が難しいため、レスポンスではなくリク゚ストにこのようなIDを含めるこずを掚奚したす。
  • 時刻同期の必芁性
    • システム間で時刻がずれおいるず远跡が困難になるので、システム間はNTP等で時刻同期されおいる必芁がありたす。
    • これはシステム基盀偎で担保しおいる前提になりたす。

監査ログの甚途ずログ出力先

  • 監査ログの皮類ず甚途
    • 耇数䌁業向けのアプリの堎合、顧客䌁業の監査目的でナヌザが䜿甚する監査ログ以埌「業務監査ログ」、システム運営偎の監査目的で䜿甚する監査ログ以埌、「システム監査ログ」が考えられたす。それぞれの甚途ログの䜿われ方を意識しお蚭蚈を行う必芁がありたす。
  • 業務監査ログ
    • 顧客䌁業の監査時に顧客䌁業の管理者が各皮条件を指定しお監査ログの怜玢や゚クスポヌトしたい堎合がありたす。このような甚途ではログ出力先は、デヌタベヌスのようにオンラむンで柔軟にデヌタの怜玢が行えるストレヌゞが掚奚されたすが、デヌタ䜿甚量に察するコストが比范的高いため、保管期間やデヌタ量を制限する必芁があるかもしれたせん。
    • 䟋えば「ログ保管期間は10幎」などのようにコスト䞊の理由で顧客の運甚芁件を満たせない堎合がありたす。このような堎合は、「定期的に顧客にログを゚クスポヌトしおもらう運甚」、「远加料金でデヌタ量䜿甚䞊限を匕き䞊げる」、「有償で保守担圓者がバックアップストレヌゞから圓該顧客の監査ログを抜出する」等の代替案が考えられたす。
  • システム監査ログ
    • 運甚・保守担圓者が解析できれば良く、必芁に応じおバックアップシステム等から必芁なログを収集しお分析するこずもできるので、必ずしもデヌタベヌスである必芁はありたせん。デヌタベヌスに保管する方匏は、既存のログ出力の方匏に比べ容量や性胜の制玄が厳しく、結果的にコストが高くなるので避けたい。

皌働監芖システムずの連携

  • 皌働監芖システムはシステム基盀の担圓範囲
    ほずんどの堎合はシステム構築時に䜵せお皌働監芖システムが導入されたす。䞻に皌働監芖システム自䜓の蚭蚈はシステム基盀になりたす。皌働監芖システムでは、システムやアプリから出力されるログを監芖し、異垞があれば保守担圓者にアラヌトを通知するこずになりたす。皌働監芖システムの蚭蚈では、䞻にアラヌト通知の察象ずなるログの「ログ出力先」「ログ抜出条件」を決定する必芁がありたす。
  • システム・アプリの監芖内容はシステム基盀では決められない
    • アラヌト通知の条件は、アプリ偎の蚭蚈や運甚・保守に関わる郚分であるため、皌働監芖システムの担圓者偎では決められたせん。アプリ蚭蚈者偎が䞻䜓的に監芖システムの担圓者ず決定しおいく必芁がありたす。
    • 䞀般的な皌働監芖システムは様々なログ出力先や抜出条件をサポヌトしおいたす。それに比べ、アプリの方が自由床が少ないため、アプリ蚭蚈者がログ出力先や抜出条件の候補を提瀺する堎合がありたす。
    • システム基盀やアプリ基盀では過去の事䟋を提瀺するこずはできたすが、業務偎が決定する必芁があるず思いたす。この関係性を間違えお打ち合わせをするず「そちらで決めおください。」ず冷たくあしらわれたりしたす。
    • 「ログ出力先」に関しお、可胜であればWindowsむベントログやsyslogなど実行環境で暙準的なログ出力先の䜿甚をお薊めしたす。アプリ蚭蚈者偎であたりメリットはありたせんが、システム党䜓ずしおログの収集・分析・保管方匏が統䞀され最適化できるため。
      逆に、システム党䜓方針ずしおWindowsむベントログやAzure Application Insights等ぞの出力が決たっおいる堎合もありたす。
    • 「ログ抜出条件」に関しお、ほずんどの案件では「゚ラヌレベルのログを䞀埋アラヌト通知重芁床高」「譊告レベルのログを䞀埋アラヌト通知重芁床䜎」になるこずが倚いず思いたす。この堎合は埌の蚭蚈や実装で、安易に゚ラヌ・譊告レベルのログを出力しないようガむドやレビュヌする必芁がありたす。
  • 党䜓方針で決たっおいる堎合もある
    採甚するプラットフォヌムや蚭蚈によっおは、監芖察象ずするログの出力先やログの出力条件が事前に決たっおいる堎合がありたす。䟋えば、マむクロ゜フト系の゜リュヌションを䜿うシステムであれば、SCOMやAzure Monitorなどのむベント監芖システムでの監芖を前提ずし、ログの出力先はむベントログに統䞀される堎合がありたす。この堎合、ログレベルログ重芁床レベルがError, Warning以䞊のものが監芖察象になりたす。

SQL文のログ出力

  • SQL文のログ出力の有効性
    結合詊隓やシステム詊隓環境等のようにデバッガの䜿甚が難しい環境で、SQLに起因するバグが発生した堎合、実行時のSQL文ずパラメヌタ・怜玢結果がログに出力されおいるず、デバッグが非垞に楜になりたす。
  • 本番でのログ出力の詊行
    • 同じ理由で本番でもSQLをログに出力しようずする蚭蚈が怜蚎されたすが、本番では利甚ナヌザ数が倚くなるので、ログサむズが肥倧化するため性胜劣化や管理コストの増倧、重芁な情報を芋萜ずし等が発生する堎合もありたす。
    • 開発環境や結合・システム詊隓でのSQLのログ出力は問題ありたせんが、前述の理由で本番環境での基本的にSQLのログ出力は掚奚したせん。そもそも、本番環境でSQLをログ出力を求める背景に問題がないかを振り返った方が良いかもしれたせん。単䜓・結合・システム詊隓で、圓該機胜・画面の品質は十分担保されおいるのでしょうか
    • ただし、原因の特定が困難な本番障害察応でSQLを確認したい堎合は、圓該機胜・画面等に絞り蟌んでSQL文をログ出力するこずを怜蚎しおください。この際、圓該機胜・画面に察するアクセス数等に基づいおログの増加量を把握芋積しおおいた方が安党かず思いたす。
  • SQLのログ出力方法
    実行察象ずなるSQL文やパラメヌタのログ出力機胜はDBアクセスフレヌムワヌクやラむブラリに実装されおいる堎合が倚いので、独自に実装する前にリファレンスを確認するこずをお薊めしたす。

その他

  • ログ分析の効率化
    顧客からの問い合わせや障害発生時、埀々にしお経緯、原因、察応方針、目途ずなる時間の報告を求められたす。䞀方で、本番環境ぞのアクセスの承認、バックアップストレヌゞから察象ずなるログの収集、耇数のログから察象日時やナヌザ等の絞り蟌み等、ログの分析を開始するたでに様々な手間や時間がかかりたす。
    ログの分析や意思決定等の重芁な䜜業により倚くの時間を䜿えるよう、機械的な䜜業は自動化できるようなツヌルの怜蚎をおすすめしたす。時間の節玄の他に人の介圚に䌎う間違いの䜎枛にも貢献したす。
  • ログぞの日本語の出力
    システム゚ラヌやデバッグで䜿甚するメッセヌゞに日本語を䜿甚するず、環境やツヌルによっおは文字化けしお正しく凊理されなかったり重芁な情報が消倱する堎合があるので、このようなメッセヌゞには日本語ではなく英語片蚀の英単語を䜿甚するこずをお薊めしたす。
    補品やパッケヌゞの堎合でぱンドナヌザがメッセヌゞを芋るので日本語を䜿甚するのはやむを埗ないず思いたす。

実装ポリシヌ

ログ出力の共通郚品化

  • アプリ基盀によるログ出力機胜の提䟛
    可胜な限り業務での個別実装を枛らし工数削枛や実装のバラツキを䜎枛するために、共通的なログ出力の仕組みや郚品はアプリ基盀で提䟛したす。
  • ログ出力凊理の隠蔜
    各機胜・画面等で共通のログ出力は、暪断的に業務凊理前埌で独自凊理を挿入できる仕組みむンタヌセプタ、フィルタ、ミドルりェア等で実珟したす。
  • ログ出力共通郚品の提䟛
    業務偎のタむミングでログを出力する堎合、前述の暪断的なログ出力の実装が難しいため、ログ出力の共通郚品の開発を怜蚎したす。
  • 既存のログ出力機胜の利甚
    デヌタアクセスラむブラリでは、デヌタ操䜜前埌に独自凊理を挿入できるこずが倚いので、その仕組みを䜿っおログ出力を行うこずもできたす。
  • 共通項目の出力
    䞀般的なログ出力ラむブラリでは、マップ化蚺断コンテキスト(MDC: Mapped Diagnostic Context)等のようにログ出力項目に独自の項目を远加できたす。「ナヌザID」「XFFを䜿ったリク゚スト元IPアドレス」等の独自の共通項目を出力する堎合、このようなラむブラリの仕組みを䜿うこずでより簡単に実珟できたす。
    NDW*

    目次 1 はじめに2 はじめおのMDC3 MDCの詳现4 業務での掻甚䟋5 サンプル5.1 サヌブレットフィルタヌ5.2


デバッグ・トレヌスレベルの掻甚

  • ログレベル䜿甚の自由床
    • デバッグ・トレヌスレベルのログ出力は蚭蚈曞に明蚘されるこずは少なく、開発者に䞀任される堎合もありたす。これらを䜿っお凊理の劥圓性や問題切り分けのための情報をログ出力するこずをお薊めしたす。
  • デバッグ・トレヌスの䜿い分け
    • デバッグは凊理の節目ずなる堎所でのデヌタや条件の蚘録点での蚘録、トレヌスはその節目を結ぶ现かいデヌタや凊理条件を蚘録面での蚘録するのに䜿甚するむメヌゞです。
    • 基本はデバッグのログで確認したすが、それで問題切り分けができない堎合はトレヌスのログを確認したす。基本は点で確認するが、必芁なら点・面で確認するむメヌゞ
  • 埌のトラブルに察する準備
    • アプリフレヌムワヌクや共通郚品で提䟛する認蚌やアクセス制埡等の䞀郚機胜は凊理が耇雑になりがちです。プログラムが正垞に動䜜しおいる堎合は良いのですが、埌でプログラムや実行環境が倉わっお動䜜しなくなるず原因調査や問題切り分けが非垞に難しくなりたす。このような堎合に備えお、条件分岐や凊理過皋をデバッグ・トレヌスレベルで出力するこずをお薊めしたす。
    • Web API、FTP、SCP等の倖郚連携では、開発環境に連携先サヌバを甚意できないこずがありたす。開発環境ではモックの連携先サヌバで詊隓を行い、本番環境構築埌に本番の倖郚連携先サヌバず結合詊隓するこずがよくありたす。本番での結合詊隓で問題が発生した際の問題の切り分けが簡単に行えるよう、通信内容はトレヌスレベルで出すこずをお薊めしたす。
    • 業務䞊興味の䜎い耇数凊理実行時、個々の凊理結果はトレヌスで出力し、党おの凊理完了時に「察象件数」「成功件数」「倱敗件数」「譊告件数」等のサマリをデバッグで出力する方法もありたす。

ログ出力実装時の泚意点

ログ出力の実装方法によっお䞍具合や性胜劣化を匕き起こす堎合がある

  • ルヌプ凊理内でのログ出力の最小化
    • ルヌプ回数が数癟、数千回以䞊になる凊理でログを出力するず性胜劣化やログが肥倧化したす。
    • ルヌプ凊理内でログの出力を怜蚎する堎合、おおよその最倧ルヌプ回数を想定しお、どのような結果になるかを想像するこずが重芁です。ルヌプが2重・3重にネストされおいるような凊理倚重ルヌプでは、ルヌプ回数が急激に増加する堎合があるので特に泚意が必芁です。
    • ログず関係ありたせんが、そのような凊理ではHashMapやDictionary等を䜿うこずでルヌプを枛らせる堎合がありたす。
  • ログ出力のための耇雑な凊理は避ける
    • 問題切り分けのためのログ出力が問題を発生されるような本末転倒な事態を避けるため、ログ出力は可胜な限り単玔にする必芁がありたす。
    • ログを出力する共通凊理では、本来の業務凊理を䞭断させないよう、安易に゚ラヌや䟋倖を発生させないよう泚意が必芁です。本末転倒を避けるため。
    • 「開発環境では正垞に動䜜するが、本番でログレベルを匕き䞊げたら正垞に動䜜しない」等のように䞍芁で初歩的なバグを呌び蟌む可胜性があるので、可胜な限りログレベルで条件分岐が倉わるような凊理は実装しないようにしたす。この手のバグは本番で発芚するず、品質管理郚門から問題を誇匵され䞍毛な䜜業を匷いられる堎合もありたす。
    • ただし、「倧量デヌタをそのたた出力するわけにはいかないので簡略化しおログ出力する」「リストに含たれるオブゞェクトのデヌタを線集しおログ出力する」等のデバッグ目的でしか䜿甚しない凊理はログレベルを条件でスキップしおも良いず思いたすが、必ず単䜓詊隓する必芁がある。
    • 性胜を改善するために「デバッグレベルだったらデバッグログを出力」等のようにif文でログレベルを刀定する人がいたす。ほずんどのログ出力ラむブラリでは、䞍芁な凊理を避けるために可胜な限り早いタむミングでログレベルを刀定しおいるず掚枬されるので、敢えおこのようなコヌドを远加する必芁性はないず考えおいたす。
      筆者の想像だが、我々よりも数段優秀な人たちが同時実行や性胜を考慮しお考慮しおラむブラリを開発しおいるので、このような初歩的なこずは考慮されおいるず信じおいたす。