Hmm, ok I course-correct myself and add 1 more cent to the discussion. So, as per my understanding of Brendan's thought process, I think there is greater value in inserting BPF/bcc at the snap and collectd stage (so that we basically outsource the trace management to these early event collection interfaces). Alternatively, I think we can have a BCC specific uniform interface that provides this trace management and control (and risk getting in domain of sounding like a complete tracing system). I would let experts give their opinion on what is more congenial here. A uniform interface would allow a better control over what is collected. This would allow an interface to other event collection systems such as snap etc. It may also simplify the task of custom-implementations of plugins for all such systems eventually
> Scope by Weaveworks: > * HTTP Stats plugin : > https://github.com/weaveworks-plugins/scope-http-statistics > * tcptracer-bpf : https://github.com/weaveworks/tcptracer-bpf > [Kinvolk's effort] > > Vector > * There was some discussion that died down : > https://github.com/Netflix/vector/issues/74 > > Graylog > InfluxDB - time series event collection > Prometheus > Fluentd > Grafana - time series visualizations > Sysdig > LTTng - if they agree to support events collected from eBPF. It > already allows perf contexts > (http://lttng.org/docs/v2.9/#doc-adding-context) > Trace Compass (visualize stored CTF/XML/JSON or "whatever format" > traces. We can define our own views in XML that we may package with > eBPF tools - stuff which I am working on in my free time) > HoneyComb > Catapult (Chrome Trace Viewer) So, in view of the above, out of this list, the only relevant addition I gave is fluentd/LTTng. We just need to be sure that collected event data format is compact enough so that we don't lose events as they are delivered. I have mostly worked with post-mortem analysis usecase (C2) only and primary concern there is less event loss as incoming trace data is huge and analysis needs to have as much events as possible for a better picture. -- Suchakra _______________________________________________ iovisor-dev mailing list [email protected] https://lists.iovisor.org/mailman/listinfo/iovisor-dev
