はじめに
Pleasanterのトラブルシューティングにおいて、システムログ は最も重要なログです。アプリケーションに到達したリクエストの詳細を記録するため、障害解析やパフォーマンス分析の中心的な情報源となります。
この記事では、システムログの設定方法、参照方法、主要カラムの読み方から、実践的なトラブル事例まで、体系的に解説します。
関連記事：Pleasanter障害調査：システムログで見えないエラーの事例と確認方法
Pleasanterのシステムログ概要
基本的な記録のしくみ
Pleasanterのシステムログは、サービスの起動など一部のログ除き、基本的にはクライアント（ブラウザやAPI）からの1リクエストに対して、アプリケーション内での処理結果を1ログレコードとして記録 する仕組みです。
例えば、ユーザが、ログイン、 一覧画面でレコードを表示、レコードの作成を行うとした場合、各操作のそれぞれが、独立した1つのリクエストとしてシステムログに記録されます。
各ログには、リクエストの時刻、ユーザID、実行URL、処理時間、エラー有無などの詳細情報が含まれます。
システムログで確認できる情報
システムログを通じて、以下のような情報を確認できます。
| 確認項目 | 説明 |
|---|---|
| ユーザ操作履歴 | いつ、だれが、どのページで、何を操作したか |
| アプリケーションエラー詳細 | エラーメッセージ、エラーが発生した処理場所、スタックトレース |
| パフォーマンス | 各操作の処理時間、メモリ使用量、セッション情報 |
| システムの健全性 | アプリケーション再起動、リソース使用状況、エラー発生頻度 |
システムログデータの保存先
システムログは、デフォルトではPleasanterのデータベースのテーブル SysLogs に保存されます。Pleasanter 管理画面から参照できるほか、SQL クエリで直接アクセスして詳細な分析も可能です。
なお、本記事では触れませんが、システムログをテキストファイルとして出力する機能 もあります。大規模環境での外部ログ管理ツールとの連携や、長期保存が必要な場合に有用です。詳細は公式ドキュメントを参照してください。
システムログをテキスト出力できるようにする
https://pleasanter.org/ja/manual/syslogs-text-output
システムログの推奨設定
システムログの拡張機能の有効化
デフォルトのシステムログには基本的な情報が記録されますが、システムログの拡張機能を有効化することで、トラブルシューティングに有用なカラムが追加 されます。これらのカラムには、API呼び出し判定、サイトID、参照先レコード、詳細なステータスコードなどが含まれます。
システムログの拡張機能
https://pleasanter.org/ja/manual/syslog-extension
新規に環境を構築する際には、システムログの拡張機能を有効化することを推奨します。
既にシステムログにデータが保存された既存環境で拡張機能を有効化する場合は、上記設定ファイルを変更し、 CodeDefiner を実行することでテーブル構造が更新され、拡張カラムが追加されます。
この際、現状のSysLogsテーブルのレコード件数が多い場合は、CodeDefinerの実行に時間がかかる可能性があります。
ログ保存期間の設定
システムログは、デフォルトでは無期限に保存 されます。そのため、長期間運用を続けるとログテーブルのサイズが肥大化し、データベース全体のパフォーマンス低下につながる可能性があります。
ログの自動削除ルールを設定するには、BackgroundService.json の DeleteSysLogs を有効化し、DeleteSysLogsTimeを指定します。
パラメータ設定：BackgroundService.json
https://pleasanter.org/ja/manual/background-service-json
SysLogsテーブルに格納されるシステムログの保存日数は、SysLog.json の RetentionPeriod パラメータで設定します。
パラメータ設定：SysLog.json
https://pleasanter.org/ja/manual/sys-log-json
システムログの参照方法
Operations Tools での高度な分析
Pleasanter の有償ライセンス（Enterprise Edition）環境では、Operations Tools という運用支援ツールを利用することができ、システムログを多角的に分析できます。
Operations Toolsは以下のような機能が含まれます。
- 運用レポート：全体の利用状況・性能状況を俯瞰し、日別／時間別（15分単位）の性能推移を確認
- 利用状況詳細：日別／月別／詳細で、ログイン履歴・メール送信履歴・APIリクエスト履歴などを可視化
- 監視アラート：データベース／システムテーブル／サイト単位の現在値を把握し、上限値のアラート設定が可能
- サイト情報一覧：サイトの一覧と基本情報を横断的に確認
- アクセス権一覧：各サイトのアクセス権設定を一覧で点検
- パラメータ一覧：各種パラメータの設定値と変更有無を確認
Operations Tools：機能概要
https://pleasanter.org/ja/manual/operations-tools-overview
システムログ管理画面からの確認
特権ユーザでPleasanterにログインし、管理メニューから 「システムログ」 を選択します。
必要な検索条件を設定し、「フィルタ」ボタンを押下することで、指定の条件のシステムログが参照できます。また、表示されているシステムログをCSVでエクスポートすることも可能です。
システムログ管理機能
https://pleasanter.org/ja/manual/syslog
SQL での直接参照
システムログ管理画面では表示できない、より詳細なログフィルタリングや集計が必要な場合は、SQL で直接 SysLogs テーブルを参照します。
ログ参照時のパフォーマンスに関する注意
SysLogsテーブルには SyslogIdとCreatedTime カラムにIndexが設定されています。全期間を対象とした調査するようなケースを除き、WHERE条件で必ず日付・時間範囲を指定 してください。
ログ件数が多い場合に CreatedTime を指定せずにその他の項目のみを条件のみでフィルタすると、データの取得に時間がかかる場合があります。
データベースに負荷をかけずに効率的にログを参照するためには、以下のように 日付・時間範囲を指定してログをExcel等にエクスポートし、 エクスポート後のデータをExcelのフィルタ機能で絞り込みを行う方法もあります。
SQL Server での取得例
SELECT *
FROM "dbo"."SysLogs"
WHERE "CreatedTime" >= '2026-01-29 14:00:00' AND "CreatedTime" < '2026-01-29 15:00:00'
ORDER BY "CreatedTime" DESC;
※ PostgreSQL、MySQLを使用している場合は、スキーマやSQL構文を適宜調整してください。
SysLogs テーブルの主要カラム
Pleasanterのシステムログを格納する Syslogsテーブルには、多くの列項目が出力されます。それぞれ、目的に応じて確認するポイントをまとめています。
FAQ：システムログ(SysLogsテーブル)の内容について
https://pleasanter.org/ja/manual/faq-contents-of-syslogs
ユーザ操作の追跡に役立つ項目
| カラム | 説明 | 活用例 |
|---|---|---|
SiteId(拡張項目) |
アクセス先のサイト | どのサイトにアクセスしたか |
ReferenceId(拡張項目) |
アクセス先のレコードID | どのレコードにアクセスしたか |
Url |
アクセス先のURL | どのページにアクセスしたか |
UrlReferer |
リクエスト元のURL（ページ遷移元） | ユーザの操作フローを追跡 |
RequestData |
リクエストボディの内容 | 送信されたデータの詳細 |
Creator |
操作者のユーザID | 誰が操作したか |
Updator |
データ更新者（操作内容がデータ更新の場合） | データを変更したユーザ |
UserHostAddress |
アクセス元のIPアドレス | どのネットワークからのアクセスか |
SessionGuid |
ユーザセッションの識別子 | 同一セッション内の操作を追跡 |
UserAgent |
ブラウザのユーザエージェント | どのブラウザからアクセスしたか |
CreatedTime |
リクエスト受信時刻 | リクエストを受け取った日時 |
UpdatedTime |
リクエスト処理完了時刻 | リクエストの処理が完了した日時 |
活用シーン：
- Creatorを指定し、特定ユーザの操作フローを時系列で追跡
-
SiteIdやReferenceId(もしくはUrl)を指定し、特定ページへのアクセス状況を把握
パフォーマンス分析に役立つ項目
| カラム | 説明 | 分析目安 |
|---|---|---|
Elapsed |
リクエスト処理時間（ミリ秒） | 特定の操作、処理で時間を要していないか |
WorkingSet64 |
リクエスト処理時のメモリ使用量（バイト） | 急激な増加や継続的な増加はメモリリークの兆候 |
活用シーン：
-
Elapsedの降順にソートし、遅い処理を特定 -
WorkingSet64の時系列グラフ化し、メモリ使用量の推移を監視
Elapsedには、以下を除く通常のリクエストでは、リクエストを受けた処理の開始から終了までの時間がミリ秒の単位で記録されます。
Elapsedが記録されないログ
- Pleasanter本体の起動ログ、サービス開始ログ
- ユーザのログイン・ログアウトの操作ログ
- 一部のサードパーティ製品のログ（Report Create for プリザンターのログ）
これらのログ以外で、Elapsed列の出力が空（Null）の場合、システムログ取得時点で処理が継続しているか、あるいは終了まで到達せず、異常終了している可能性があります。
アプリケーションエラー調査に役立つ項目
Pleasanterの画面操作中、下部に「アプリケーションエラーが発生しました」と表示された場合、基本的にはシステムログの以下の列にそのエラーの詳細が出力されます。
| カラム | 説明 | 活用例 |
|---|---|---|
ErrMessage |
エラーメッセージ | エラーの概要を特定 |
ErrStackTrace |
スタックトレース | エラーが発生した処理箇所を特定 |
活用シーン：
- 特定のサイトでエラーメッセージが発生：サイトの設定、サーバスクリプトを確認
- 特定のサイトに限定せずデータベースに関するエラーが発生：データベースのパフォーマンス不足や、コネクション不足などを確認
ErrMessageにエラー情報が出力された場合、その詳細がErrStackTraceに出力されます。 出力された関数名から Pleasanterのソースコードを参照し、エラーの発生源を特定することができます。
具体的なトラブル事例
ユーザから「特定の処理が遅い」という報告があった場合、以下の各ケースを確認します。
ケース1：Elapsedが高い処理の特定
CreatedTime で期間を絞り込んだうえで、Elapsedが Nullの項目や、Elapsedの値が大きい処理を特定し、その分布によって発生源を特定します。
- 特定のサイトでのみElapsedの値が高い：そのサイトの設定やスクリプトが遅い可能性
- 特定の時間帯に集中：その時間帯の同時利用ユーザ数
- 特定ユーザに限定：そのユーザの操作や対象データの問題
ケース2：WorkingSet64 の異常増加
CreatedTime で期間を絞り込んだうえで、WorkingSet64 の推移をグラフ化してメモリ利用状況を調査します。
-
特定サイトの操作で
WorkingSet64が上昇：そのページの設定やスクリプトにメモリ使用の問題がある可能性を調査 - 特定の処理に起因した急上昇はないが常に高い状態：システムのリソースの絶対量が不足している可能性を調査
ケース3：特定の重い処理
以下のような処理については、処理対象となるデータ量、対象となるサイトの既存データ数などに応じて、システムリソースを消費する場合があります。
システム高負荷となる要因の典型的な操作：
- Import（インポート）
- Export（エクスポート）
- BulkUpdate（一括更新）
- BulkDelete（一括削除）
- synchronizedsummary（サマリ同期）
- 各APIによる一括処理
- 多数の処理を行うサーバスクリプト
- 大容量、あるいは多量の添付ファイルのアップロード・ダウンロード
- 一覧画面での複数、複雑なフィルター・サブクエリを伴う検索処理
これらの処理の重複などによってElapsedやWorkingSet64の上昇が確認できた場合は、実行タイミング、運用の見直しなど検討します。
まとめ
Pleasanter のシステムログは、ユーザ操作の監査、パフォーマンス分析、エラーの原因特定 に不可欠なツールです。継続的なシステムログの監視と分析を通じて、トラブルの早期発見・対応、システムパフォーマンスの最適化を実現してください。