Download the PHP package ayaou/command-logger-bundle without Composer

Command Logger Bundle

Overview

The Command Logger Bundle is a Symfony bundle that logs executed console commands. It provides insights into command execution, including arguments, execution time, exit codes, and errors.

Installation

Install the bundle via Composer:

Register the bundle in config/bundles.php if not automatically added:

Configuration

Add the following configuration in config/packages/command_logger.yaml:

Usage

Enabling Logging on a Command

Use configuration commands array (if not using attributes) Or:

Use the CommandLogger attribute on any Symfony command to enable logging:

Entity Structure

The logs are stored in the command_log table with the following fields:

• commandName – Name of the executed command
• arguments – Command arguments in JSON format
• startTime – Execution start time
• endTime – Execution end time
• exitCode – Command exit code
• durationMs – Execution duration in milliseconds, or null when unknown (see "Command Execution Statistics" below)
• errorMessage – Error message if applicable
• output – What the command printed, or null unless output capture is enabled (see "Capturing Command Output" below)
• executionToken – Unique identifier for execution tracking

Using a Separate Entity Manager

By default, the command_log table lives in the application's default Doctrine entity manager, alongside the application's own entities. Setting entity_manager targets a different, named entity manager instead - typically one backed by its own, separate database connection:

Two consequences follow from this, both intentional:

• Schema creation needs --em=command_logs. Since command_log is no longer part of the default entity manager, Doctrine's own commands must be told which one to target, e.g. bin/console doctrine:schema:update --em=command_logs --force (or the equivalent migration command for your setup).
• The log no longer participates in the application's database transactions. A command log entry lives in its own connection, so it is written independently of - and survives - a rollback of whatever the application itself was doing. That is precisely the point of moving it to a separate database: an execution log should still exist even when the command it describes failed and rolled back its own changes.

Capturing Command Output

By default a log row tells you whether a command succeeded, not what it said while doing so. Turn on output capture and the row carries the command's own output next to its exit code:

The captured output is also exposed on the API's item endpoint, in the command_log:item serialization group.

Why it is off by default

A command may print anything, and that includes secrets. The sensitive_parameters redaction works on argument and option names; nothing can reliably recognise a secret inside free-form prose. Storing output is therefore a decision you make explicitly, for commands whose output you know.

What it costs the observed command

Nothing while disabled: no stream filter is registered and no stream is touched.

While enabled, the cost is one bounded string append per write:

Memory is bounded by max_length and by nothing else. Once that many bytes have been captured, nothing further is retained and the stored value is suffixed with " [truncated]" - so a command printing a gigabyte costs exactly what one printing a kilobyte costs.

What it captures, and what it does not

Capture works by observing the stream behind the command's output, so:

• stdout and stderr written through Symfony's OutputInterface are captured - including everything SymfonyStyle produces.
• echo, print and PHP warnings are not. They go through PHP's own output layer, which stream filters never see.
• Outputs with no stream behind them are left alone - NullOutput and BufferedOutput capture nothing, and are not disturbed.
• A command killed before it terminates leaves output null, exactly as it leaves endTime and exitCode null: nothing runs to store what it had printed so far.
• Escape sequences are stripped before storage. Colours are not preserved, on purpose: the value is replayed later by command-logger:show and by the API, and a stored escape sequence is an instruction for whichever terminal renders it.

Failure Behavior

The bundle never lets its own storage break the command it is logging. If writing to the command_log table fails for any reason — the table doesn't exist yet, the database is unreachable, the entity manager was already closed by a previous error — the listener gives up on that write and lets the command carry on (or, for the error listener, lets the original exception propagate to the user unchanged).

When this happens, an error is emitted on the application's logger service (if one is configured), naming the command and including the underlying exception. If no logger service is available, the bundle stays silent and the command is unaffected either way.

The level is error, not warning, for two reasons. A log entry that could not be written is a runtime error in PSR-3 terms, not an exceptional-but-benign occurrence. And Symfony's fallback logger — the one an application without Monolog gets — only emits error and above, so a warning would have been dropped on exactly the bare setups where a silent empty table is hardest to diagnose.

Show Command Logs

The command-logger:show command displays logged command executions from the command_log table. It supports filtering, pagination, and viewing specific entries by ID.

Description

This command retrieves and displays command execution logs. By default, it shows the latest 10 entries, ordered by startTime in descending order, in a tabular format. You can filter by command name, exit code, or success/error status, and view a single entry by ID.

The command supports pagination, allowing you to press Enter to view more entries interactively.

Arguments

• name (optional): Filters logs by the command name (e.g., app:example-command).

Options

• --limit|-l (optional): Specifies the number of entries to show per page (default: 10).
• --code|-c (optional): Filters logs by a specific exit code (e.g., --code=0 for successful commands).
• --id (optional): Displays a single log entry by its ID (e.g., --id=123). When used, no other arguments or options are allowed.
• --error (optional): Filters logs to show only entries with non-zero exit codes (indicating errors). Cannot be used with --success or --code.
• --success (optional): Filters logs to show only entries with an exit code of 0 (indicating success). Cannot be used with --error or --code.
• --from (optional, Y-m-d or Y-m-d H:i:s): Only include logs started on or after this date/time.
• --to (optional, Y-m-d or Y-m-d H:i:s): Only include logs started on or before this date/time.

Purging Old Logs

The bundle includes an automatic mechanism to purge logs older than the configured purge_threshold. You can also manually trigger log cleanup using the following command:

By default, this uses the purge_threshold value from the configuration. To override it, specify a custom threshold (in days) with the --threshold or -t option:

For example, --threshold=30 removes logs older than 30 days

Command Execution Statistics

:warning: Schema update required. The durationMs column is new. After upgrading, run doctrine:schema:update --force (or apply an equivalent migration) before using this feature. Rows logged before the upgrade have no way to recover a duration and will keep durationMs = null forever; they are excluded from the duration averages/min/max below, not counted as zero.

The command-logger:stats command aggregates the command_log table into a summary, a breakdown by exit code, and a breakdown by command name.

Arguments

• name (optional): Filters statistics by command name (exact match on the "name contains" filter, same as the name query parameter of the REST API).

Options

These mirror the REST API's CommandLogFilter exactly, so the numbers here are computed over the same rows a matching GET /command-logs request would list:

• --status (optional): success or error. Cannot be combined with --code.
• --code|-c (optional): Filters by a specific exit code.
• --from (optional, Y-m-d or Y-m-d H:i:s): Only include logs started on or after this date/time.
• --to (optional, Y-m-d or Y-m-d H:i:s): Only include logs started on or before this date/time.
• --limit|-l (optional, default 10): Number of commands to show in the per-command breakdown.

Metrics

• Total – Number of logs matching the filter.
• Successes – Logs with exitCode = 0.
• Failures – Logs with exitCode != 0.
• Unfinished – Logs with endTime IS NULL. This means the command never reached console.terminate: it may have been killed, crashed, or it may simply still be running right now, at the moment the statistics were computed. There is no way to tell the two apart from this table alone.
• Failure rate – Failures / Total, computed in PHP so an empty result set never divides by zero.
• Duration (avg / min / max) – In milliseconds, computed only over logs that actually have a durationMs value. Unfinished logs and logs predating the schema update are excluded from these figures rather than treated as 0.
• Measured executions – How many of the matched logs contributed a durationMs value to the duration figures above.
• Breakdown by exit code – Count of logs for each distinct, non-null exitCode.
• Breakdown by command – The same set of metrics grouped by commandName, sorted by total volume (descending) and capped at --limit entries.

These aggregations only use COUNT, AVG, MIN, MAX and GROUP BY, so they run unchanged on every database engine this bundle supports — there is no median, no percentile, and no time-bucketed series in this feature.

REST API

The bundle can optionally expose the command log history over a read-only JSON-LD/Hydra REST API. It is disabled by default and must be opted into explicitly.

:warning: Security warning

These endpoints expose the full command execution history, including command arguments. They ship with no access control of any kind — anyone who can reach the routes can read every logged command and its arguments. Protecting them is entirely the consuming application's responsibility: restrict the path with access_control in security.yaml (or an equivalent firewall rule) before exposing this API outside of trusted networks. This is the single most important thing to get right before enabling this section — read it before you do.

Enabling api.enabled may be all it takes to expose the routes. On a Symfony 7.4 or 8.x application (any skeleton generated with the default config/routes.yaml, which imports resource: routing.controllers), that loader automatically routes the #[Route] attributes of every controller registered as a service — including this bundle's, the moment api.enabled turns it into one. The routes then appear in debug:router with no import of config/routes.yaml required at all. Symfony 6.4 skeletons scope that same loader to App\Controller only, so there the explicit import below is still what exposes the API. Either way, put the access_control rule in place before setting api.enabled: true in any environment you don't fully control — do not rely on "I haven't imported the routes yet".

Enabling the API

Two things gate the API, and both are opt-in — and a third, protecting it, is on you:

1. Turn on the API services — this is the flag that matters most, since it is what can expose the routes on its own on Symfony 7.4/8.x (see the warning above):

2. Find out where the routes actually are, with bin/console debug:router. Do not assume — the answer depends on your application's config/routes.yaml, and it decides which path you have to protect.

If they are already listed (Symfony 7.4/8.x default skeleton), step 1 was enough: the routing.controllers loader picked the controller up the moment it became a service, and the endpoints are served at /command-logs. Importing the routes file cannot move them. That import is read after the routes already exist, so a prefix set there is silently ignored — you would get a 404 on the prefixed path while the real one stays open. Do not import anything.

If nothing is listed (Symfony 6.4 skeleton, or any application whose controller import is scoped to App\Controller), import the routes yourself. Here the prefix does apply:

3. Protect the path debug:router printed, not the one you expected. Guarding ^/api/command-logs while the routes are served at /command-logs leaves the API wide open and looks protected, which is worse than leaving it visibly unprotected:

Endpoints

Route names are prefixed with command_logger_api_ (e.g. command_logger_api_list, command_logger_api_stats, command_logger_api_item), following Symfony's naming convention for bundle-provided routes.

Like the rest of this REST API, /command-logs/stats exposes exactly the same aggregated data as the command-logger:stats CLI command and the log list above — it stays behind the same command_logger.api.enabled flag and the same security warning at the top of this section: put your own access_control rule in place before enabling it.

Query parameters

The parameters below apply to both GET /command-logs and GET /command-logs/stats, and can be combined, unless stated otherwise. On /command-logs/stats, page is not used (there is nothing to paginate) and limit instead caps how many commands appear in the per-command breakdown.

• page (optional, integer, default 1) — Page number to return; must be positive. Ignored by /stats.
• limit (optional, integer, default 10) — Number of entries per page; must be between 1 and 100. On /stats, the number of commands returned in the per-command breakdown.
• name (optional, string, minimum length 2) — Filters logs whose command name contains this value.
• status (optional, string, one of success or error) — Filters by outcome. Cannot be combined with code.
• code (optional, integer) — Filters by exact exit code. Cannot be combined with status.
• from (optional, string, Y-m-d or Y-m-d H:i:s) — Only logs started on or after this date/time.
• to (optional, string, Y-m-d or Y-m-d H:i:s) — Only logs started on or before this date/time. Must not be earlier than from.

Invalid or conflicting parameters return 422 Unprocessable Entity with a Problem Details (application/problem+json) body listing the offending violations, each with its propertyPath. Unknown ids return 404 Not Found in the same Problem Details format.

Statistics response

GET /command-logs/stats wraps the same figures as the command-logger:stats CLI command in a JSON-LD envelope: a summary (volume by outcome, failure rate, duration extrema), a byExitCode breakdown, and a byCommand breakdown bounded by limit.

License

MIT License