thoren-d / tracing-chrome Goto Github PK

As per the security report by the RUSTSEC team.

This dependency (json) is unmaintained and probably should be removed.

Maybe, it could be replaced by serde_json ?

Hi there! Thanks for maintainging this. I'm having some difficulty using tracing-chrome in my application.

use tracing_subscriber::prelude::__tracing_subscriber_SubscriberExt;
use tracing_subscriber::util::SubscriberInitExt;

let (chrome_layer, _guard) = tracing_chrome::ChromeLayerBuilder::new().build();
tracing_subscriber::registry().with(chrome_layer).init();
tracing::info!("I'm not visible in chrome's tracing tool");

I'm using this kind of minimal setup, but when I run my application, the generated .json file looks like this (note the lack of a closing bracket):

[{"ph":"M","pid":1,"name":"thread_name","tid":0,"args":{"name":"main"}},
{"ph":"i","pid":1,"ts":2043.166,"name":"event server/src/appstate.rs:45","cat":"atomic_server::appstate","tid":0,"s":"p","args":{"[file]":"server/src/appstate.rs","[line]":45}},

This is what the tracing_subscriber::fmt::init() logger outputs, which gives an impression of many things that are missing:

2021-12-27T15:41:09.417479Z  INFO atomic_server::appstate: Atomic-server 0.30.0. Use --help for more options. Visit https://docs.atomicdata.dev and https://github.com/joepio/atomic-data-rust.
2021-12-27T15:41:09.423608Z  INFO atomic_server::appstate: Opening database at "/Users/joep/.config/atomic/db"
2021-12-27T15:41:09.896965Z  INFO atomic_server::appstate: Setting default agent
2021-12-27T15:41:09.915284Z  INFO atomic_server::appstate: Default Agent is set: https://atomicdata.dev/agents/QmfpRIBn2JYEatT0MjSkMNoBJzstz19orwnT5oT2rcQ=
2021-12-27T15:41:09.916352Z  INFO atomic_server::appstate: Starting search service
# this continues for a while

If I output the trace log, there's far more items in there.

It could be that there are two issues here:

• In the second line, there is no string I'm not visible in chrome's tracing tool. The contents of the spans seem missing.
• All the other tracing statements that happen later aren't included.
• The JSON is invalid, as if it was still waiting to write the actual JSON.

Maybe anybody reading this has an idea on how to solve this? Thanks!

Edit: I think the answer might be calling the _guard flush function before exiting. However, this seems to be not that trivial in my code. Is there a way to auto-flush every X seconds or so?

When I turn this Subscriber on the trace file generated can be huge in relatively little time (1GB per minute almost). Trying to load this into chrome:://tracing as-is just causes it to hang or crash. I would like to be able to tail the file to get the last x events but because all of the events are written on one line it is very hard to process.

The solution I have at the moment is to generate the trace file, split it with jstream and then tail it for the events I want.

Ideally if there was an option to add newlines after every event I could skip this step and it would make the file much easier to work with in standard linux tools. Obviously this would increase the file size but 1 byte per event.

I have a tokio-based CLI program that creates a root span upon start and then processes multiple files concurrently using the code like:

#[tracing::intrument]
async fn do_stuff(...) { ... }

let futures: Vec<_> = files
    .into_iter()
    .map(|f| do_stuff(f))
    .collect();

let results = futures::future::join_all(futures).await;

I configure the layer with TraceStyle::Async, but even then the resulting graph in Perfetto looks as if all the do_stuff spans are mushed together into one bar instead of being treated as independent concurrent tasks.

Looking at the trace file, all do_stuff events seem to have "id": 1, so Perfetto likely unable to tell them apart.

Is this expected / current limitation / or perhaps I'm doing something wrong?

Hi!

I am using this and jaeger in tandem to get some oversight into the run. I much prefer how lightweight this is, but noticed the chrome-tracing output does not include any fields or attributes in the same way the opentelemetry layer does.

https://docs.rs/tracing/latest/tracing/index.html#recording-fields

Using tracing::instrument, function parameters will automatically be included in the opentelemetry tags. I am open to writing a PR for this.

Cheers

Alex