Log and audit

SFTPPlus records activity and security events on each cluster node. You can collect and review these events in three ways. Choose the approach that fits your traffic volume, retention policy, and existing monitoring tools. Each option is described in more detail below:

• Embedded activity log: Forward node events to the controller and review them in the Web Manager.

• External log system: Write events to local files and use a collection agent to send them to a dedicated log platform.

• Kubernetes pod logs: Collect events from container standard output and query them through a log platform such as Loki and Grafana.

Embedded activity log

Cluster nodes can forward selected events or all events to the SFTPPlus controller. Store the forwarded events with a database event handler and review activity from all nodes in the controller's Web Manager Activity Log. Configure forwarding through the controller's node-sync resource; see Audit events.

This is useful for small clusters with low event volume. The embedded database offers a convenient activity log, but it cannot match the throughput, search capabilities, or flexibility of a dedicated log system.

External log systems

SFTPPlus can write events to local log files on each node. An agent for Splunk, Amazon CloudWatch Logs, Azure Monitor Logs, Google Cloud Logging, Datadog, or another log platform can then read those files and forward the entries. Configure the local file event handler's output format to match what the agent can parse. SFTPPlus can rotate the files and automatically delete older rotated files according to the configured retention settings. See log management for rotation and retention options.

Using local files gives the collection agent a buffer during a temporary connection failure. Keep the files long enough for the agent to catch up.

Kubernetes pod logs

In Kubernetes, you can use any of the approaches above, or collect the logs written to pod standard output. The SFTPPlus Helm chart configures a Standard Output Stream event handler in both the controller and worker containers with logfmt output, writing one structured event per line. The default fields include loglevel, peer_ip, and peer_port for log filtering. The chart preserves an existing controller configuration during an upgrade, so change its Standard Output Logger separately if it still uses plain text. See Logfmt output for the handler settings. The SFTPPlus Helm chart labels both controller and worker pods with service_name set to the Helm installation name. For an installation named sftpplus, both deployments therefore have service_name=sftpplus.

For example, Grafana Alloy can discover the pods in a namespace and attach the installation name to each Loki stream. This excerpt uses the standard Helm app.kubernetes.io/instance pod label, which has the same value as service_name:

discovery.kubernetes "sftpplus" {
  role = "pod"
  namespaces {
    names = ["manual-tests"]
  }
  selectors {
    role = "pod"
    label = "app.kubernetes.io/name=sftpplus,app.kubernetes.io/instance=sftpplus"
  }
}

discovery.relabel "sftpplus" {
  targets = discovery.kubernetes.sftpplus.targets
  rule {
    source_labels = ["__meta_kubernetes_pod_label_app_kubernetes_io_instance"]
    target_label = "service_name"
  }
  rule {
    source_labels = ["__meta_kubernetes_namespace"]
    target_label = "namespace"
  }
}

loki.source.kubernetes "sftpplus" {
  targets = discovery.relabel.sftpplus.output
  forward_to = [loki.write.local.receiver]
}

loki.write "local" {
  endpoint {
    url = "http://sftpplus-loki.grafana.svc:3100/loki/api/v1/push"
  }
}

Alloy also needs Kubernetes permissions to read pods and pod logs. The complete deployment example is in infrastructure/onpremise/alloy.yaml in the SFTPPlus server repository. Set the namespace, selector, and Loki URL for your installation.

In Grafana Explore, select the Loki data source, set the time range to Last 12 hours, and enter this LogQL query to see both controller and worker logs:

{namespace="manual-tests", service_name="sftpplus"}

The example SFTPPlus logs dashboard uses the same service_name label and a 12-hour time range. Configure retention in the destination log system separately from SFTPPlus local file retention.