Sitelet https://web.archive.org/web/20210623195954/https://github.com/github/opentelemetry-ruby
Skip to content

/ opentelemetry-ruby

forked from open-telemetry/opentelemetry-ruby

OpenTelemetry Ruby API & SDK, and related gems

opentelemetry.io/
Apache-2.0 License
0 stars 86 forks
Star
Notifications
main
Switch branches/tags
10 branches 295 tags
Code
Clone

Use Git or checkout with SVN using the web URL.

This branch is 3 commits behind open-telemetry:main.
Contribute

  • This branch is not ahead of the upstream open-telemetry:main.

    No new commits yet. Enjoy your day!

  • Open pull request

Latest commit

@ahayworth @robertlaurin
ahayworth and robertlaurin feat: Add ActiveJob instrumentation (open-telemetry#726)
6c5d877 Jun 16, 2021
feat: Add ActiveJob instrumentation (open-telemetry#726) 
* feat: Add ActiveJob instrumentation

This is a slightly modified version of the ActiveJob instrumentation
that we have been running for a few weeks now, on two different internal
applications. It is somewhat basic, but it works well enough.

There are a few things of note:
- We track a few custom attributes for ActiveJob - I'm not sure if the
  naming is good, however.
- We do not attempt to pass any kind of context propagation through the
  job system. I have successfully done that via job-argument-mangling,
  but didn't do so here. We've found that doing so leads to unwieldy
  traces for web requests that enqueue background jobs.
- I've tried to follow the overall messaging semantic conventions, since
  'job' semantic conventions have not materialized yet. I'll update this
  PR if they are finalized before this is merged; otherwise we can make
  those updates later.
- The test suite is a tad slow - to test a few features, I needed to
  explicitly use a real job system - in this case, the `async` adapter.
  It's all still in-process, but uses threads as a queueing system. I
  found the easiest thing to do was to just call `sleep` in a few places.

Probably the most important things to think about when reviewing are:
- Are the attributes added correct (or - are they at least close to
  correct until we have proper job semantic conventions)?
- Following a job produce -> job enqueue requires searching your tracing
  system on the value of `messaging.message_id`. Is that ergonomic or
  should we do something different?

I'd appreciate anyone who's willing to test this out in a production
system - I think. We're going to test this version internally as well,
since it differs in a few small ways from what we actually run today.

* Appease the cop

* Silence the cop

* Appease the cop

* Add arbitrary metadata to ActiveJob and propagate context with it

* Move patching to ActiveJob::Base

* typo

* Fix patching location and re-hashify deserialized metadata

* Move patching/requiring to separate methods

* Allow configurable linking - parent/child, span links, or none

* Fix option validation and simplify some logic

* Simplify options, add tests, fix other tests

* Appease the cop

* Address must_be_nil/assert_nil feedback

* Ensure inline adapter is restored when tests change it

* Avoid non-deterministic sleep by shutting down the async adapter instead

* Add note about :inline behavior

* Fix typo in comment

* Add option to set span names according to class names, or queue names

* Bump versions after 0.18 release

* Ah right we made an RC, did we not

* Change option handling to make testing easier

The tests were failing depending on the run order; and it's basically
all my fault. Rather than re-install the instrumentation between tests
(which has its own downsides!) I was just reaching in and fiddling
around with the internal options. However, depending on run order the
instrumentation options could actually become unset.

This cleans up the test suite and tests passed 20 times in a row
(including with previously-failed randomization seeds) so I think this
is in okay shape.

* Silence the cop

* s/enable_(job_class_span_names)/\1/ to match resque

* s/context_propagation/propagation_style/ to match resque

* Use File::NULL instead of /dev/null for windows compat

* Remove accidentally committed .ruby-version

* Update instrumentation/active_job/test/test_helper.rb

Co-authored-by: Robert <robertlaurin@users.noreply.github.com>

* Update instrumentation/active_job/test/test_helper.rb

Co-authored-by: Robert <robertlaurin@users.noreply.github.com>

* Remove config default checking in instrumentation by more-cleverly resetting tests

* Update instrumentation/active_job/lib/opentelemetry/instrumentation/active_job/instrumentation.rb

Co-authored-by: Robert <robertlaurin@users.noreply.github.com>

* Add pry to dev depenedencies

* Standardize on span_naming option

* Add failing tests for baggage propagation

* Propagate baggage at all times

* fix: update to match new baggage api changes

* Call force_flush on OpenTelemetry.tracer_provider

* Add an option for force-flushing the tracer (default: no flushing)

Co-authored-by: Robert <robertlaurin@users.noreply.github.com>
6c5d877

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
.github/workflows
 
 
.instrumentation_generator
 
 
.toys
 
 
api
 
 
bin
 
 
common
 
 
examples/http
 
 
exporter
 
 
instrumentation
 
 
propagator
 
 
rakelib
 
 
resource_detectors
 
 
sdk
 
 
website_docs
 
 
.gitignore
 
 
CHANGELOG.md
 
 
CODEOWNERS
 
 
CODE_OF_CONDUCT.md
 
 
CONTRIBUTING.md
 
 
Dockerfile
 
 
Gemfile
 
 
LICENSE
 
 
README.md
 
 
Rakefile
 
 
docker-compose.yml
 
 
OpenTelemetry Ruby Contributing Installation Quick Start Instrumentation Libraries Who's using OpenTelemetry Ruby? Useful links License

README.md

OpenTelemetry Ruby

Slack channel CI Apache License

The Ruby OpenTelemetry client.

Contributing

We'd love your help! Use tags good first issue and help wanted to get started with the project.

Please review the contribution instructions for important information on setting up your environment, running the tests, and opening pull requests.

The Ruby special interest group (SIG) meets regularly. See the OpenTelemetry community page repo for information on this and other language SIGs.

Approvers (@open-telemetry/ruby-approvers):

Find more about the approver role in community repository.

Maintainers (@open-telemetry/ruby-maintainers):

Find more about the maintainer role in community repository.

Installation

This repository includes multiple installable packages. The opentelemetry-api package includes abstract classes and no-op implementations that comprise the OpenTelemetry API following the specification. The opentelemetry-sdk package is the reference implementation of the API.

Libraries that produce telemetry data should only depend on opentelemetry-api, and defer the choice of the SDK to the application developer. Applications may depend on opentelemetry-sdk or another package that implements the API.

Please note that this library is currently in beta for tracing.

The API and SDK packages are available on RubyGems.org, and can be installed via gem:

gem install opentelemetry-api
gem install opentelemetry-sdk

or via Bundler by adding the following to your Gemfile:

gem 'opentelemetry-api'
gem 'opentelemetry-sdk'

followed by:

bundle install

To install development versions of these packages, follow the Docker Setup instructions.

Quick Start

require 'opentelemetry/sdk'

# Configure the sdk with default export and context propagation formats
# see SDK#configure for customizing the setup
OpenTelemetry::SDK.configure

# To start a trace you need to get a Tracer from the TracerProvider
tracer = OpenTelemetry.tracer_provider.tracer('my_app_or_gem', '0.1.0')

# create a span
tracer.in_span('foo') do |span|
  # set an attribute
  span.set_attribute('platform', 'osx')
  # add an event
  span.add_event('event in bar')
  # create bar as child of foo
  tracer.in_span('bar') do |child_span|
    # inspect the span
    pp child_span
  end
end

See the API Documentation for more detail, and the opentelemetry examples for a complete example including context propagation.

Instrumentation Libraries

This repository contains instrumentation libraries for many popular Ruby gems, including Rails, Rack, Sinatra, and others, so you can start using OpenTelemetry with minimal changes to your application. See the instrumentation README for more.

Who's using OpenTelemetry Ruby?

OpenTelemetry Ruby is in use by a number of companies, including:

If you would like to add your name to this list, please feel free to submit a pull request.

Useful links

License

Apache 2.0 - See LICENSE for more information.

About

OpenTelemetry Ruby API & SDK, and related gems

opentelemetry.io/

Resources

Readme

License

Apache-2.0 License

Releases

295 tags

Packages

No packages published

Languages