Streaming egress options

timmydo commented 3 years ago

Background and Motivation

Reflecting on #85, I am thinking about a more generic option for egress. When running in a container, a rolling file egress may not make as much sense, given a container's lifetime. There are lots of ways the trace information could be egressed, but I would like to consider hooking into a purpose-built egress tool rather than implementing all the sinks that they implement. The scenario primarily revolves around having dotnet-monitor always connected to a specific .NET process and listening for custom events that are emitted.

Proposed Feature

The proposed feature is to add egress options that support fluentd or vector. The trace information may no longer be in the nettrace format, but the same data could still be exported and analyzed with other tools. Transforms, filtering, and aggregation could be done by these logging tools and all their features would be at our disposal.

Usage Examples

Egress dotnet trace data to fluentd running on a unix domain socket. Have it forward data to another fluentd instance and write rolling file logs and filter some other data and send it to azure blobs.
Egress dotnet trace data to vector, have it generate metrics for GC events and write to prometheus, send some other events to clickhouse.

wiktork commented 2 years ago

jgador commented 1 year ago

I support this feature request for continuous log collection and egress. It would greatly enhance the monitoring capabilities of this tool.

Please count my vote!

dotnet / dotnet-monitor