Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LoggingTracer sample #92

Conversation

discostu105
Copy link
Member

@discostu105 discostu105 commented Jun 4, 2019

This is supposed to be a super-simple API implementation that helps to understand OpenTelemetry API layer.

It basically just logs every single API call, with thread-id and a time-offset since start.

#89

@lmolkova
Copy link

lmolkova commented Jun 4, 2019

@discostu105 can you please help me understand which problem does it solve? Is it available in other languages? Why does it have to live in this repo?

public IScope StartScopedSpan()
{
Logger.Log($"SpanBuilder.StartScopedSpan");
return new CurrentSpanUtils.LoggingScope(new LoggingSpan(spanName, spanKind));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need to create a new span every time. One instance should suffice

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok. creating the span in .ctor now and re-use that instance.

interesting question though: If I use one SpanBuilder, should I be able to create multiple spans from that (multiple calls to StartScopedSpans)?


This is supposed to be a super-simple API implementation that helps to understand OpenTelemetry API layer.

It basically just logs every single API call, with thread-id and a time-offset since start.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps getters should only log.

@SergeyKanzhelev
Copy link
Member

@discostu105 can you please help me understand which problem does it solve? Is it available in other languages? Why does it have to live in this repo?

One of the principles of OpenTelemetry is to allow to create an alternative implementations. I think it's a good showcase how this can be done.

At this stage it creates some liability as API is changing rapidly. But in general, it's OK to have.

@discostu105 my only concern is amount of code you bring with the ASP.NET example. The worst thing is to get a security notification about the repo when some issue found in jquery or bootstrap. So if it possible - can you please minimize the amount of code you submit to simplify maintenance

@lmolkova
Copy link

lmolkova commented Jun 5, 2019

Thanks for explanation @SergeyKanzhelev.

Assuming it lives in the different repo - what changes? Since it's an example there is nothing enforcing it to work - just to compile. If we want to keep it going forward in this repo - can we enforce some testing to make sure it still works after we change things?

@discostu105
Copy link
Member Author

@discostu105 can you please help me understand which problem does it solve? Is it available in other languages? Why does it have to live in this repo?

For me it's was an exercise to:

  • learn which API calls would be made from an instrumentation (e.g. ASP.NET Core)
  • learn on which threads these API calls are made
  • learn how to implement "only the API layer" without using the SDK.

I thought that could be useful for others as an example. Maybe to run it to see API calls on the console themself.

The "liability" concerning the API changes is a valid concern. But you have the same with tests. The implementation is also very small and simple, so should be easy to adapt.

If you think it's not worth putting it into the repo, I am also fine with that. I could put it into my own sample repo.

@discostu105
Copy link
Member Author

  • got rid of all NotImplementedExceptions
  • decided to not log for property getters/setters for now, as it would have blown up the code unncessarily and is not that interesting IMHO.
  • made logs more consistent

@discostu105 discostu105 mentioned this pull request Jul 2, 2019
Copy link

@lmolkova lmolkova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some minor comments, basically new projects needs stylecop configured

@discostu105
Copy link
Member Author

@lmolkova thanks. adressed your comments.

@lmolkova
Copy link

lmolkova commented Jul 4, 2019

@discostu105 sorry async main suggestion broke the build.

Program.cs(11,29): error CS8107: Feature 'async main' is not available in C# 7.0. Please use language version 7.1 or greater. [D:\a\1\s\samples\LoggingTracer\LoggingTracer.Demo.ConsoleApp\LoggingTracer.Demo.ConsoleApp.csproj]

Could you please update Directory.Build.props in root as mentioned here? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version#configure-multiple-projects , add <LangVersion>7.3</LangVersion>

@lmolkova
Copy link

lmolkova commented Jul 9, 2019

@SergeyKanzhelev @austinlparker please merge!

@SergeyKanzhelev
Copy link
Member

@discostu105 can you please fix the build? WIth the recent changes in master you need some stylecop fixes

@discostu105
Copy link
Member Author

Branch is up-to-date and build is fixed.

@austinlparker austinlparker merged commit d053e75 into open-telemetry:master Jul 23, 2019
@austinlparker
Copy link
Member

Thanks!

Yun-Ting pushed a commit to Yun-Ting/opentelemetry-dotnet that referenced this pull request Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants