# Reading Logs
**Audience:** IT admins who need to find, read, and use Keeper Privilege Manager logs for troubleshooting and compliance. *** ### Overview Keeper Privilege Manager uses **centralized logging**: the main service and plugins send log messages to a **Logger** component (e.g. KeeperLogger plugin), which writes them to **log files** and optionally to system logs or an HTTP endpoint. Understanding where logs are and how they’re formatted helps you troubleshoot policy denials, job failures, and registration or plugin issues. *** ### Where the Log File Is Log file **location** is configurable. Typical defaults: * **Under the Logger plugin directory:** e.g. `Plugins/Logger/bin/Release/net8.0/Log/` or a similar path under the application root. The exact path can be in the Logger plugin config or in application settings. * **File name pattern:** Often date-based, e.g. `KeeperLoggerYYYYMMDD.log` (one file per day). * **Application root:** On Windows, application root is often `C:\Program Files\KeeperPrivilegeManager`; on Linux/macOS, something like `/opt/keeper/`. So a full path might look like `C:\Program Files\KeeperPrivilegeManager\Plugins\Logger\...\Log\KeeperLogger20250223.log`. Check the **KeeperLogger** (or Logger) plugin configuration for: * **log.file.path** — Log file path (may use variables like `{approot}`). * **log.retention.days** — How long to keep old log files. * **log.rotation.size\_mb** — Rotate to a new file when this size is reached. If you’re unsure, search the install directory for `*.log` or look in the Logger plugin folder for a `Log` subdirectory. *** ### Log Levels Logs are emitted at different **levels**. Common levels (from least to most severe): * **Debug** — Detailed diagnostic information (noisy; use for deep troubleshooting). * **Information** — Normal operations (e.g. job started, policy evaluated). * **Warning** — Recoverable or unexpected conditions (e.g. optional step failed, fallback used). * **Error** — Failures (e.g. task failed, plugin crash). * **Critical** — Severe failures that may affect service stability. The **minimum level** written to the log file (or to the Logger) is usually configurable (e.g. in plugin settings or appsettings). In production, **Warning** or **Information** is typical; for troubleshooting, **Debug** gives the most detail. Error and Critical are often always written even when the minimum level is higher. *** ### Log Format and Structure Log entries are usually **structured** (e.g. JSON or a consistent text format) so you can search and parse them. A typical entry might include: * **Timestamp** — When the event occurred (often UTC or local). * **Level** — Debug, Information, Warning, Error, Critical. * **Component / category** — Which part of the system logged (e.g. KeeperPolicy, JobService, KeeperLogger). * **Message or event name** — Short description or event code (e.g. POLICY\_EVALUATION, JOB\_TRIGGERED, AGENT\_REGISTERED). * **Context** — Optional key-value data: correlation id, job id, policy id, user, path, exit code, etc. **Example (conceptual):** ``` 2025-02-23T14:30:00Z [Information] [KeeperPolicy] POLICY_EVALUATION PolicyId=policy-123 Result=Deny User=DOMAIN\jane Application=C:\Windows\System32\mmc.exe ``` Or in a JSON-style line: ``` {"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"} ``` Use **grep**, **findstr**, or a log viewer to search by level, component, event name, policy id, user, or correlation id. Correlation ids help you follow a single request across multiple log lines. *** ### What to Look for When Troubleshooting * **Policy denials:** Search for the policy id, event type (e.g. PrivilegeElevation), and “Deny” or “ApplicablePolicyIds: 0”. Check which policies were evaluated and why none allowed the request (e.g. filters didn’t match, or admin fallback denied). See [Architecture](https://docs.keeper.io/en/keeperpam/privileged-access-manager/getting-started/architecture). * **Job failures:** Search for the job id and “JOB\_EXECUTION”, “Task”, “exit code”, or “Failed”. Check which task failed and the exit code or error message. * **Registration:** Search for “AGENT\_REGISTER”, “AGENT\_REGISTERED”, or “REGISTER\_ERROR” to see whether registration succeeded or why it failed. * **Plugin startup:** Search for plugin name and “started”, “failed”, or “crashed” to see if a plugin failed to start or exited unexpectedly. * **Errors and critical:** Filter by level Error and Critical to see all failures in a time range. *** ### Rotation and Retention * **Rotation:** Logs may rotate by **date** (new file per day) or by **size** (new file when current file reaches a limit in MB). Old files are kept according to **retention** (e.g. 30 days). Configurable via Logger plugin settings. * **Disk space:** Ensure the log directory has enough space; adjust retention or size limits if logs grow too large. *** ### System Logs (fallback) When the Logger plugin is unavailable or for critical errors, the **main service** may write to **system logs** (Windows Event Log, systemd journal, or macOS unified logging). Check Event Viewer (Windows), `journalctl -u keeper-privilege-manager` (Linux), or Console.app (macOS) for Keeper Privilege Manager or the service name. These are a fallback; the primary place for detailed, structured logs is the Logger log file.