一連の処理から出力されるログに共通で付与されるIDがCorrelation Id。
OutSystemsでこのCorrelation Idをどうするかを検討してみる。
Table of Contents
結論から
OutSystemsの標準ログはデフォルトでCorrelation Idを記録しているので、標準ログを使っていれば何もする必要がない。
ただし、標準ログはDBに出力される。他の場所に出力したいときには、自分でログを出力するか、DBから同期する仕組みを構築する必要がある。このときのCorrelation Idとしては、標準ログでも使っているIdを取得するRequest_GetKey (PlatformRuntime Extension)かGenerate_Guid (System)が使える。
標準ログにおけるCorrelation Id
仕組み
OutSystemsの標準ログには、デフォルトでCorrelation Idに相当する情報が出力される（Request_Keyという名前）。
トップレベルログと呼ばれる画面からのサーバーリクエスト・Expose REST API呼出・Timerの単位でこのRequest_Keyが一意で振られ、これらのリクエストに紐づく各種ログには同じRequest_keyが記録される。
そのため、OutSystemsの標準ログを使っていれば、このRequest_KeyがCorrelation Idとして機能する。
トップレベルログとドリルログ
トップレベルログに分類されるのは、Service CenterのMonitoringの下にある個別ログでいうと、以下のものが該当する。
- Traditional Web Requests
- Screen Requests
- Integrations (Type=Exposed)
- Timers
ドリルログは、
- Errors
- General
- Integrations (Type=consumed)
- Extensions
つまり、画面へのリクエスト（Traditional Web RequestsやScreen Requests）やExpose REST APIへのリクエスト（Integrations (Type=Exposed))、タイマー（Timers）1つに対し、エラーログ、任意に出力する各種ログ、Consume REST API、Extensionのログがそれぞれ0-複数件紐づく。
ログへのアクセス
Service Centerを利用する方法
各環境のService CenterのMonitoringタブを開く。
問題が発生した時点の、ログをまずどれか1つ見つける。
見つけたログをExport ExcelでExcelに出力すると、Correlation Idに該当するRequest_Keyが含まれている。
関連するログを時間帯でフィルタして同様にExcelにExportしてRequest_Keyが一致するものが一連のログということになる。
例：エラーが発生して調査する場合。時間帯・エラーメッセージ・エラーモジュールがわかっていれば、
- Service CenterのErrorsの画面で検索して画面上でログを確認
- ExcelにエクスポートしてRequest_Keyを確認
- LogMessage等を出力しているならGeneralでExcelにエクスポートしてRequest_Keyでフィルタすると目標のログが見つかる
DBを利用する方法
各ログには、対応するEntityが用意されているので、これらを結合して検索する仕組みを作る。実は、標準ログは更新速度に最適化されている。検索速度のために、別のDBを用意し、出力されたログをコピーしておき、そのDBを利用した検索システムを構築することが推奨されている。
このあたりの仕組みについては、OutSystemsを利用したシステム開発でログはどうすべきかを参照。