# ログの確認

**対象:** トラブルシュートやコンプライアンスのために、Keeper特権マネージャーのログを見つけ、読み、活用する必要があるIT管理者向けです。

***

## 概要

Keeper特権マネージャーでは、ログは**集中管理**されます。メインサービスとプラグインからのログメッセージは**Logger**コンポーネント (例: KeeperLoggerプラグイン) に送られ、**ログファイル**に書き込まれ、必要に応じてシステムログやHTTPエンドポイントへも出力されます。ログの保存場所と形式を押さえると、ポリシーによる拒否、ジョブの失敗、登録やプラグインまわりの不具合を調べる際に役立ちます。

## ログファイル名の規則 (プラットフォーム共通)

アクティブなログファイルは `KeeperLogger.log` です。ローテーションは日付が変わったタイミングか、サイズ上限に達したときに行われ、ファイル名は `KeeperLogger_YYYYMMDD.log` または `KeeperLogger_YYYYMMDD_HHMMSS.log` に変更されます。保持は `logRetentionDays` の設定に従い (既定は15日)、古いローテーション済みファイルから自動削除されます。アクティブなファイル自体は保持ポリシーでは削除されません。

* **ファイル名のパターン:** 日付ベースであることが多く、例として `KeeperLoggerYYYYMMDD.log` (1日1ファイル) です。

## ログファイルの場所

以下に示す既定のログファイルパスは、既定のインストールレイアウトを前提としています。一方で、実際の保存場所は KeeperLoggerプラグインの構成によって変わります。組織でインストール先を変更したり、非標準パスに展開したり、セットアップ時にログ出力先を明示したりした場合、既定と異なる場所にログが置かれることがあります。パスを前提にする前に、有効な構成を直接確認してください。

{% hint style="danger" %}
デプロイごとのログファイルの場所は、KeeperLoggerプラグインの構成で指定されている場合があります。
{% endhint %}

KeeperLoggerプラグイン構成のうち、ログの出力先と管理に関わる主な設定は以下のとおりです。

* `log.file.path` — ログファイルを書き込むディレクトリです。`{approot}` のように、実行時にインストールルートへ展開されるパス変数を使えるため、KEPMのインストール場所がマシンごとに異なっても同じ設定を流用しやすくなります。
* `log.retention.days` — ローテーション済みログを何日分保持するかです。最も古いファイルから自動削除されます。
* `log.rotation.size_mb` — ログファイルがこのサイズ (MB) に達したときにローテーションし、新しいファイルを開始する上限です。

{% hint style="info" %}
不明な場合は、インストールディレクトリで `*.log` を検索するか、Loggerプラグインフォルダ内の `Log` サブディレクトリを確認してください。
{% endhint %}

### 既定のログファイルパス

ログの**保存場所**は構成で変えられます。多くの環境で想定される既定は以下のような形です。

* **Loggerプラグインディレクトリ配下:** 例として `Plugins/Logger/bin/Release/net8.0/Log/` や、アプリケーションルートから見た同様のパスです。正確なパスは Loggerプラグインの構成またはアプリケーション設定に記載されていることがあります。
* **ファイル名のパターン:** 日付単位であることが多く、例として `KeeperLoggerYYYYMMDD.log` (1日1ファイル) です。
* **アプリケーションルート:**
  * Linux `/Library/Keeper/sbin/Plugins/bin/KeeperLogger/Log`
  * macOS `/opt/keeper/sbin/Plugins/bin/KeeperLogger/Log`
  * Windows `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件)

```
2025-02-23T14:30:00Z [Information] [KeeperPolicy] POLICY_EVALUATION PolicyId=policy-123 Result=Deny User=DOMAIN\jane Application=C:\Windows\System32\mmc.exe
```

JSON風の1行の例:

```
{"timestamp":"2025-02-23T14:30:00Z","level":"Information","component":"KeeperPolicy","event":"POLICY_EVALUATION","policyId":"policy-123","result":"Deny","user":"DOMAIN\\jane","application":"C:\\Windows\\System32\\mmc.exe"}
```

レベル、コンポーネント、イベント名、ポリシーID、ユーザー、相関IDなどで、**grep**、**findstr**、またはログビューアを使って検索できます。相関IDは、1つのリクエストに関する複数行をたどるのに役立ちます。

***

### トラブルシュートで見るポイント

* **ポリシーによる拒否:** ポリシーID、イベント種別 (例: PrivilegeElevation)、「Deny」または「ApplicablePolicyIds: 0」で検索します。どのポリシーが評価され、なぜいずれもリクエストを許可しなかったか (フィルター不一致、管理者向けフォールバックによる拒否など) を確認します。詳細については、[アーキテクチャ](/keeperpam/jp/privileged-access-manager/getting-started/architecture.md)をご参照ください。
* **ジョブの失敗:** ジョブ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で、Keeper特権マネージャーまたはサービス名を確認してください。こちらは補助的な出力であり、詳細な構造化ログの主な参照先はLoggerのログファイルです。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/user-guides/reading-logs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.