Tracing / logging / auditing as capability

[mknet]

Hello everybody,

I try to implement the kind of auditing / tracing as a capability. The idea behind it is that the shell gets the info that "something happened" and the shell decides what to do with this info. On the rust side I try to use a crate like tracing so I can just reuse the macros and the existing implementation. I tried to implement a custom subscriber forwarding the tracing events to the capability's operation method (I call the method trace). Now I got this dilemma: I need the instance of the core so I can invoke the capability operation within the method update. In order to invoke update I invoke process_event with an internal event Trace. The invocation of process_event happens in the custom tracing subscriber. Now, when I process an other event I end in the following stack:

1. Root (business) event passed to process_event
2. Handle event in update
3. Invoke tracing event
4. Handle tracing event by invoking process_event

And this leads to the error rwlock write lock would result in deadlock within implementation of process_event. If I got it right the reason is, that self.model.write() is invoked twice without releasing the lock in the stack.

Now, I want to ask you guys what you think. How can we implement a kind of auditing / tracing / logging capability reusing implementations which already exist. I am open to every idea or hint.

Thanks for your interest and support.

[StuartHarris]

Hey @mknet apologies for slow response, but happy to help. I like the idea of a tracing subscriber as a capability. I'm a little confused as to why you're calling process_event from the shell-side of the capability. Maybe you have some code you can share? I'd be up for adding tracing to one of the examples (probably the counter), where the shell side records the subscribed events and spans to local storage or something. Would that be useful?

[mknet]

@StuartHarris Thanks for reaching out to me.

I'm a little confused as to why you're calling process_event from the shell-side of the capability.

The idea behind it, is that the tracing subscriber catches the tracing events and provides them via capability. I see no other option for forwarding the event to a capability than going through process_event.

Maybe you have some code you can share?

This does makes a lot of sense. Unfortunately, I cannot share my original code. I will provide a sample project and will come back to you asap.

I'd be up for adding tracing to one of the examples (probably the counter), where the shell side records the subscribed events and spans to local storage or something. Would that be useful?

Yes, I guess this would help. At least it will show your thoughts about this topic. So, please go ahead. Thanks!

[kaidelorenzo]

Less advanced than tracing and auditing I'm looking into simple print line debugging. I'm curious what others have done in the past. It feels weird to write to std out with println! for example because that's a side effect right? So that should happen on the shell side. though maybe just for debugging it doesn't really matter.

[charypar]

@kaidelorenzo I personally do just use println / eprintln for the cases I'm not intending to commit.

At a larger scale for more production-like logging, you're right that philosophically, logging should be a capability, but pragmatically I personally think it's okay to compromise and just rely on shims and protability of the basic concept of stdout / stderr for that purpose. Others might disagree.

[kaidelorenzo]

Yeah that makes sense. That's what I landed on myself.