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.
