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.
Log File Naming Convention - Platform Agnostic
The active log file is KeeperLogger.log. On rotation — either at midnight or when the size limit is reached — it is renamed to KeeperLogger_YYYYMMDD.log or KeeperLogger_YYYYMMDD_HHMMSS.log. Files are retained based on the logRetentionDays setting (default: 15 days), after which the oldest rotated files are deleted automatically. The active file is never deleted by the retention policy.
File name pattern: Often date-based, e.g.
KeeperLoggerYYYYMMDD.log(one file per day).
Where the Log File Is
The default log file paths listed below reflect the default installation layout. However, the exact location of log files on any given deployment depends on how the KeeperLogger plugin has been configured. If your organization customized the installation directory, deployed to a non-standard path, or explicitly set a log output location during setup, the log files may be in a different location than the defaults shown. Before assuming a path, verify the active configuration directly.
Log file locations for any given deployment may be configured in the KeeperLogger plugin configuration.
The following settings in the KeeperLogger plugin configuration control where logs are written and how they are managed:
log.file.path— The directory where log files are written. This value may use path variables such as{approot}which resolves to the installation root at runtime, making the setting portable across machines regardless of where KEPM is installed.log.retention.days— How many days of rotated log files to retain before the oldest are deleted automatically.log.rotation.size_mb— The maximum size a log file can reach before it is rotated and a new file is started.
If you’re unsure, search the install directory for *.log or look in the Logger plugin folder for a Log subdirectory.
Default Log File Paths
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:
Linux
/Library/Keeper/sbin/Plugins/bin/KeeperLogger/LogmacOS
/opt/keeper/sbin/Plugins/bin/KeeperLogger/LogWindow
C:\Program Files\KeeperPrivilegeManager;
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):
Or in a JSON-style line:
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.
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.
Last updated
Was this helpful?