SSH log monitoring with a managed probe

Availability: available

The managed log probe monitors regular Linux log files. Mendry installs a fixed probe over the project’s saved SSH private key. AI generates schema-constrained rules; it does not generate or execute arbitrary scripts.

Requirements

• An SSH source using host deployment and tail mode.
• A Linux SSH user that can read the configured absolute log path. The path must not contain spaces, tabs, or line breaks.
• Python 3.6 or newer, a running systemd instance, and non-interactive sudo -n on the host.
• Outbound HTTPS access to MENDRY_PUBLIC_URL.
• A saved custom-rule trigger. AI generation additionally requires a configured LLM provider.

Setup

1. Enter the SSH host, user, and private-key credential under Collection source. For Host process deployments, select Browse remote files, navigate to a readable log file on the host, select it, and save the source. You can also enter an absolute file path manually.
2. Select Managed log probe under Trigger.
3. Add contains/regex rules manually, or generate one from an intent and redacted sample.
4. Paste redacted expected error and non-error lines into Test rules and select Run test. Review missed error lines, unexpected matches, and exclusions; the test uses the unsaved rule draft and does not send an alert.
5. Review the ID, pattern, threshold, detection window, exclusion regex, and cooldown, then save.
6. Select Enable monitoring. Before writing files, Mendry checks the host’s service manager, probe user, and Python version, then uses the detected Python path in the systemd unit. The install request returns starting when the remote install command completes; the page checks status separately and confirms monitoring only when the current probe reports a fresh monitoring status.

File browsing uses the current SSH form values before the source is saved. It lists a single directory as the SSH user without reading log contents. Each response contains at most 100 files or directories, with a notice when results are truncated. Directories are navigation targets; select a specific file for the log path.

The first run starts at the end of the file. The probe persists its inode and offset, starts a rotated file at its beginning, spools events before delivery, and only sends strict events for the active trigger version and rule IDs.

Trigger semantics

• threshold: the number of matching lines required within the detection window.
• windowSeconds: the rolling window used to count matches.
• cooldownSeconds: the quiet period after the same rule fires.
• groupingWindowSeconds: retained as incident grouping configuration; it does not replace the detection window.
• excludePattern: a regular expression that excludes lines even when they match the main rule.

Configure 1–20 rules with unique IDs matching ^[a-z][a-z0-9_-]{0,63}$. Thresholds range from 1–10,000 lines, detection windows from 1–86,400 seconds, and cooldowns from 0–86,400 seconds. For example, a contains rule for ERROR with threshold 3, window 60, and cooldown 300 fires after three matching lines within 60 seconds, then suppresses the same rule for five minutes.

A stable event ID becomes the incident fingerprint. Retrying the same event updates the same incident instead of creating another; a lost delivery response can still result in a duplicate observation.

Verify monitoring

The rule test checks line matching only. It cannot prove that enough lines will arrive within windowSeconds, that delivery succeeds, or that future error formats match. Complex regex constructs outside the trial matcher subset are rejected rather than reported as a passing test. The pasted lines are not sent to the LLM or stored; use redacted examples. Editing rules or samples invalidates the visible result.

Wait for a fresh monitoring status after installation. Then have the application write new matching lines to the selected file until the rule’s threshold is reached within its detection window. Historical lines from before the first start are not replayed. Inspect the project’s event stream and incident list for the resulting signal and incident.

If nothing appears, check the exclusion pattern, cooldown, and delivery status before changing the rule. See troubleshooting.

Operations

Status is read over SSH from systemd and the probe status file. Uninstall stops the service and removes its program, token-bearing configuration, cursor, and spool.

After rotating the trigger token or changing the trigger configuration, run Install or update immediately. Old tokens and stale configuration versions are rejected. Permanently rejected events (such as invalid or stale requests) move to /var/lib/mendry-log-probe/rejected rather than blocking subsequent deliveries. The status remains degraded until those files are reviewed and cleared; uninstall removes the directory. Retryable failures, including 429 and 5xx responses, remain in the spool.

When switching from the managed probe to a signed webhook, disable the previous probe from the Trigger page while the saved SSH host is still available. If the SSH source or host is replaced first, Mendry no longer has the original connection details and the service must be removed on the old host.

The current release supports one regular Linux file. Docker stdout, journald, multiline aggregation, and missing-log rules are out of scope. The service and configuration paths are shared on each host, so installing a probe for another project on the same host replaces the existing probe configuration.