csnemes / tracer

Tracing rewriter using Fody
Apache License 2.0
93 stars 26 forks source link

How to pass configuration to the tracer at weave time #74

Closed ndrwrbgs closed 4 years ago

ndrwrbgs commented 5 years ago

Say you were making the serilog tracer (which already exists), but wanted to NOT include the parameters on a method. How could you pass that configuration information from Fody's configuration, through tracer to the Serilog tracer itself?

Are there any hooks to the Fody configuration or additional configuration mechanisms for the implementor?

Thanks!

csnemes commented 5 years ago

There are many ways to do it,. First one can modify the weaver and put this feature as a configuration switch. This way it would work for all adapters, log4net, serilog, etc. A less involved solution is to create your own adapter based on the source and modify the traceenter and traceleave implementations to skip parameters. Or if you just don't want to see the parameters in the log you might adjust the logging configuration (need to check if its possible with serilog). From performance perspective the first one is the best as it don't waste cycles on something that is not used. I'm currently updating Fody with some new features, I'll add this switch into the new version.

ndrwrbgs commented 5 years ago

Thanks for the reply!

I’m actually writing a tracer based on this library but have the requirement that SOME methods have their arguments traced and some do not. I am looking at the source here and not seeing any easy way to pipe information from the weaver config file or the TraceOn down to my implementation. Would you have any ideas on that front?

Your answers on the various approaches for how to completely remove arguments were useful, thank you for that insight!

csnemes commented 5 years ago

So, just to test if my understanding is correct, what you'd like to achieve is to pass down information from config and/or attributes to the logger adapter (TraceEnter and TraceLeave methods). Am I right?

ndrwrbgs commented 5 years ago

Indeed, either pass down or have some static way to access it - any mechanism that allows me to read a config value at that location would enable the scenario like

[TraceOn(includeArguments: true)]
public void MyMethod(string args) {}
csnemes commented 5 years ago

I think the TraceEnter and Leave methods' signature can be extended with an additional configuration argument which is injected at weaving time based on attribute or XML configuration. I'm thinking of a general argument (like a string) so that it can be used for different purposes by different implementations. Of course it would mean that we lose the type safety and extra info on the attribute. Like [TraceOn("IncludeArguments")]. I'll see if I can find a way to keep the specificity of named arguments and still provide a general extensibility. Anyway, the rewriter is now under a major update ('I'm almost finished with it), so I can probably add this feature as well.

csnemes commented 5 years ago

Try beta3. It passes an array of Tuple<string, string> to both enter and leave methods. These extra config parameters can be used to modify the behaviour of the logger. The weaver fills these parameters based on

ndrwrbgs commented 5 years ago

Sorry for latency, still alive but haven't gotten a chance to return to this yet :)

ndrwrbgs commented 4 years ago

Finally cleaning up my tech debt I left in your project (this open issue) :-) https://github.com/ndrwrbgs/Tracer.OpenTracing.Fody/commit/b511a84896374a26e9ebceaa7f29f4f04b03f974

ndrwrbgs commented 4 years ago

I wasn't able to (quickly) figure out how the config XML got passed, but in my scenario (we have secrets passed around in our code) configuring globally would be undesired anyway. There are some optimizations (like perhaps using ValueTuple, passing the values as object instead of turning them into strings) that we could make, but this issue is closed and if any of those show up in profiles later I'll send a PR