Avanade/Liquid-Application-Framework

Provide a way to add an abstraction for adding custom logging and instrumentalization

dervanil-junior opened this issue · 5 comments

Current scenario:

Today logs generated by Liquid are by default routed to Console or it could be routed to other destinations using configuration.

Problem:

In some cases, like Elastic APM is necessary to add instrumentation manually, starting and ending transactions and spans (Elastic APM concepts), but there is not a standard way to do this in Liquid.

Proposed solution:

  1. Add a component with abstractions that should be used optionally by others to add custom logging logic, also provide a default implementation that keeps the current behavior routing logs to console.

  2. Propose a standardized way to use the interface ‘IPipelineBehavior<,>’ and ‘LiquidInterceptorBase’ to add the custom logic.

Liquid.ElasticApm.zip
Proposed code for the component.

This could be generalized to provide other APM implementations. Datadog works in a similar way, and so does Application Insights.

It should also be investigated if Elastic implements de concept of end to end tracing and how it does, this way we could trace a transaction from start to finish, even if it involves asynchronous components such as Service Bus or RabbitMq.

Regarding the code, I believe the logging level of before start and after end should be changed to Trace, or be configurable, to avoid generating a lot of useless logs (if it´s already in the APM, the console log should not have much value).

@dervanil-junior and @marcoshidalgonunes, looking at the code, I understand that this component can be an extension of Liquid's telemetry classes, which specialize in the needs of Elastic APM.

Talking to the Liquid team, we understand that we can publish it as a Liquid package, but you guys will need to make some adjustments.

I created a release branch where you can work on the following items:

  1. The project must be included in the Liquid.Core solution, with the namespace "Liquid.Core.Telemetry.ElasticApm".
  2. The code must be adapted to the Liquid naming standard, considering the namespace defined above.
  3. A unit test project must be created, and it must have at least 80% coverage of the code.

Important: you must work in a fork, and open a pull request to the official repository when it is completed, so that we can review and approve the final solution.

I opened the pull request to the release branch from official repository.