Operations
Operational visibility without workplace surveillance
When a development machine slows down, the team needs an explanation. It does not follow that every command line should be stored centrally or every activity attributed to a person. Between operating blindly and comprehensive surveillance lies an important design task: which observation supports which decision? Who may see it? And how long does it actually need to survive to serve the purpose for which it was collected?
Start with the operational question, not collection
Asking which workload is consuming available memory requires different data from asking who entered which commands today. When both purposes are combined in one tool, technical diagnosis can quietly become an individual activity history. To make a sound decision, first describe the operational problem you need to solve, then select the observations actually required to investigate that problem rather than collecting everything available.
My open-source project system-health-nix focuses on local Linux workstations: it examines resource use by processes, workloads and control groups. Its reports include CPU activity, memory, input and output, and resource pressure. According to its documentation, this requires no persistent daemon, database, network listener or telemetry. The purpose of observing a workstation therefore does not automatically require introducing a central service.
Fewer identifiers do not make data harmless
An optional local history function in system-health-nix records aggregate resource peaks. It omits process names, process identifiers, command lines and host identity. That is a deliberate restriction on the data footprint. It answers a different question from a complete process history: how heavily the system was loaded, rather than which particular command ran at every point during someone's work.
The documentation still treats these aggregate values as private operational data. That is a useful standard for teams: aggregation is not an automatic anonymity guarantee or permission for unrestricted sharing. Define who can access the records and when they are deleted. If additional central collection is proposed, it needs its own justification rather than an assumption that technical metrics are inherently harmless.
Measurement gaps are part of the result
A short local sample can explain a current bottleneck but miss short-lived processes. A quiet measurement does not establish that nothing happened beforehand. System-health-nix explicitly acknowledges these limits. A report without a warning cannot support a comprehensive conclusion about unobserved resources or other periods. For a decision-maker, that distinction matters just as much as the display of an unusually high value.
More data is not necessarily the right response to every measurement gap. Sometimes a targeted repeat during the affected workflow is sufficient; sometimes the problem needs a different kind of diagnosis. The important step is to name the specific uncertainty. Otherwise an incomplete snapshot is either overrated as reassurance or used to justify a disproportionately comprehensive record of activity unrelated to the original operational question.
Remote assistance need not copy the working environment
My open-source project shell-away opens a temporarily adapted interactive shell on a Linux or macOS SSH target. It transfers generated, non-secret shell assets, not local history, credentials, environment variables or desktop configuration. Its default mode downloads nothing. This provides a more familiar working interface without transferring somebody's entire personal environment as a package onto another machine just to make remote work convenient.
That restriction is not a promise of a traceless session. The optional Nix mode can download or build packages that remain in the target's store. Agent forwarding, graphical forwarding and port forwarding are disabled, but the session is not a sandbox. Which commands a person can run and which data they can reach remain questions about the actual permissions on the target system.
Explain honestly what remains
Shell-away normally removes its session files on exit or handled signals. An abrupt termination can nevertheless leave files behind. The SSH server and commands executed during the session can also create logs or other state independently. Temporary therefore describes a limited part of the workflow; it must not be confused with a promise that absolutely nothing will remain on the target afterwards.
For me, both projects express the same operational choice: create visibility deliberately and disclose its cost in data and residual state. That replaces neither an organisation's internal policy nor an assessment of a particular deployment. It does make a concrete agreement possible: we collect these observations for this diagnosis, understand the gaps and explain what survives a session, instead of asking people to trust sweeping assurances.
Questions for your team or vendor
- Which specific operational decision requires the collected data, and which available data would be unnecessary?
- What stays local, what is transmitted and who may inspect the results?
- Which identifiers are omitted from history, and why does the remaining data still need protection?
- Which short-lived events or periods can the measurement fail to cover?
- What remains on the target after normal exit, disconnection or abrupt termination?
- Who decides whether collection is expanded and how long records are retained?