Unfortunately RPM 2.10.5 couldn’t monitor jobs of Resque. Resque forks to process a job. RPM agent instance can’t chase the things happend in forked processes which terminates in a short time.

However I succeeded to monitor Resque jobs with RPM with a little hack. I want to share it here, though, it is just a hack. The information might be obsolete soon. So I explain my process I took to find it too. In that way, I hope that it gives you a help when this hack is no longer applicable.

Step 1. Follow the instruction of RPM

Firstly I followed RPM’s instruction (API document) and implemented a sample job like this.

class HelloWorldJob
  include NewRelic::Agent::Instrumentation::ControllerInstrumentation

  @queue = :low
  def self.perform
    HelloWorldJob.new.hello_world
  end

  def hello_world
    RAILS_DEFAULT_LOGGER.info "#{Time.now}: Hello World!"
    RAILS_DEFAULT_LOGGER.flush
    sleep(3)
  end

  add_transaction_tracer :hello_world, :name=>'hello_world'
end

But even if the job is processed on Resque, it is not shown as a transaction in management screen of RPM.

Step 2. Google it

Secondly I googled it. I felt that researching myself is a waste of time if someone has found the way already(This idea is always wrong though). But Google didn’t give me the answer this time. I thank Google for that because it gives me an oppotunity to understand how both Resque and Newrelic RPM work deeply.

Step 3. Set up environment to debug

For Resque: start resque worker with very vobose mode.
e.g.

VVERBOSE=true QUEUE=* rake environment resque:work

For Newrelic: set log level with debug in newrelic.yml

  log_level: debug

Then I tested the job with script/console. You can run the job like this:

% script/console
> Resque.enqueue HelloWorldJob
=> Enqueues a job and it will be executed on Resque worker
> HelloWorldJob.process
=> Executes a job directly without queueing

You should be able to confirm that the job executed directly on console is monitored on RPM and shown in its management screen. But the one proccessed by Resque never comes to the screen.

Step 4. Try to know what happens in Resque

I proceeded the investigation with the following cycle.

1. Run job on Resque and script/console
2. Compare the log of Resque to the one of script/console
3. Make an assumption and put some debug codes in Resque or Newrelic RPM (Thanks god those are opensource!)
4. Restart Resque worker and script/console
5. Back to 1

Sorry but there is no magic and shortcut. But after I spent about 15 minutes or so with the cycle, I found(and remembered at the same time) that Resque uses forking for processing a job and I was convinced that it would cause the issue. So I changed the code on Reque not to fork the process as an experment.

in lib/resque/worker.rb

    def fork
+      return false

Then ran the job via Resque. Yay, the transaction information was shown in RPM.

Step 5. Then a little hack

Of course, you can’t turn off the forking of Resque. That is something that makes Resque awesome. So I reveted the change I made on worker.rb and focused on finding a way to monitor forked process with RPM.

What I tried at first is to call NewRelic::Agent.shutdown which sends the all queued data after the job is done. RPM sends the log every 60 seconds but the job finishes about in 3 seconds. So that the job has to make sure to send the data before ended.

class HelloWorldJob
  include NewRelic::Agent::Instrumentation::ControllerInstrumentation

  @queue = :low
  def self.perform
    HelloWorldJob.new.hello_world
    NewRelic::Agent.shutdown
  end

  def hello_world
    RAILS_DEFAULT_LOGGER.info "#{Time.now}: Hello World!"
    RAILS_DEFAULT_LOGGER.flush
    sleep(3)
  end

  add_transaction_tracer :hello_world, :name=>'hello_world'
end

On console/script, it worked in a way I expected, though, it didn’t on Resque. Dammn it. Next I looked into RPM’s codebase with the cycle I showed on Step 4.

Then I found that RPM resets the connection information if the current process id is different from the one which RPM got when it started. Then, on that situation, it tries to start worker thread which reports the information to RPM server every 60 seconds. But it takes seconds to launch and the job finishes before the thread finishes communicating server.

Anyway you don’t want to create a thread for RPM everytime Resque job is created. It just wastes your machines resource and makes a job process slow in terms of background job. Alternatively it would be nice if the forked process use the parent connection information simply. I monkey-patched onto RPM to behave in that way. This patch shouldn’t affect monitoring for other applications.

in lib/new_relic/agent/agent.rb

    def ensure_worker_thread_started
      return unless control.agent_enabled? && control.monitor_mode? && !@invalid_license

-     if !running?
+     if !running? && !control['resque']

Then changed the codebase of the job like this.

class HelloWorldJob
  include NewRelic::Agent::Instrumentation::ControllerInstrumentation

  @queue = :low
  def self.perform
    NewRelic::Control.instance['resque'] = true
    HelloWorldJob.new.hello_world
    NewRelic::Agent.shutdown
  end

  def hello_world
    RAILS_DEFAULT_LOGGER.info "#{Time.now}: Hello World!"
    RAILS_DEFAULT_LOGGER.flush
    sleep(3)
  end

  add_transaction_tracer :hello_world, :name=>'HelloWorldJob#hello_world'
end

Wheeee, now the job is shown and tracked as a transaction on RPM. You can track the exceptions occurred in Resque jobs as well as slow transactions with RPM.

Step 6. Refactor

To monitor all jobs in same way, I refactor HelloWorldJob with its super class. I hope that RPM is going to support forked background process like Resque officially in a nice way and the hack is no longer needed soon. So it doesn’t make sence to write this ugly hack on every single job. Instead of that, I put all newrelic related code onto a super class.

So here is a final codebase.

class BaseJob
  include NewRelic::Agent::Instrumentation::ControllerInstrumentation

  # This is called from Resque.
  # To be wrapped with the common operation, please describe job in the instance's perform method.
  def self.perform(*args)
    NewRelic::Control.instance['resque'] = true
    self.new.perform_wrapper(*args)
  ensure
    NewRelic::Agent.shutdown
  end

  # Sends a hint to our monitoring system, newrelic rpm
  def add_custom_parameters(key, value)
    NewRelic::Agent.add_custom_parameters(key => value.to_s)
  end

  # Calls :perform with monitoring on newrelic rpm
  def perform_wrapper(*args)
    # :task seems available only for charged plan. When you test this with a free plan, you have to get rid of it.
    # perform_action_with_newrelic_trace(:name=>'perform') do
    perform_action_with_newrelic_trace(:name=>'perform', :category => :task) do
      begin
        perform(*args)
      ensure
        logger.flush if logger && logger.respond_to?(:flush)
      end
    end
  end

  # Override this method instead of the class method.
  def perform(*args)

  end

  def logger
    RAILS_DEFAULT_LOGGER
  end
end

# Test purpose job. It output the information to log.
class HelloWorldJob < BaseJob
  @queue = :low

  def perform(who='World')
    # This sends the information to NewRelic RPM
    add_custom_parameters :whom, who

    logger "#{Time.now}: Hello #{who}!"
    sleep(3)
  end

end

Epilogue
I have to say lastly that reading Resque’s codebase was absolutely fun. It is simple and neat. You might feel that you can write the codebase yourself easily. But there are the good design decisions behind that: which are using only Redis for queue backend and forking for processing a job. Cool.

it "should stub/mock helper_method"
  stub.proxy(response).template do |tmpl|
    stub(tmpl).your_helper_method { "stubbed" }
  end
  get :action_you_want_to_test
  response.body.should =~ /stubbed/
end

There might be better ways, though, I think it is good enough.

先日、長男が来年1月から通うPrimary School（小学校）が決定した。London（UK全部？）の公立小学校は1年生の前にReception Classというのがあって、4才のうちに小学校に通い始めることになる。通い始める時期も微妙に違っていて、9月〜1月生まれの子は9月入学、2月〜8月生まれの子は遅れて1月から入学するという変な制度。うちの子は3月生まれなので、後者に入る。小学校の願書は前年の1月中に出さないといけない。つまりまだ子供は3才なのに、どの小学校に行くかとか考えないといけない。これ子供がちっこいだけに、けっこう現実感がでないものです。

うちのCouncil（区）では願書に4つの希望校を優先順に書いて提出。運のいいことに、我が家の近くには評判の良い小学校が多く、埋めるのには困らない。しかもうちから最短の2校、H校とF校はどちらも良さそうなので、その2校に絞って学校見学。どちらも評判通りの良い小学校に思えたけど、生徒数、子供の伸び伸び度、Head Teacherと直接話せ、彼に好感が持てた事でF校に気持ちが傾く。加えて、H校DELLに対して、F 校は全てmac!! 勝負あったとばかりに、F校を第一志望にして願書を提出。

ところがなんと3ヶ月後に送られて来た結果通知は、第二志望のH校の名前が。DELL DELL DELL …。いいんだけどね別に、通うのは僕じゃないし、いい学校だったし。でも、やっぱ…ね…。ただ全てがcomplainすることで覆る可能性を秘めているのが欧米流。道はあるはずと思ったら、ありました、あっさり。F校の定員60人に対して、第一志望に書いた子は350人超。その中から、兄弟が通っている子、F校が一番近い子は優先的に合格。残った子のうち、学校から近い順に合格になっていくのだけど、合格した子のうちで、一番学校から遠い子が349m。うちからF校までの距離が353m。妻が電話で問い合わせたところ、Waiting Listの一番上に名前を置けると言われ、早速申し込み。私立と並行して申し込みをしている子もいるはずなので、かなり期待度は高い。その後も気を抜かずに、担当に印象づけるために、定期的に礼儀正しく電話で状況を問い合わせ。

そんな1年近くをかけて行われたやりとりの末に我ら夫婦に訪れたものは、一通のF校受け入れ連絡通知のお手紙と、海外生活の敵に真っ当に渡り合って勝利したとでもいったような、満足感と恍惚感。もはや子供がその学校に行く事自体は、あまりどうでも良くなっていたりしてw

そんなわけでロンドンの冬なんて好きなところが一つもなかったけど、どうも最近は悪くないようにも思う。朝起きて駅まで向かう道すがらの澄んだ空気。霧に包まれる街の風景。静まり返った暗い町並みを、古い建物の間をぬって、あてもなく歩くのもいい。

歩いていたら、ベルリン天使の詩で、冬の寒い日にピーター・フォークが手をこすって温めるシーンを思い出した。

真似をしてみるとヨーロッパの冬も悪くないと思えた。たぶんぼくもこんな感じでうす気味悪く笑ってたかもしれない。

自分が取得手続きを踏んでいるわけではないので、どんだけ厳しくなったのかなど、詳しい事はわからない。ごめんなさい。でも、実際のところをなんとか知りたい、という人にも耳寄りな情報があります。実はちょうど僕の会社でRubyプログラマを募集中です。ロンドンで働くことに興味があって、腕に自信のある人を知っていたら、その人が人柱となって、もっと詳しい情報を提供してくれるでしょう。もちろん自分で人柱になれる人は、それに越したことはありません。

興味のある人は ononoma(at)gmail(dot)com まで

セッション全体を通して興味深いと思った傾向が抽象化に対してのスタートアップの取り組み。スタートアップ企業のウェブ開発では、常にマーケットインするためのスピードと、その後のスケーラビリティや拡張性との狭間の意思決定で非常に難しい選択を強いられる。よく軌道に乗り始めたスタートアップに就職したエンジニアが、「外から見ると良くてもさ、中身はコードがスパゲッティでやってられないよ」みたいな文句を言うのを耳にするけど、彼らは「立ち上げる」ことがどんなに大変か知らないのだ。起業というのは、コースが未定で、レースの途中に制限時間があって、しかもゴールまでの距離が不明確なマラソンを走ってるみたいなものだ。最初の1kmは2分で走ってもらわないと失格です、といわれたら42.195kmのペース配分なんて考えてられない。先の例では、そんな風にして20km走った時点で、後から入って来た仲間に、「おいおいそんなんじゃ42.195km走れないよ」って言われるようなものだけど、そんな彼らも早晩そういう立場に立つ事になる。スケーラビリティや拡張性を考慮するのは大事だけど、パフォーマンスや運用コストが問題になってから考えればいいや、拡張する必要になってから考えればいいやっていう気楽さが必要だし、そのほうが効率が良いケースの方が多々ある。0kmの時点では色んな可能性があるわけだし、その可能性に全て手を打つ事で生じる機会損失を考慮しなければならない。

ただそんなスタートアップを取り巻く状況に多少変化があるのを今回のカンファレンスで感じた。原則的な考え方は一緒なんだけど、

• 2倍、4倍とどんどんユーザ数が増えるサービスに関わった経験を持つ技術者が増えた
• 同様にリアルタイムコミュニケーション系のサービスに関わった経験を持つ技術者が増えた
• そしてその経験がweb知として共有される機会が増えた

ことによって、0km地点での技術者のやれること（競争的な言い方をすればやらなきゃいけないこと）が多くなってる感じがした。例えばmemcachedなんかは0km地点でも、それほど手間を掛けずに設計に組み込むことができるだろうし、それは初期段階のユーザの急激な増加を捌くのに役立つだろう。 また、

• ajax以降のweb UIの進化がUIの差別化の評価が大きくしている

UIの層をキッチリと抽象化して、携帯電話、iPhoneなどのデバイスへの対応を意識したり、ユーザをクラスタ化して（初心者、上級者など）それぞれの見せ方を変えるとか。またヨーロッパではi18nもとても重要視されているので、そのへんの取り組みとか。会場にはヨーロッパ各国から参加者が来てて色々と話してみたけど、例え国民の英語能力が高いとしても、やっぱり英語のみのサイトは母国語サイトに負けるとの意見が多かった。この辺を考える事はアーキテクトとして当たり前じゃんという人も多いかもしれないけど、時間とコストの制約が厳しいスタートアップ企業が「やれること」の範囲は今もどんどん広がっていることを実感するのはやはり興味深い。

技術的な話以外では、VC、シリコンバレーとロンドン、クレジットクランチがスタートアップに与える影響などなど、色々とあったけど、個人としては小難しい事を考えずに、リラックスして、好きな事を楽しくやりたいって感じだし、おおむねみんなもそんな雰囲気。そんなのゴチャゴチャ考えたって、なるようにしかならないよねえ。

そうそう、セッションの1/3くらいがビデオで配信されているので、興味がある人は見てみてください。

Firefox3なんてリリースされたのいつの話だよ、と自分でも突っ込みたくなるけど、最近は自分ですら使ってないからなあ。クリップボードと、lingr以外（twitterとかrejawとか）のサービスも対応してくれたら、使ってあげてもいいんだけど、現状じゃどうも物足りない。どうせアップデートするならば、自分で使いたいと思うようなツールに仕上げれる時間が取れてからにしようと考えてるうちに、2008年の夏も終わってしまいました。そもそも僕、Firefoxは仕事でしか使ってないし、気温と共に自分で使いたい熱は下がる一方。

そんな重い腰をあげたのは、何通かのフィードバックのメール。何かしらの反応があるというのは嬉しいものです。それが好意的な反応だと、とても嬉しいものです。知らなかったけど、大分前にLingrのblogでも取り上げてくれてたみたいだし、まあこれくらいはやらなきゃな、と思った次第。

ということで、FOWA, Feature of Web Apps に行きます。カンファレンスも楽しみだけど、Londonに来てからこういう大きなイベントに参加するのは初めてなので、ネットワーキングのほうも頑張りたいところ。英語はまだまだしょぼいけど、気後れせずに（しないけど）色んな奴と話してみようっと。そうやって会って話をすのって、やっぱり刺激を受けることも大きいし、そういう刺激って大事だなと思うのです。Londonだけでなく他のEuropeの国からも多くの参加者が来ると思うので、なるべく多くの人と話せるといいな。うーん、楽しみ。ちょっと色々やる気でてきた。

Londonではあまり日本人と知り合う機会もないので、FOWAに行く人でこのブログにたどり着いた人が何かの間違いでいたら、当日会場で会えたらそれもまたうれしい。連絡先は、 ononono spamma+blog@gmail.com です。

正直なところは、ビザ延長が正式に許可されたというだけでもうれしい。大丈夫だと思ってても、どうしても気に掛かっちゃうし、こういうのを待ってるジワジワとしたストレスは本当に嫌だ。

なんかホッとしたら風邪ひいたみたい。転職周りのビザ手続きについてまとめようと思ったのだけど、今度にしよう。