OSSのノーコード・ローコード開発ツール「プリザンター」 Advent Calendar 2025

Pleasanter障害調査：システムログで見えないエラーの事例と確認方法

Last updated at 2025-12-12Posted at 2025-12-12

はじめに

Pleasanterのトラブルシューティングにおいて最も主要なログは システムログ です。
通常の運用における障害解析はまずシステムログを確認しますが、アプリ層に到達する前の前段で発生した問題（起動失敗、HTTPリクエストの不正、認証ハンドシェイクの失敗など）は、システムログだけでは掴みきれません。

こうした問題の調査には、標準出力/標準エラー出力（以下、標準出力） に加え、Webサーバ（IISやnginx）、ロードバランサやFirewall のログも有効です。この記事では、標準出力の扱いを中心に各環境での確認方法と、代表的なトラブルをまとめます。

Pleasanterの標準出力とは

PleasanterはASP.NET Core上で動作する.NETアプリです。Pleasanterのシステムログはアプリケーション層での各操作ログを中心に記録しますが、起動フェーズのメッセージ、ホスト／ミドルウェア層の警告・失敗、未処理例外など、一部の情報はシステムログに出力されず、標準出力へ出力されることがあります。

システムログに出力されず、標準出力に出力される事象の例

アプリ起動時の致命的エラー
（依存DLLがない、設定ファイルの読み込み失敗）
HTTP前段のリクエスト不正
（BadHttpRequestException：行形式不正、ヘッダ超過、リクエストボディやヘッダの形式不整合など）
CORSポリシー違反
（プリフライト失敗、未許可オリジン）
認証ハンドシェイク失敗
（Cookie/SAMLのメタデータ不一致）

これらはPleasanterのアプリケーションの前段／ミドルウェアで弾かれるため、アプリが動き出す前に発生します。そのため、システムログには記録されず、標準出力にその痕跡が出力されることがあります。

環境別：標準出力／標準エラーの出方と確認方法

Windows（IIS + ASP.NET Core）環境

Windows環境において、IISでホストされたASP.NET Coreアプリケーションの起動失敗や致命的障害は通常、Windows イベントログ（アプリケーション）に記録されます。

そのため、まずはイベントログを確認し、イベントログでも原因が特定できない場合のみ、以下の操作により、一時的に 標準出力を有効化して詳細を調査する運用としてください。

有効化手順：Pleasanterのカレントディレクトリにある web.config の <aspNetCore> 設定で、stdoutLogEnabled="false" を stdoutLogEnabled="true" に書き換え、Pleasanterを再起動します。

変更前:

	<aspNetCore processPath="dotnet" arguments=".\Implem.Pleasanter.dll"
		stdoutLogEnabled="false"
		stdoutLogFile=".\logs\stdout"
		hostingModel="inprocess" />

変更後:

	<aspNetCore processPath="dotnet" arguments=".\Implem.Pleasanter.dll"
		stdoutLogEnabled="true"
		stdoutLogFile=".\logs\stdout"
		hostingModel="inprocess" />

注意
stdoutLogFileに指定したログファイルは自動で削除されず、タイムスタンプ付きで増え続けます。肥大化を避けるため、調査が済んだら出力を解除する運用を徹底してください。

ログの確認方法：

イベントログは「イベントビューア」から「Windowsログ」→「アプリケーション」を開いて確認します。
イベントログで確認できない事象がある場合は、標準出力を一時的に有効化し、web.configで指定したstdoutLogFileのファイルを直接参照します。

参考情報 :
ASP.NET Core モジュールを使用したログの作成とリダイレクト | Microsoft Learn
https://learn.microsoft.com/ja-jp/aspnet/core/host-and-deploy/iis/logging-and-diagnostics

Linux（systemd + journald）環境

Linux環境では、サービスとして起動したアプリケーションの標準出力および標準エラー出力は、systemdによって自動的にjournaldへ収集されます。これにより、アプリケーションの起動メッセージやエラー、未処理例外なども含めて、すべてのログが一元的に管理され、journalctlコマンドで確認できます。
ログのローテーションや容量管理は、systemdのjournaldによってデフォルトで自動的に行われます。通常の運用では追加設定は不要ですが、ログの保存容量や保持期間はjournaldの設定に依存するため、出力量や容量に過不足がある場合は、適宜journaldの設定を調整してください。

ログの確認方法：

journalctl -u pleasanter.service でサービスのログを確認できます。
リアルタイムで追従する場合は journalctl -u pleasanter.service -f を利用します。

参考情報 :
How to enable persistent logging for the systemd journal - Red Hat Customer Portal
https://access.redhat.com/solutions/696893
Ubuntu Manpage: journalctl - Query the systemd journal
https://manpages.ubuntu.com/manpages/xenial/en/man1/journalctl.1.html

Docker 環境

Docker環境では、コンテナ内アプリケーションの標準出力および標準エラー出力は、Dockerランタイムによって自動的にログとして収集されます。
これらのログは、docker logs <container名> コマンドで参照できます。
ログのローテーションや保存容量は、Dockerの設定で適宜調整します。

ログ確認方法：

docker logs <コンテナ名> コマンドで、コンテナの標準出力のログを確認できます。

参考情報:
Logs and metrics | Docker Docs
https://docs.docker.com/engine/logging/

標準出力で確認できるトラブル事例

Pleasanterのシステムログにエラーが記録されていない場合や、アプリが起動しない、APIでリクエストが届かないといったPleasanterのアプリケーションの前段の問題が疑われる場合は、適宜標準出力の出力も確認してください。

以下は、その代表的なトラブル事例です。

アプリ起動時の致命的エラー（未処理例外）

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly ...

依存DLL不足や参照ミス。問題がある場合はPleasanterの起動前に発生します。

Unhandled exception. Implem.Libraries.Exceptions.ParametersIllegalSyntaxException: Api.json
at Implem.DefinitionAccessor.Initializer.Read[T](Boolean required) in C:\Implem\Pleasanter.NetCore\Implem.DefinitionAccessor\Initializer.cs:line 254
at Implem.DefinitionAccessor.Initializer.SetParameters() in C:\Implem\Pleasanter.NetCore\Implem.DefinitionAccessor\Initializer.cs:line 96

Pleasanterのパラメータファイル（json等）の構文エラーや必須パラメータ不足。初期化処理で失敗し、Pleasanterの起動前に発生します。

fail: Microsoft.Extensions.Hosting.Internal.Host[11]
	Hosting failed to start
	System.IO.IOException: Failed to bind to address http://[::1]:80: address already in use.
	---> Microsoft.AspNetCore.Connections.AddressInUseException: 通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートのどれか 1 つのみを使用できます。
	---> System.Net.Sockets.SocketException (10048): 通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートのどれか 1 つのみを使用できます。
		at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)

ポート競合や権限不足によるバインド失敗。初期化処理で失敗し、Pleasanterの起動前に発生します。

HTTP前段のリクエスト不正（400 Bad Request）
```
Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException: Invalid request line
```
- PleasanterのAPIを外部から呼び出した際、HTTPリクエストの構文やヘッダが不正な場合（例：ヘッダサイズ超過、multipart/form-data の境界（boundary）不一致、Content-Type の不整合など）、ASP.NET Core の Kestrelレイヤーやリクエストパーサーでエラーとなり、Pleasanterのシステムログには記録されません。
CORS プリフライト失敗／未許可オリジン
```
fail: Microsoft.AspNetCore.Cors.Infrastructure.CorsService[4]
      Request origin 'http://example.com' does not have permission ...
```
- このエラーは ASP.NET Core の CORS ミドルウェアで発生します。
  プリフライトリクエストや実リクエストのオリジンが許可リストに含まれていない場合、Pleasanterのアプリ処理には到達せず、Pleasanterのシステムログには記録されません。

認証ハンドシェイクの失敗（Cookie/SAML）

fail: Microsoft.AspNetCore.Authentication[0]
      Authentication failed: The SAML response issuer does not match the expected value.

このエラーは ASP.NET Core の認証ミドルウェアで発生します。
SAMLやCookie認証のハンドシェイク時に、メタデータ不一致、時刻のずれ、署名検証の失敗などの要因で失敗することがあります。これらは Pleasanterのアプリケーションロジックに到達する前に認証ミドルウェアで拒否されるため、システムログには記録されません。

標準出力以外の前段ログ

Pleasanterのアプリ層に到達する前に問題が発生する場合、標準出力ログだけでなく、Webサーバやロードバランサのログも重要な手掛かりになります。これらのログは、ネットワークやリクエスト転送の段階で起きる問題を切り分ける際に有効です。

IISログ（Windows環境）

IISのログは、HTTPリクエストがPleasanterに到達しているか、またはIIS側で拒否されていないかを確認する際に有効です。ヘッダサイズ超過やSSLハンドシェイク失敗、リクエスト制限（例：クエリ文字列がmaxQueryStringを超過）によってブロックされる場合、ASP.NET Coreにはリクエストが届かず、HTTP 404などのエラーが返されます。
これらの情報は通常 %SystemDrive%\inetpub\logs\LogFiles に記録されます。

参考情報:
IIS でログ記録を構成する | Microsoft Learn
https://learn.microsoft.com/ja-jp/iis/manage/provisioning-and-managing-iis/configure-logging-in-iis
要求の制限 | Microsoft Learn
https://learn.microsoft.com/ja-jp/iis/configuration/system.webServer/security/requestFiltering/requestLimits/

nginxログ（Linux/Dockerでのリバースプロキシ構成時）

nginxのログは、外部からのリクエストがPleasanterに届いているか、または転送時に問題が発生していないかを確認する際に有効です。特に、タイムアウト、SSL証明書エラー、プロキシ設定不備などの問題を切り分ける手掛かりになります。

また、通信制限によりリクエストが処理されない場合があります。例えば、クライアントから送信されるリクエストがnginxの制限を超えると、413 Request Entity Too Large が発生し、Pleasanterにはリクエストが到達しません。この場合、nginxのerror.logにエラーが記録されるため、ログを確認して原因を特定してください。
nginxのログは通常 /var/log/nginx/access.log や error.log に記録されます。

参考情報:
Module ngx_http_log_module
https://nginx.org/en/docs/http/ngx_http_log_module.html

ロードバランサ／Firewallのログ

ロードバランサやFirewallのログは、リクエストがPleasanterやWebサーバに到達する前の段階で発生する問題を切り分ける際に有効です。SSL終端の設定不備や証明書エラー、ヘッダ不足、タイムアウト、またFirewallのルールによる通信ブロックなどは、PleasanterやWebサーバのログには記録されません。これらのログを確認することで、リクエストがどこまで到達しているか、ネットワーク層やアプリケーション層でブロックされていないかを把握できます。

まとめ

Pleasanterの主要ログはシステムログですが、起動フェーズやホスト／ミドルウェア層で発生する問題は、システムログには記録されず、標準出力にのみ出力される場合があります。さらに、ネットワークやWebサーバの前段で発生する問題は、Webサーバ（IIS、nginx）や ロードバランサ／Firewallのログを確認する必要があります。
次のようなケースでは、標準出力のログ確認が有効です。
- 構築時や初期設定時：パラメータファイル（JSON）の構文エラーや必須項目不足による起動失敗。
- APIの開発・実装時：HTTPリクエストの構文不正やAPI呼び出しの誤りによるBadHttpRequestException、外部オリジンからPleasanter APIを呼び出す際のCORSポリシー違反。
- 認証設定時：CookieやSAMLのハンドシェイク失敗、メタデータ不一致。
- 運用中の障害調査：アプリが起動しない、APIリクエストが届かないなど、システムログに記録されない前段の問題。
ネットワークやアプリケーション層で発生する拒否を切り分けるため、ロードバランサやFirewallが配置されている場合は、それらのログも確認してください。SSL終端の設定不備、証明書エラー、ヘッダ不足、タイムアウト、Firewallルールによる通信ブロックなどは、PleasanterやWebサーバのログでは確認できません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up