by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    jeffalder
    @jeffalder
    @tigrannajaryan I was considering forking the New Relic Java log extensions and modifying them for OTel spans. Would that be a useful demo? I can also talk Wednesday on some of the principles and lessons learned that guided New Relic’s library design, if that would be interesting.
    Tristan Sloughter
    @tsloughter
    what does the new relic extension do? I would think the otel logging part should just be like an OnStart span processor that sets some log metadata based on the span
    jeffalder
    @jeffalder
    The NR extensions vary based on the logging framework. Generally there’s a leading part that tacks ThreadLocal data onto the message at the time of logging, and a trailing part that serializes to our JSON format. From what I could tell, not all the frameworks have MDC capabilities, and it was important to us to reach as many frameworks as made sense.
    I have to admit that I don’t know the OT Span API/SDK capabilities, so there could be a more-efficient way to do this, and I’m interested in exploring what’s there
    Tristan Sloughter
    @tsloughter
    MDC?
    metadata something? guessing meaning not all can track metadata and o you have to add it at the time of the log itself and not simply at the time of span creation?
    jeffalder
    @jeffalder
    Mapped Diagnostic Context: http://logback.qos.ch/manual/mdc.html
    And yes - I was unable to use MDC for log4j 2 or JUL.
    Sorry, my thought process is very Java-centric because that’s my current area of responsibility. We do have at least one log extension/enricher for .NET, Python, Ruby, node.js, Go, and PHP. I was not directly involved in those, so I’d have to do some research.
    Tigran Najaryan
    @tigrannajaryan
    @jeffalder please sync @zenmoto since it appears what you describe overlaps with he is doing / done. Definitely useful to hear about your learnings.
    As for "forking the New Relic Java log extensions" it is important to understand the full implications. We went through a process of companies donating their existing solutions to OpenTelemetry (particularly with Java autoinstrumentation library). I am not sure a fork fits this model (due to branding, licensing implications and vendor neutrality stance of OpenTelemetry. You may want to discuss this in more detail with OpenTelemetry TC and Admins and look into the history of Java autoinstrumentation donation as a possible model to follow if you intend to donate solutions. A fork is fine as a proof of concept though if you want to demonstrate a concept.
    I believe at this stage it is important to come up with library specs and guidelines (and doing proof-of-concepts is likely necessary for this). The implementations can then follow, based on the agreed guidelines.
    Tristan Sloughter
    @tsloughter
    yea
    I'd also hope this could just go in the SDK as a processor and not require a seprate library
    jeffalder
    @jeffalder
    I’m not at all proposing the fork as a solution - just a throwaway prototype since I’m sure there will be better ways to accomplish it, and OT’s requirements aren’t New Relic's requirements. I could also simply present on our design principles and why we implemented things the way we did and call it good.
    1 reply
    jeffalder
    @jeffalder
    Also @tsloughter we’d want to make sure any non-span attributes OT would add got captured if there is no active span. So I think the SpanProcessor would work for trace/span injection but not for other resource attributes. Right?
    Tristan Sloughter
    @tsloughter
    yea, would have to hook into the Resource setup somehow as well
    Joshua MacDonald
    @jmacd
    distributed context and resources, then? sounds good.
    Nail Islamov
    @nilebox
    I was unable to use MDC for log4j 2 or JUL.
    The implementation is different from logback's MDC, but capabilities are similar it seems
    jeffalder
    @jeffalder

    @nilebox You’re right, that is very similar. It’s been a while since I reviewed the design. One of the design principles in the New Relic extensions was zero-injection of bytecode. Because of the way the New Relic span creation works, I think there wasn’t a zero-injection way of intercepting the message and adding context in a useful way. We ended up inheriting the MessageFactory … and at that point there was no real point in using ThreadContext when we could use our own Message class. (This is me trying to recapture the decision we made at the time; there may have been other reasons.)
    https://github.com/newrelic/java-log-extensions/tree/master/log4j2

    Certainly an improvement to consider in the next round!

    Tigran Najaryan
    @tigrannajaryan
    @/all if you have not reviewed the Data Model proposal yet please do: open-telemetry/oteps#97
    If you are a spec approver please approve if you have no objections. If you are not a log expert please invite someone trusted who is an expert and can help you to review.
    I would like to make sure we are moving forward and finalize the data model and if possible settle all outstanding data model issues in tomorrow's Log SIG meeting.
    The data model is a prerequisite for a lot of work that cannot start until we agree on the data model (including protocol work and many parts of PoC of adding logs to Collector).
    Joshua MacDonald
    @jmacd
    @tigrannajaryan I'm concerned that the OTel collector is bogging itself down with this logs work. When do we expect to be rid of the internal OpenCensus data format used throughout the collector?
    IOW if withholding an approval will help us get to 1.0 sooner, I will do that.
    Tigran Najaryan
    @tigrannajaryan
    @jmacd getting rid of the internal OpenCensus data format is blocked by finalizing the protocol definitions. We are not going to start working on metrics conversion when metrics protocol is in such fluid state since every change in a protocol definition breaks Collector internal code.
    Things are better for trace part. Trace-related components in the Core are now converted to OTLP with the exception of Zipkin. Collector core maintainers do not intend to convert contrib components. We will publish guidelines for contributors to convert their components once we are certain trace protocol is final and we are not going to make further changes to it in the near future. I am deliberately delaying this to avoid asking contributors to redo their work again.
    Logs work is done by different people (me) and has no effect on this (since I am not doing conversion work - it is primarily Bogdan and others).
    Withholding log approval is not going to help with this in any way. Expediting metric work and finalizing metric protocol will help.
    Joshua MacDonald
    @jmacd
    Traces are still using the OpenCensus format internally, yes? This is going to hamper performance. I still feel that logs is a distraction and that the charter for OTel includes spans and metrics until it reaches 1.0
    Tigran Najaryan
    @tigrannajaryan
    @jmacd No. Traces are using OTLP for most of core components (except Zipkin).
    Joshua MacDonald
    @jmacd
    Thanks. I had heard otherwise as recently as this morning.
    I recommend a SIG for logging w/ its own approvers. For me, paying attention to logs will slow down metrics..
    Tigran Najaryan
    @tigrannajaryan
    Having log approvers makes sense to me.
    @bogdandrutu I believe we were already moving in the direction of having separate approvers for signals, right?
    Joshua MacDonald
    @jmacd
    It's "approved" for metrics, but not deployed.
    Bogdan Drutu
    @bogdandrutu
    I am moving to that direction, final cleanups before we enable that
    jeffalder
    @jeffalder
    @zenmoto is gitter a good communication mechanism? LMK if there’s a better option.
    David Poncelow
    @zenmoto
    @jeffalder it should be, though you may have to @ me if I don’t reply here. I’ll be better about running the client so I get notifications.
    jeffalder
    @jeffalder
    Roman Inflianskas
    @rominf
    This message was deleted
    2 replies
    Omer Katz
    @thedrow
    Hi, I would very much be interested to join this effort
    1 reply
    One of the things I'm wondering about is how we'd model logging inside the application.
    Omer Katz
    @thedrow
    Does the SDK provide a logging mechanism or should we use whatever we'd like and the collector will collect it from files/journald etc.
    4 replies
    Rahul M Chheda
    @rahulchheda
    Hi, would like to contribute to these efforts, went through the previous meeting agendas and results. Could somebody point me towards the repo, or github link for OTEP for logging?
    2 replies
    haojhcwa
    @haojhcwa
    Just like to share a small tool we used to benchmark our various log agent implementation, it is still a work in progress with many features pending, feel free to contribute or share your opnion: https://github.com/awslabs/amazon-log-agent-benchmark-tool
    Jonah Kowall
    @jkowall
    The PR for the spec seems like there are a bunch of vendor specific things. Why do Splunk need SignalFX events and Splunk events? Same with the google/amazon log fields, we could make those generic versus specific.
    Tristan Sloughter
    @tsloughter
    hm? that isn't the case. also the otep PR is not the spec, it is the process before a spec is written
    ah saw your comments on the PR. don't think you should worry about getting in a logz.io mapping/example to the OTEP. -- unless you think it shows something that would require changing the otep, but the otep isn't the spec so the spec isn't in stone after its merger
    I didn't bother sending an Erlang mapping like there is for log4j and zap because I don't think it would add anything to the otep, but there certainly will be one when the spec is complete
    Tigran Najaryan
    @tigrannajaryan
    Mark Carter
    @markcartertm_twitter
    @tigrannajaryan thank you for all the amazing work and your leadership 👍🏻🙏🍻
    Rahul M Chheda
    @rahulchheda
    Congrats @tigrannajaryan ! That's great!
    Omer Katz
    @thedrow
    :tada:
    Tigran Najaryan
    @tigrannajaryan
    Thanks everyone for reviewing and providing valuable feedback. Next: logging libraries, log protocol and log data support in Collector.