Repository navigation
Proposal: built-in tracing and metrics via ActivitySource/Meter #1854
Description
Hi, I'd like to propose adding built-in tracing and metrics to SSH.NET using System.Diagnostics.ActivitySource and Meter, the same approach Npgsql and the MongoDB driver use.
I first opened an OpenTelemetry contrib package that wraps ISftpClient/ISshClient (open-telemetry/opentelemetry-dotnet-contrib#5781). An OTel maintainer suggested building it into the library instead, so users only need AddSource("Renci.SshNet") and AddMeter("Renci.SshNet"). That also works with other backends (Datadog, App Insights), and covers cases a wrapper can't reach: CreateCommand + Execute, Begin*/End*, non-seekable streams.
I have a working prototype: https://github.com/YoussefElshemi/SSH.NET/tree/native-telemetry
- Spans:
Connect(ssh/sftp/scp/netconf)- SFTP
UploadFile,DownloadFile,ListDirectory SshCommandexecution
- Metric:
ssh.client.operation.durationhistogram (seconds) - Where it hooks in: the existing
Internal*methods, so every overload is covered - When nobody is listening: no allocation or extra work
- Tests: existing unit tests pass. New integration tests pass on net48/net8/net9/net10.
Questions before I go further:
- It adds
System.Diagnostics.DiagnosticSource(8.0.1) as a dependency on net462/netstandard2.0 only. Is that acceptable? - Attribute names like
ssh.operation.name,sftp.transfer.bytesandssh.command.exit_codearen't official OpenTelemetry names yet. Any preference? - Command text isn't recorded, since it may contain secrets. Should there be an opt-in?
- Should a first PR stay this small, or also cover
Exists/Delete/Rename/SCP?
Would you be open to a PR along these lines?
Activity
Rob-Hague commentedon Oct 27, 2026
I would be open to it, but I have only surface-level familiarity with Activity/Metrics/OpenTelemetry so I would not be the best judge of an implementation (@mus65?). I also can't guarantee review timing from my side. There is already a list of things I would like to address if ever I am motivated.
Yes, next month the Microsoft.Extensions.Logging.Abstractions dependency would be bumped to v10 which brings it in already.
I would like to know what precedent there is in existing clients or servers. I assume this is not the first implementation.
Probably not until there is explicit demand in the future
Without having studied the code, covering other SFTP operations sounds OK. SCP should not be touched as it is a legacy protocol whose use should be discouraged.
YoussefElshemi commentedon Oct 27, 2026
Thanks for the quick reply!
On attribute names: as far as I could find, this would be the first. OpenTelemetry's semantic conventions have no SSH or SFTP namespace, and I couldn't find built-in tracing in other SSH clients (Paramiko, JSch, Apache MINA SSHD, Go's x/crypto/ssh). The only SSH-related thing I found in the OTel ecosystem is the Collector's sshcheck receiver, which is a connectivity probe. It uses
ssh.endpointandsshcheck.*metrics.So the plan would be:
server.address,server.port,network.protocol.name,file.path,error.typessh./sftp.prefix (ssh.operation.name,sftp.transfer.bytes,ssh.command.exit_code)I'll drop the SCP changes, add the remaining SFTP operations (Exists, Delete, CreateDirectory, Rename, Get/SetAttributes, ChangeDirectory, etc.), and update the branch. No rush on review.
mus65 commentedon Oct 27, 2026
I'm not too familiar with these APIs either, but I could look into it and help out with review. The plan sounds good to me in general.
YoussefElshemi commentedon Oct 27, 2026
Opened #1857 with the changes discussed above: SCP is left untouched and the remaining SFTP operations are now covered. @mus65 thanks for offering to help review!