by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Wesley Pettit
    @PettitWesley
    I read through it. I'm very new to OT, but have a little bit of experience with logs. I really liked the proposed data model and overall thoroughness of the doc. I've not yet been able to think of anything obvious which it seems to be missing.
    Tigran Najaryan
    @tigrannajaryan
    @/all Log SIG meeting tomorrow conflicted with Community meeting. I moved Log SIG meeting to be one hour earlier to avoid the conflict. Calendar is updated.
    Olivier Mengué
    @dolmen
    Hi. New here. I'm just discovering the project as a future user.
    I just wanted to tell about a typo in the meeting notes: the meeting dates are in year 2010 !
    Ron Cohen
    @roncohen
    Hi folks! Is there a recording of the meeting on Apr 8, 2010?
    probably a question for @tigrannajaryan
    Tigran Najaryan
    @tigrannajaryan
    @roncohen AFAIK the recordings are not published automatically (we don't have a way to do it). I believe it is a manual process. @mtwo do you know this?
    Ron Cohen
    @roncohen
    Ah, I know that struggle :) A colleague wrote this tool to automatically upload recordings from recurring zoom meetings to Google Drive folders: https://github.com/graphaelli/zat/ then we just link to the folder with all the recordings for discoverability
    Morgan McLean
    @mtwo
    yeah, it's manual ... apparently Kubernetes has a new way to automate it but I haven't had the time to investigate it
    @roncohen neat, I'll check that out
    Tigran Najaryan
    @tigrannajaryan
    @/all Unfortunately both Morgan and I have a conflict. I am moving today's SIG meeting by 30 minutes so that we can make it. Sorry for last minute notice, we realized too late we have a conflict with Community meeting today and had to reschuffle the schedule.
    Ron Cohen
    @roncohen
    If anyone wants to join early and chit chat I'm there :)
    Eduardo Silva
    @edsiper
    ack
    Madis Liias
    @liias
    Hi there. Quick question. If I am interested in tracing, logging (java applications) in production. Is it too early to consider open-telemetry and I should look into OpenCensus instead?
    Tigran Najaryan
    @tigrannajaryan
    @liias OpenTelemetry tracing is fairly mature and is currently in Beta. I know people who use it at least parts of OpenTelemetry in production (e.g. the Collector). Support for logs does not exist yet. We started discussions to support logs a few weeks ago and I do not expect logs to be production-ready for the next few months.
    rparth
    @rparth
    Folks, glad to join this forum. We are a small group of folks working on a full observability stack at https://logiq.ai. Would be happy to contribute to the logging efforts. Look forward to engaging with the community.
    Tigran Najaryan
    @tigrannajaryan
    @rparth welcome. Feel free to join SIG meetings (meetings are in OpenTelemetry Calendar) and review proposals (recent open proposal is about Data Model: https://docs.google.com/document/d/1ix9_4TQO3o-qyeyNhcOmqAc1MTyr-wnXxxsdWgCMn9c/edit?ts=5e990fe2#)
    Ron Cohen
    @roncohen
    @tigrannajaryan the doc is no longer publicly accessible. Any idea?
    jeffalder
    @jeffalder
    Hi folks! I'm from New Relic. We recently released a logging product. I wrote the Java Agent integrations with logback 1.2, log4j 1, log4j 2, and java.util.logging, and served as a tech lead across the other languages. The Java Agent writes its own logs using log4j 2. I'm a little late to the design process. Let me know how I can contribute.
    Tigran Najaryan
    @tigrannajaryan
    @roncohen I accidentally changed the permission. Should be accessible now.
    @jeffalder you may want to sync with @zenmoto who works on Logging Library spec.
    jeffalder
    @jeffalder
    @zenmoto lmk how I can help!
    jeffalder
    @jeffalder
    @tigrannajaryan Is there a work plan? Once the current OTEP 97 is completed, what needs to get done next? Is there anything that can be done in parallel besides the Library spec?
    Tigran Najaryan
    @tigrannajaryan
    @jeffalder yes, there is a rough plan on what we want to do: https://docs.google.com/document/d/1cX5fWXyWqVVzYHSFUymYUfWxUK5hT97gc23w595LmdM/edit#heading=h.ym810wjhhbxw
    I am personally focused on the data model, the protocol and the Collector. @zenmoto works on library specs. There are several other topics that I think nobody owns yet.
    Wesley Pettit
    @PettitWesley
    Based on last weeks discussion in the SIG, I put up PRs for two suggested edits to the log vision otep.
    Quantifiable resource utilization goals for the unified collector: open-telemetry/oteps#101
    A concrete list of log sources to support: open-telemetry/oteps#102
    Tristan Sloughter
    @tsloughter
    @johnroach here
    John Roach
    @johnroach
    Hi! I am getting a little confused about what open-telemetry can do. I am especially interested in the logging ability where I read OpenTelemetry captures metrics, distributed traces, resource metadata, and logs (logging support is incubating now) from https://opentelemetry.io/about/ . Where can I find documentation on the incubation work being done? Is there an example of a Go implementation of this? Does OpenTelemetry act like a wrapper around login the case of Go or does it provide it's own solution like logrus or Uber's zap?
    24 replies
    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).