ログの確認
対象: トラブルシュートやコンプライアンスのために、エンドポイント特権マネージャーのログを見つけ、読み、活用する必要があるIT管理者向けです。
概要
エンドポイント特権マネージャーでは、ログは集中管理されます。メインサービスとプラグインからのログメッセージはLoggerコンポーネント (例: KeeperLoggerプラグイン) に送られ、ログファイルに書き込まれ、必要に応じてシステムログやHTTPエンドポイントへも出力されます。ログの保存場所と形式を押さえると、ポリシーによる拒否、ジョブの失敗、登録やプラグインまわりの不具合を調べる際に役立ちます。
ログファイル名の規則 (プラットフォーム共通)
アクティブなログファイルは KeeperLogger.log です。ローテーションは日付が変わったタイミングか、サイズ上限に達したときに行われ、ファイル名は KeeperLogger_YYYYMMDD.log または KeeperLogger_YYYYMMDD_HHMMSS.log に変更されます。保持は logRetentionDays の設定に従い (既定は15日)、古いローテーション済みファイルから自動削除されます。アクティブなファイル自体は保持ポリシーでは削除されません。
ファイル名のパターン: 日付ベースであることが多く、例として
KeeperLoggerYYYYMMDD.log(1日1ファイル) です。
ログファイルの場所
以下に示す既定のログファイルパスは、既定のインストールレイアウトを前提としています。一方で、実際の保存場所は KeeperLoggerプラグインの構成によって変わります。組織でインストール先を変更したり、非標準パスに展開したり、セットアップ時にログ出力先を明示したりした場合、既定と異なる場所にログが置かれることがあります。パスを前提にする前に、有効な構成を直接確認してください。
デプロイごとのログファイルの場所は、KeeperLoggerプラグインの構成で指定されている場合があります。
KeeperLoggerプラグイン構成のうち、ログの出力先と管理に関わる主な設定は以下のとおりです。
log.file.path: ログファイルを書き込むディレクトリです。{approot}のように、実行時にインストールルートへ展開されるパス変数を使えるため、KEPMのインストール場所がマシンごとに異なっても同じ設定を流用しやすくなります。log.retention.days: ローテーション済みログを何日分保持するかです。最も古いファイルから自動削除されます。log.rotation.size_mb: ログファイルがこのサイズ (MB) に達したときにローテーションし、新しいファイルを開始する上限です。
不明な場合は、インストールディレクトリで *.log を検索するか、Loggerプラグインフォルダ内の Log サブディレクトリを確認してください。
既定のログファイルパス
ログの保存場所は構成で変えられます。多くの環境で想定される既定は以下のような形です。
Loggerプラグインディレクトリ配下: 例として
Plugins/Logger/bin/Release/net8.0/Log/や、アプリケーションルートから見た同様のパスです。正確なパスは Loggerプラグインの構成またはアプリケーション設定に記載されていることがあります。ファイル名のパターン: 日付単位であることが多く、例として
KeeperLoggerYYYYMMDD.log(1日1ファイル) です。アプリケーションルート:
Linux
/Library/Keeper/sbin/Plugins/bin/KeeperLogger/LogmacOS
/opt/keeper/sbin/Plugins/bin/KeeperLogger/LogWindows
C:\Program Files\KeeperPrivilegeManager
ログレベル
ログはレベルごとに出力されます。軽いものから順に、たとえば以下の区分があります。
Debug: 詳細な診断情報 (出力が多い。深いトラブルシュート向け)
Information: 通常運用 (例: ジョブ開始、ポリシー評価)
Warning: 回復可能な異常や想定外 (例: 任意ステップの失敗、フォールバックの利用)
Error: 失敗 (例: タスク失敗、プラグインのクラッシュ)
Critical: サービス安定性に影響しうる重大な失敗
ログファイル (または Logger) に書き込まれる最小レベルは、多くの場合プラグイン設定や appsettings で変更できます。本番では Warning または Information が一般的で、トラブルシュートでは Debug が最も詳細です。Error と Critical は、最小レベルを上げていても多くの場合そのまま記録されます。
ログの形式と構造
ログエントリは、検索やパースがしやすいよう、多くの場合構造化されています (JSONや一貫したテキスト形式など)。典型的には、1件に以下のような項目が含まれます。
Timestamp: イベント発生時刻 (UTCまたはローカルであることが多い)
Level: Debug、Information、Warning、Error、Critical
Component / category: ログを出した機能領域 (例: KeeperPolicy、JobService、KeeperLogger)
Message or event name: 短い説明またはイベントコード (例: POLICY_EVALUATION、JOB_TRIGGERED、AGENT_REGISTERED)
Context: 任意のキーと値 (相関ID、ジョブID、ポリシーID、ユーザー、パス、終了コードなど)
例 (概念的な1件)
JSON風の1行の例
レベル、コンポーネント、イベント名、ポリシーID、ユーザー、相関IDなどで、grep、findstr、またはログビューアを使って検索できます。相関IDは、1つのリクエストに関する複数行をたどるのに役立ちます。
トラブルシュートで見るポイント
ポリシーによる拒否: ポリシーID、イベント種別 (例: PrivilegeElevation)、「Deny」または「ApplicablePolicyIds: 0」で検索します。どのポリシーが評価され、なぜいずれもリクエストを許可しなかったか (フィルター不一致、管理者向けフォールバックによる拒否など) を確認します。詳細については、アーキテクチャをご参照ください。
ジョブの失敗: ジョブIDと「JOB_EXECUTION」「Task」「exit code」「Failed」で検索します。どのタスクが失敗したか、終了コードやエラーメッセージを確認します。
登録: 「AGENT_REGISTER」「AGENT_REGISTERED」「REGISTER_ERROR」で検索し、登録の成否や失敗理由を確認します。
プラグイン起動: プラグイン名と「started」「failed」「crashed」で検索し、起動失敗や異常終了の有無を確認します。
Error と Critical: レベルで Error と Critical に絞り、期間内の失敗一覧を確認します。
ローテーションと保持
ローテーション: ログは日付 (1日1ファイル) またはサイズ (現在ファイルが上限MBに達したら新ファイル) で切り替わることがあります。古いファイルは保持期間 (例: 30日) に従って残ります。Loggerプラグインの設定で変更可能です。
ディスク容量: ログフォルダに十分な空きがあるかを確認し、ログが大きくなりすぎる場合は保持日数やサイズ上限を調整してください。
システムログ (フォールバック)
Loggerプラグインが使えない場合や重大なエラー時には、メインサービスが システムログ (Windowsイベントログ、systemdのジャーナル、macOSの統合ログなど) に書き込むことがあります。Windowsではイベントビューア、Linuxでは journalctl -u keeper-privilege-manager、macOSではコンソール.appで、エンドポイント特権マネージャーまたはサービス名を確認してください。こちらは補助的な出力であり、詳細な構造化ログの主な参照先はLoggerのログファイルです。
最終更新