refactor(tracing): Using tracing instead of log for logging

[gabrik]

Replacing log with tracing and env_logger with tracing_subscriber.

Added init_log() function to zenoh_util as init tracing logging is a bit more complicated than env_logger::init()

Bindings Sister PRs:

• Python: feat(tracing): using zenoh-util function for log initialization zenoh-python#172
• C: feat(tracing): using tracing and zenoh-util init_log zenoh-c#308
• Java: feat(tracing): using tracing instead of log zenoh-java#58
• Kotlin: feat(tracing): using tracing instead of log zenoh-kotlin#63

Plugins/Backends Sister PRs:

• MQTT: feat(tracing): using tracing and zenoh-util log init zenoh-plugin-mqtt#67
• DDS: feat(tracing): using tracing and zenoh-util log init zenoh-plugin-dds#204
• ROS2DDS: feat(tracing): using tracing and zenoh-util init log zenoh-plugin-ros2dds#105
• FileSystem: feat(tracing): using tracing and zenoh-util init log zenoh-backend-filesystem#82
• InfluxDB: feat(tracing): use tracing and zenoh-util init log zenoh-backend-influxdb#92
• RocksDB: feat(tracing): use tracing and zenoh-util log zenoh-backend-rocksdb#70
• S3: feat(tracing): use tracing and zenoh-util log init zenoh-backend-s3#45
• ROS1: feat(tracing): use tracing and zenoh-util log init zenoh-plugin-ros1#49
• Webserver: feat(tracing): use tracing and zenoh-util init log zenoh-plugin-webserver#58

Closes #894

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[eclipse-zenoh-bot]

@gabrik If this pull request contains a bugfix or a new feature, then please consider using Closes #ISSUE-NUMBER syntax to link it to an issue.

[gabrik]

@Mallets sister PRs have been created, did I miss some repo?

[gabrik]

Leaks could depend on this: tokio-rs/tracing#2069

[gabrik]

@DenisBiryukov91 can you check if this memory leak is acceptable?

[DenisBiryukov91]

The leeks indeed seem to come from tracing (originated from zenoh_utils::init_log). But I do not think we should consider any memory leaks as acceptable, unless we provide the user a (possibly unsafe) way to avoid them. Would it be possible to implement a log_close method similarly to what was done for ZRuntimePool drop / ZRuntimePoolGuard in zenoh-runtime ?

[gabrik]

Maybe it is possible, but I do not thing it can be done in Zenoh, I think it has to be done in tracing.

The issue there is the tracing::subscriber::set_global_default(subscriber) creating a static inside tracing.

Even is we "drop" the result of the call the subscriber will still be there, unless we plan to contribute something to tracing.

[gabrik]

It has to be done in tracing if we want, the code that initialized the static is this here

[DenisBiryukov91]

will the tests pass if you do not call zenoh_utils::init_log() in the beginning of main, or initialize a logger with NoSubscriber ?

[DenisBiryukov91]

There is a public function get_current,
that allows to apply a function to a global subscriber.
With a bit of unsafe black magic it should be possible to delete it.

[gabrik]

will the tests pass if you do not call zenoh_utils::init_log() in the beginning of main, or initialize a logger with NoSubscriber ?

Yes on my machine the valgrind test passes without the call to init_log

[gabrik]

For reference:

zenohd	Size (bytes)	diff
log	17112192	-
tracing	18826744	1714552

Using tracing makes zenohd binary 1.7MB bigger, @JEnoch is this acceptable?

[gabrik]

For reference:

via z_pub_thr and z_sub_thr examples

pub/sub (thr)	msgs	diff	net
log (main)	3963062	-	localhost
tracing	3812013	-151049	localhost
log (main)	3998883	-	100gbe
tracing	3798591	-200292	100gbe

@Mallets this is worrying...

[gabrik]

with RUSTFLAGS='-C target-cpu=native' the situation is better.

+-------------------------+----------+----------+
|        pub/sub          |  msgs    |   diff   |
+-------------------------+----------+----------+
| log                     | 3956274  |        - |
| tracing                 | 4103986  |  147712  |
+-------------------------+----------+----------+

[YuanYuYuan]

P2P Results on C17

Latency

Protocol	5th Percentile	Median	95th Percentile
P2P (main)	10.0	10.0	10.0
P2P (tracing)	10.0	10.0	10.0

Throughput

Payload size	P2P (main)	P2P (tracing)
8 B	236.3 M	257.8 M
16 B	474.2 M	487.2 M
32 B	944.8 M	947.9 M
64 B	1.9 G	2.0 G
128 B	3.6 G	3.9 G
256 B	7.3 G	7.4 G
512 B	13.1 G	13.7 G
1 KB	23.7 G	23.4 G
2 KB	37.9 G	39.9 G
4 KB	59.6 G	58.0 G
8 KB	61.7 G	61.9 G
16 KB	54.7 G	54.9 G
32 KB	43.2 G	43.6 G
64 KB	38.1 G	39.8 G
128 KB	41.8 G	42.5 G
256 KB	47.0 G	46.6 G
512 KB	40.1 G	38.3 G
1 MB	46.7 G	48.5 G
2 MB	35.4 G	35.0 G
4 MB	32.1 G	50.8 G
8 MB	29.0 G	29.4 G
16 MB	56.7 G	27.9 G
32 MB	53.5 G	40.2 G
64 MB	59.5 G	57.9 G
128 MB	59.0 G	56.8 G
256 MB	49.3 G	51.5 G
256 MB	53.6 G	53.6 G
512 MB	51.5 G	51.5 G

[gabrik]

Adding a init_log function that does not "leak", and renamed the previous one in init_log_from_env

The new one is being used in the Valgrind tests.

[YuanYuYuan]

LGTM