The tracer is designed to send the metrics towards a telegraf server
using this kind of configuration:
[[inputs.socket_listener]]
service_address = "tcp://localhost:8094"
The telegraf server can then forward the metrics towards an influxdb
server for monitoring or directly to grafana live server[^1] for
introspection.
The influxdb database can also be used to query the metrics after
they've been indexed.
The application using the tracer can use the VLC_TELEGRAF_ENDPOINT
environment variable (eg. VLC_TELEGRAF_ENDPOINT=tcp://127.0.0.1:8094)
to set where the tracer will output the traces to.
A bunch of notes and improvement left for later:
- Unsafe code is still used for accessing the fields data since an
union is used and union access is unsafe. It could probably be
wrapped from the binding implementation.
- There is no way to specify the address using the configuration
since vlc_variable is not bound to the Rust bindings and no
unsafe extern "C" code is done from the plugin.
- The tracer currently panic as the telegraf server dies because it
doesn't handle reconnection. Proper reconnection logic with maybe
size-limited temporary storing might be a proper workaround for that.
- The tracer doesn't use the timestamp provided by VLC right now,
proper time conversion is required for it to work.
- There's no proper tags for the metrics being sent, which is an
issue given that tags are providing indexing on the data. The
tags should be generated from the string values of the tracer.
Maybe an additional "Role" should be added in the trace entry for
that purpose.
[^1]: https://grafana.com/blog/2021/08/16/streaming-real-time-telegraf-metrics-using-grafana-live/
The crates will be used by rust plugins, but we want to provide the
version from the workspace instead of specifying the path each time
relatively to the plugin crate manifest.
vlcrs_plugin exposes the base types to create plugin, much like
vlc_plugin.h in the C headers, and uses the vlcrs_core::object::Object
type. But vlcrs_core also needs vlcrs_plugin internally to define the
capabilities, and both need each other for tests also.
The same applies to vlcrs_macros when used in tests, which must stay
separated, but we can still provide it as a dev-dependencies and avoid
the cyclic reference.
Otherwise, stale files in any src/rust/vlcrs-*/ folder makes the folder
alive without manifest or with a non-complete manifest and everything
breaks...
The vlcrs-plugin crate exports structures matching vlc_plugin.h, which
is ough to be included by modules directly or indirectly (through
vlcrs-macros) to define every parts needed to setup the module manifest.
The current state exports a minimal set required for the current
vlcrs-macro code to work correctly.
Expose the version and license keys to every members of the workspace.
The rationale is that every core crates merged into `src/rust/` will
be versioned under the same revision as the core.
This binary crate, called vlcrs-sys-generator, uses the bindgen[1] crate
to automatically generate raw (extern "C"...) bindings, which are then
used by safe abstractions.
The goal is for this program to be used to generate raw bindings that
are which will be used by safe abstractions, each safely wrapping a part
of the VLC core API, generally a header will be a crate. This is done so
that the so that the dependency chain of the Rust modules closely
follows that of the C modules, in particular a demux module should not
need to be rebuild if it doesn't depend on vout.
Since writing and maintaining raw bindings is tedious and error-prone,
the raw bindings (extern "C"...) are generated using a Clang front-end,
bindgen, written in Rust. Updating the bindings should be as simple as
running `cargo run -p vlcrs-sys-generator'.
[1]: https://rust-lang.github.io/rust-bindgen/
Tristan Matthews
Alexandre Janniaux
Rémi Denis-Courmont
Vikram Kangotra
Loïc Branstett