TraceView and Ruby: Now Open Source!
by James Meickle on November 13, 2013
Open source is a big part of who we are at AppNeta. Take a glance at our public GitHub page and you’ll see some of our libraries (like TBone) and side projects (like Burndown). Until recently, though, we hadn’t released any of TraceView’s core components. We’re very happy to say that, thanks to Peter Lombardo’s hard work, we’ve been able to open source our Ruby instrumentation gem (
oboe-ruby). Let’s take a lightning tour of the repo!
Our support team is great, and if you ever have any questions, we encourage you to get in touch with them. But until now, there wasn’t an easy way to let our developers know what new features they should be working on. We’ll be using GitHub issues for our gem’s ongoing development, and that means enhancement requests can be posted directly by our users. If you want us to add support for a new gem, or to change how our existing support works, you’ll be working directly with our Ruby engineers to make it happen.
Of course, like any open source project, the best way to make sure that a feature gets added is to add it yourself. We’ve always had information about how to use our Ruby tracing API, but the new Ruby repo has many examples in one place. If you’re interested in adding support for Sidekiq, for instance, you could look at our Resque support to see how we built that out. Supporting “both sides” of the queue required instrumenting the
Most of the traces we encounter are associated with web requests, but we’re always running across new use cases. Ruby isn’t synonymous with Rails, and we’re interested expanding support to include new web frameworks or even command line tools. In fact, Chef and Puppet are both written in Ruby, and you (yes, you!) could use our Ruby API to adding tracing support for them. If your business is built around rapidly provisioning nodes for your customers, reporting performance data about your recipes could be a huge monitoring win.
We’re looking forward to collaborate on improvements to our existing instrumentation, too. By looking through our commit history, you can see how we’ve restructured our code over time to avoid unnecessary system calls or memory allocation. For example, we recently changed the options for backtrace collection during profiles. This is only a slight performance improvement for most use cases, but it makes a noticeable difference if you start profiling a call made multiple times per trace. Reducing the overhead of our instrumentation is an ongoing effort, though, so if you spot somewhere we could be doing better make sure to let us know about it!
While we’re excited to increase gem coverage and reduce overhead, we don’t want that to come at the cost of stability. Our Ruby test suite makes sure that any mistakes don’t hit production. It catches errors and exceptions, of course, but it also checks whether data is being output correctly. If you’re modifying our instrumentation code, you can run the test suite yourself to make sure everything works as expected. If you’re writing support for a new gem, adding new tests is a great way to prove that the work you’ve done plays nicely with everything else the gem is doing.
Eager to see what you can do with our code? Get forking! If you want to give it a spin first, the
oboe-heroku) gems are available on our profile on RubyGems. You can also stop by our GitHub releases page for a quick glance at the versions we’ve put out..
This is an exciting step for us, and we’re excited to see what you build, but Ruby is just the beginning. We’ll be open sourcing instrumentation code for more languages in the future. Make sure to follow us on Twitter to catch those announcements. Until then, if you want early access, come learn more about what we do at AppNeta, or sign up for your free TraceView account today.