OutSystemsでシステム開発をする際に、ログ出力方針の一応のお勧めをまとめておきます。
OutSystemsが標準で備えるログ出力の仕組みがあるので、なるべくこれを流用するのがお勧め。
目次
標準のログの仕組み
種類
代表的なものは、
- Error
- General
- 連携(RESTなど）
- 画面アクセス
あたり。アプリケーションから出力するログを考えるときは、「Error」と「General」が対象になります。
データベースビューとエンティティのマッピングに一覧があります。
記録する仕組み
各ログには対応するEntityがあり、ログを出力すべきイベントが発生すると、自動で記録されます。
Entityはログの種類ごとに1つずつ存在し、各種類のセットを1週間ごとに持ちます。
各セットには「_0」～「_9」のサフィックスが付きます。合計で10セット。
例：エラーログには、Log_Error_0、Log_Error_1、Log_Error_2、……、Log_Error_9の10個のEntityがある。
各セットは1週間毎（DBサーバー時間の金曜夜11:45）にローテートされます。
10セットなのでどうやっても10週間が保存期間の最長になりますね。実際は、Configuration Toolで設定した上限期間を過ぎると古いデータは消されていきます。
このあたりの詳細は、ログのテーブルおよびビューを参照。
閲覧方法
ログを閲覧する方法は2つあり、
①Service Centerを利用する
普通はこちらですね。直近2週間であれば、この方法が便利。
Monitoringタブの下に、閲覧できるログ種類ごとに別のタブが並んでいます。
アプリケーションが多いとログが埋もれやすいので、ModuleやMessage、日時（From/To）でフィルタリングすることが多いと思います。
②Entityを直接閲覧する
閲覧用アプリケーションをOutSystemsで作成したり、DBのツールを使って直接閲覧する方法。
Entityやその背後にあるビューについては以前Qiitaに書きましたのでこちらを参照してください。
各Entityの属性にRequest_Keyというものがあります。あるリクエストに紐付いて出力されたログには、この属性に同じ値が入るので、保守／運用時の調査に使えます。
これもQiitaに書いています。
アプリケーションから出力する方法
Errorログ、Generalログに対して非同期にログ出力を行うためのAPIが標準提供されています。
Errorログに出力するのはAsynchronous Logging APIモジュールのLogError Action、Generalログに出力するのは(System)モジュールのLogMessage Actionです。
LogMessageについてはよく使われていて、使い方もモジュール名とメッセージを渡すだけなので説明は不要ですね。
LogError Actionについては、Qiitaに書いています。
また、Exception HandlerでLog Error=Yesにしておくと、例外発生時にErrorログに記録されます。
ログはOutSystems標準に集約する
上記に書いてきたとおり、OutSystemsには標準で多くのログを収集する仕組みがあり、更に作成したアプリケーションから任意に追加することもできます。
通常は、このログの仕組みを利用し、アプリケーションからログ出力する際も標準APIで同じ場所に出力したほうが便利であり、色々なログを突き合わせる必要もないので良いと思います。
具体的には、チームや会社単位で標準のログ出力部品を作成しましょう。
ログ出力部品は内部でLogErrorかLogMessage Action呼び出しを含めることで、自動的に、非同期で標準ログに集約できることになります。
あとは、ログ出力部品にログレベル（標準APIにはこの概念がない）や追加情報を含める処理を追加すると良いですね。
こうすれば、Service CenterのMonitoring > Errors/Generalのタブで一元的に必要なログを閲覧できる。
バックアップ＆専用検索機能
クエリのログデータには、
ロギングメカニズムは書き込みに最適化されているため、稼働中のシステムのビューを照会することは、環境の実行性能に悪影響を及ぼすことにご注意ください。必要な検索タイプを考慮して設計されたモデルで、ログデータのコピーを作成するための独自メカニズムを実装することを推奨します。
と記載されています。
よって検索頻度が多くなるなら、稼働中のシステムの性能劣化を防ぐためにログデータを別の場所にコピーし、そこで検索することが勧められています。
そうでなくても、監査や調査のためにログに保管要件があるかもしれません。
タイミングはログの保管や検索に求める要件によっていくつか考えられますね。
ここでは、一案を挙げておきます。
コピー頻度：週に一度（ログのセットが切り替わった後）
コピー対象：PlatformLogs Extensionに含まれるEntityの内、「_Previous」で終わるもの。これは前週分のデータが入っているビューをポイントしている
コピー方法：Timerを利用し、必要な加工を施しつつ、独自のEntityや外部DBのテーブルにコピー（INSERT）。コピー対象のEntity/テーブルには検索列用のインデックスを設定する
利用方法：検索用のアプリケーションを別途OutSystemsで作成する
製品の仕組みでは適わない要件がある場合
ログに求められる要件が、上記OutSystemsのログ仕様を検討してもカバーできないものであった場合は、別途ログ出力先を検討しなければなりません。
その場合でも、OutSystemsが製品として出力するログは相変わらずService Centerで確認することになります。セキュリティのために出力できない場合を除いては、別の出力先だけでなく、LogErrorとLogMessageを使って標準の出力先にも同時に出力することを検討したほうがいいと思います。