Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Juraj Michálek
    @jmichalek132
    any recommendation?
    Daniel Khan
    @danielkhan
    Which technologies / languages?
    Juraj Michálek
    @jmichalek132
    languages python,javascript,c,c++,java,scala,..
    as for the technologies that would be a lot longer list
    Daniel Khan
    @danielkhan
    I would see - whatever you choose to use - if it supports auto instrumentation keeping the amount of monitoring code in your application as low as possible.
    OpenTelemetry is currently moving in that direction. Node.js already auto-instruments http and grpc ootb for instance.
    Tyler Benson
    @tylerbenson
    I hate to say it but Gitter mobile app is so horrible. I really wish we stuck with slack.
    I also just discovered I was kicked out of this room.
    Krzesimir Nowak
    @krnowak
    Everyone was kicked out of this room, because it was deleted.
    Bob Strecansky
    @bobstrecansky
    (inadvertently)
    Ted Young
    @tedsuo
    @tylerbenson we never actually switched to slack, but we still could if we resolve the issues that were raised last time.
    Tristan Sloughter
    @tsloughter
    isn't slack clamping down on publicly joinable slacks?
    or is there a paid cncf/linux foundation slack? since also if we did go to the trouble of moving I'd suggest doing so to a service we can keep history
    Ted Young
    @tedsuo
    There is a paid CNCF account, but we did not want to use a CNCF-wide shared account, as discoverability is bad enough given how many channels we need. K8s uses their own slack for this reason.
    The other issues are the ones you mentioned: a lack of message retention, and difficulty for new users to join.
    Tyler Benson
    @tylerbenson
    I’d argue that the tradeoff with gitter is difficulty for regular users to use every day.
    Ted Young
    @tedsuo
    I can’t remember if we determined whether a slack bot which archived everything was feasible or not.
    Sam Schlegel
    @samschlegel
    @davidbarsky :wave: I'd definitely be interested in something like an OpenTracing Rust SIG. I've been holding off on add tracing to our Rust services since nothing there exists yet, and might have some time in the coming quarters to spend on that (thanks to @akvanhar for calling this Gitter to my attention)
    David Barsky
    @davidbarsky
    @samschlegel i know someone implemented a mutex’d honeycomb subscriber a few days ago, and we just landed json support as well. it might be more than you’d expect!
    Sam Schlegel
    @samschlegel
    :eyes:
    David Barsky
    @davidbarsky
    exporter, sorry—terminology is hard to track :)
    should have a lock-free span registry Soon™
    (maybe this or next week, eliza’s fuzzing it)
    Alyson van Hardenberg
    @akvanhar
    :D
    Sam Schlegel
    @samschlegel
    Super cool!
    David Barsky
    @davidbarsky
    lemme track down the honeycomb one and point you at the JSON-based one.
    JSON: https://github.com/tokio-rs/tracing/blob/master/nightly-examples/examples/proxy_server.rs
    David Barsky
    @davidbarsky
    ...and honeycomb: https://github.com/pkinsky/dag-cache/blob/master/src/capabilities/telemetry_subscriber.rs
    Sam Schlegel
    @samschlegel
    Thanks David!
    @tedsuo Also Byron says hello!
    Tristan Sloughter
    @tsloughter
    devs on the Rust impl might want to take part in the group to make the spec language agnostic. let me know if you do or know somone who would
    David Barsky
    @davidbarsky
    how so? the protobuf definition does seems pretty language agnostic
    David Barsky
    @davidbarsky
    (but i’d be happy to be cc’d and read the discussions and point out any gotchas)
    Tristan Sloughter
    @tsloughter
    @davidbarsky the spec language, not the protobufs
    thanks
    David Barsky
    @davidbarsky
    @tsloughter could you link me so that I’m on same page?
    Tristan Sloughter
    @tsloughter
    @davidbarsky the spec is https://github.com/open-telemetry/opentelemetry-specification and an example of what we'll be working on improving the language for would be the use of Factory like with the tracer here https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/api-tracing.md#obtaining-a-tracer
    David Barsky
    @davidbarsky
    @tsloughter understood! what'd be the best way for me to provide specific feedback?
    Tristan Sloughter
    @tsloughter
    @davidbarsky I'll get back to you on that :). my current plan is to write up a starting point of sorts and then send it to you and a few others which we can then discuss and extend. the starting point will be examples of language to change and how I think they would be better described. i.e. what does having a Factory mean to the end user developer, what it allows described in a agnostic way
    David Barsky
    @davidbarsky
    @tsloughter no worries, you where to find me! and sounds great!
    Ted Young
    @tedsuo
    FYI I deleted the website sync today, since Morgan is OOO this week.
    Bradley
    @BradErz

    Hi Everyone!

    We are starting on our magical journey for custom traces.. (we are using opencensus to actually do the tracing but the gitter seems pretty dead). We have deployed the opencensus agent, opencensus collector which is writing to jaeger-collector and then into the jaeger stack. We are sending traces from 2 sources.

    • istio-proxy
    • individual applications

    I have some questions regarding trace sampling ratios, settings and in which places.. Right now we are using the default sampling probability everywhere, but it doesnt work so well. We basically end up with traces from the two diffrent sources being disjointed from eachother.. Our applications check for the root span id, if its there then they use it (its always there because istio generates it) otherwise it would create a new one.

    Should the apps + istio have a tracing probability of 100% and then let the opencensus collector control the probability and produce more accurate spans? Or? Tracing every request is probally not the best idea due to the overhead it creates.

    Bradley
    @BradErz
    This is what a trace without the istio tracing looks like: image.png
    Austin Parker
    @austinlparker
    quite a few people trace every request
    Bradley
    @BradErz
    hmmmm ok
    Austin Parker
    @austinlparker
    the real cost of not sampling, imo, isn’t in runtime overhead, it’s collection/centralization/storage
    iirc the collector allows you to do tail-based sampling which is what i’d reccomend
    Bradley
    @BradErz
    yea that was my thought, it just sempt to be against the norm of what i could find documented anywhere to actually sample every request in the application and in envoy/istio
    thats going to be a LOT of traces :joy:
    Austin Parker
    @austinlparker
    Tail sampling is pretty new
    “new"