pglombardo

Newly created applications have pre-populated git repositories so you can't just at another remote to your existing repository and push to openshift - this is an unnecessary step. This occurs even though I didn't request an pre-existing application.

The pre-existing code had a pre-populated config.ru.

Ruby 2.0 not available

Having ruby '2.0.0' doesn't nicely tell you that you're not running Ruby 2.0 (I had the Ruby 1.9 cartridge installed), it instead barfs out an error like this:

pglombardo@themightyshogun:~/Projects/pwpush-heroku $ git push openshift master

Counting objects: 1253, done.

pglombardo

deployer  9646  2566  0 16:08 pts/1    00:00:00 /usr/bin/g++ -DENABLE_DEBUGGER_SUPPORT -DV8_TARGET_ARCH_IA32 -I../src -I../include -Wall -Werror -W -Wn
deployer  9647  9646 99 16:08 pts/1    00:00:09 /usr/lib/gcc/i686-linux-gnu/4.6/cc1plus -quiet -I ../src -I ../include -imultilib . -imultiarch i386-li
areu      9662  5379  0 16:08 pts/2    00:00:00 ps -ef

pglombardo

Report 1 (232 bytes)
		X-Trace-Header : 2 	 X-Trace Report ver 1.1
		X-Trace : 2 	 1B70B57EC70701B1B379F0B7A0F9999AF5EAE114D11C4705BACF532624
		Layer : 2 	 RubyGC
		Label : 2 	 entry
		ProcessName : 2 	 12000
		TID : 18 	 12027
		Timestamp_u : 18 	 1399928193538032
		Hostname : 2 	 hanzo
Report 2 (824 bytes)

pglombardo

require 'dashing'
require 'oboe'

Oboe::Config[:tracing_mode] = 'always'
Oboe::Config[:sample_rate] = 1e6
Oboe::Config[:verbose] = true

configure do
  set :auth_token, 'YOUR_AUTH_TOKEN'

pglombardo

IRC2HipChat is a short Ruby script that uses Cinch to monitor IRC and re-post messages to a dedicated HipChat room using the HipChat API gem.

  on :channel do |m|
    msg = "<em>#{m.user.nick}</em>: #{m.message}"
    $hipchat.send('irc2hipchat', msg, { :notify => true, :message_format => 'html' })
  end

pglombardo

@session = Moped::Session.new([ "127.0.0.1:27017" ])
@session.use :moped_test
@users = @session[:users]

Oboe::API.start_trace('just_mongo_find', nil, { :Force => true }) do
  @users.find
end

Oboe::API.start_trace('mongo_find_and_count', nil, { :Force => true }) do
  @users.find.count

pglombardo

HOW-TO: ASYNCHRONOUS AND PARALLEL WORKFLOWS

Most web application requests follow a simple path through the application, regardless of whether it is blocking or evented, where the critical path of the request is the only work being done. However, some web applications make use of threads, eventlets, or queues to process work in parallel or out of the critical path.

In order to analyze traces with asynchronous and parallel workflows correctly, small annotations must be added to the trace’s events. They boil down to adding the key Async = True on “asynchronous” layers. Here’s how to handle two common scenarios:

pglombardo

EventMachine::HttpConnection.class_eval do
  def setup_request_with_oboe(*args, &block)
    c = nil

    ::Oboe::API.log_entry('em-http-request', { uri: @uri, start: 'start' })

    c = setup_request_without_oboe(*args, &block)
    c.req.headers["X-Trace"] = Oboe::Context.toString()
    ::Oboe::API.log(nil, 'info', { uri: @uri })

pglombardo

      def report_backtrace
        kvs = { :Backtrace => Oboe::API.backtrace }

        if Oboe.tracing?
          Oboe::API.log(nil, 'info', kvs)
        else
          Oboe::API.start_trace('manual', { "Force" => true }) do
            Oboe::API.log(nil, 'info', kvs)
          end
        end

pglombardo

#!/usr/bin/env ruby

Bundler.require(:default)

Oboe::Config[:tracing_mode] = :always

while true do
  Oboe.sample?(:layer => 'rack')
  puts "PID - SampleRate/Source: #{Process.pid} - #{Oboe.sample_rate}/#{Oboe.sample_source}"
  sleep 1