And merged (targeting Rails 6.0.0.beta4) 😊 On Fri, Oct 26, 2018 at 7:56 PM Jeremy Daer <jeremyd...@gmail.com> wrote:
> Nice! 👍 > > On Fri, Oct 26, 2018 at 2:51 AM 'Daniel Schierbeck' via Ruby on Rails: > Core <rubyonrails-core@googlegroups.com> wrote: > >> First PR is up: https://github.com/rails/rails/pull/34305 >> >> On Tue, Oct 23, 2018 at 4:33 AM Jeremy Daer <jeremyd...@gmail.com> wrote: >> >>> On Mon, Oct 22, 2018 at 9:56 AM 'Daniel Schierbeck' via Ruby on Rails: >>> Core <rubyonrails-core@googlegroups.com> wrote: >>> >>>> On Fri, Oct 19, 2018 at 10:15 PM Daniel Azuma <daz...@gmail.com> wrote: >>>> >>>>> I'd love to help get OpenCensus's instrumentation fleshed out for >>>>> people's use cases. The current gem does have basic integration with AS::N >>>>> to collect trace information for events that are instrumented, but I'm >>>>> trying very very hard not to introduce monkey patches. If you're using the >>>>> opencensus gem and have particular instrumentation needs, I'll be happy to >>>>> help with PRs and get them committed upstream. Please don't hesitate to >>>>> reach out to me. >>>>> >>>> >>>> One thing I'm unsure of is naming conventions – with Datadog, we'll >>>> have a "span name" that's close to e.g. the AS::N event names, such as >>>> `rack.request`. In addition to that, there's the notion of a "resource", >>>> typically the name of an endpoint, e.g. `ArticlesController#show`. That >>>> part seems to be missing from OpenCensus, and the span names are overloaded >>>> with both span type info and "endpoint" names. Is there a standardized way >>>> to capture both? This is important because it's nice to have a small set of >>>> span types, but the resources can number in the thousands and you'll >>>> typically filter those. >>>> >>> >>> Not sure! Would check out the Datadog Go exporter to start, since it's >>> mapping from one span to another. Looks like it's just using the span name >>> as the resource name rather than pulling it from an annotated attribute. >>> >>> I'd naively expect to see spans annotated with the controller action >>> (picked up from the active trace context) and have that exported as Datadog >>> resource. >>> >>> I don't really get this part of OC – since there's a standard wire >>>> format, would you not want an external process doing the exporting? >>>> >>> >>> Direct export can be appealing for easy-setup or quick-deploy scenarios >>> like dev/test, one-click Heroku apps, or short-lived services like one-off >>> jobs run outside the main cluster. >>> >>> -- >>> >> You received this message because you are subscribed to a topic in the >>> Google Groups "Ruby on Rails: Core" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/rubyonrails-core/qJlL_uVxsnU/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> rubyonrails-core+unsubscr...@googlegroups.com. >>> To post to this group, send email to rubyonrails-core@googlegroups.com. >>> Visit this group at https://groups.google.com/group/rubyonrails-core. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to rubyonrails-core+unsubscr...@googlegroups.com. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> Visit this group at https://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
