GithubHelp home page GithubHelp logo

appsignal / appsignal-ruby Goto Github PK

View Code? Open in Web Editor NEW
177.0 8.0 113.0 6.4 MB

๐ŸŸฅ AppSignal for Ruby gem

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

License: MIT License

Ruby 97.24% C 2.43% HTML 0.12% Shell 0.21%
appsignal error-monitoring performance-monitoring custom-instrumentation ruby host-metrics rails apm metrics monitoring

appsignal-ruby's Introduction

AppSignal apm for Ruby

AppSignal solves all your Ruby monitoring needs in a single tool. You and your team can focus on writing code and we'll provide the alerts if your app has any issues.

Build status Gem Version Code Climate

Description

The AppSignal gem collects exceptions and performance data from your Ruby applications and sends it to AppSignal for analysis. Get alerted when an error occurs or an endpoint is responding very slowly.

AppSignal aims to provide a one stop solution to all your monitoring needs. Track metrics from your servers with our Host metrics and graph everything else with our Custom metrics feature.

Usage

First make sure you've installed AppSignal in your application by following the steps in Installation.

AppSignal will automatically monitor requests, report any exceptions that are thrown and any performance issues that might have occurred.

You can also add extra information to requests by adding custom instrumentation and by adding tags.

Track any error

Catch any error and report it to AppSignal, even if it doesn't crash a request.

begin
  config = File.read("config.yml")
rescue => e
  Appsignal.set_error(e)
  # Load alternative config
  config = { :name => ENV["NAME"] }
end

Read more about Exception handling in our documentation.

Tagging

Need more information with errors and performance issues? Add tags to your requests to identify common factors for problems.

Appsignal.tag_request(
  user: current_user.id,
  locale: I18n.locale
)

Read more about Tagging in our documentation.

Custom instrumentation

If you need more fine-grained instrumentation you can add custom instrumentation anywhere in your code.

# Simple instrumentation
Appsignal.instrument("array_to_hash.expensive_logic", "Complex calculations") do
  array = [["a", 1], ["b", 2], ["c", 3]]
  Hash[array]
end

# Add the query that you're monitoring
sql = "SELECT * FROM posts ORDER BY created_at DESC LIMIT 1"
Appsignal.instrument("fetch.custom_database", "Fetch latest post", sql) do
  # ...
end

# Nested instrumentation calls are also supported!
Appsignal.instrument("fetch.custom_database", "Fetch current user") do
  # ...

  Appsignal.instrument("write.custom_database", "Write user update") do
    # ...
  end
end

Read more about custom instrumentation in our documentation.

Installation

First, sign up for an AppSignal account and add the appsignal gem to your Gemfile. Then, run bundle install.

# Gemfile
gem "appsignal"

Afterward, you can use the appsignal install command to install AppSignal into your application by using the "Push API key". This will guide you through our installation wizard.

appsignal install [push api key]

Depending on what framework or gems you use some manual integration is required. Follow the steps in the wizard or consult our integrations page for help.

If you're stuck feel free to contact us!

Supported frameworks and gems

AppSignal automatically supports a collection of Ruby frameworks and gems, including but not limited to:

  • Ruby on Rails
  • Rack
  • Sinatra
  • Padrino
  • Grape
  • Webmachine
  • Capistrano
  • Sidekiq
  • Delayed Job
  • Resque
  • Rake

AppSignal instrumentation doesn't depend on automatic integrations. It's easy to set up custom instrumentation to add keep track of anything.

For more detailed information and examples please visit our integrations page.

Front-end monitoring (Beta)

We have a Front-end monitoring program running in Beta currently. Be sure to check it out!

Supported systems

Currently the AppSignal agent works on most Unix-like operating systems, such as most Linux distributions, FreeBSD, macOS, excluding Microsoft Windows.

For more detailed information please visit our Supported systems page.

Releases

Following the process below to release a new version of the Ruby gem.

  1. Make sure mono is installed by following the installation instructions.
  2. Run: mono publish
    • Mono will automatically bump the version number based on the .changesets/.
    • Mono will automatically update the CHANGELOG.md file based on the .changesets/.
  3. Confirm with your two-factor authentication token for Rubygems.org, twice.

Development

Installation

Make sure you have Bundler installed and then use the Rake install task to install all possible dependencies.

# Install Bundler
gem install bundler
# Bootstrap the project
mono bootstrap
# Install the AppSignal extension and _all_ gems we support.
bundle exec rake install
# Only install the AppSignal extension.
bundle exec rake extension:install

Git source for Bundler

When specifying a git source for the AppSignal gem in Bundler we do not support JRuby. This is because our gemspec defaults to the Ruby implementation for installing the AppSignal C-extension.

# Gemfile
gem "appsignal",
  :git => "https://github.com/appsignal/appsignal-ruby.git",
  :branch => "main"

When you need to use a git source of the gem in your JRuby install, you'll need to run the following to install the C-extension on JRuby. Note that this post-install step is not possible on platforms such as Heroku where the app is sent through a deploy pipeline and the app is started immediately after.

bundle install
(cd $(bundle show appsignal)/ext && rake)

Testing

bundle exec rspec
# Or with one file
bundle exec rspec spec/lib/appsignal_spec.rb

Note that some specs depend on certain other gems to run and if they are not loaded RSpec will not run them. See also Testing with other gems.

Testing with other gems

AppSignal runs in many different configurations. To replicate these configurations you need to run the spec suite with a specific Gemfile.

BUNDLE_GEMFILE=gemfiles/capistrano2.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/capistrano3.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/dry-monitor.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/grape.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/hanami.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/http5.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/no_dependencies.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/padrino.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/que.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/que_beta.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-3.2.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-4.0.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-4.1.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-4.2.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-5.0.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-5.1.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-5.2.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/rails-6.0.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/resque-1.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/resque-2.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/sequel-435.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/sequel.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/sinatra.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/webmachine.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/redis-4.gemfile bundle exec rspec
BUNDLE_GEMFILE=gemfiles/redis-5.gemfile bundle exec rspec

If you have either RVM, rbenv or chruby installed you can also use rake build_matrix:local:generate to generate a script that runs specs for all Ruby versions and gem combinations we support.

We run the suite against all of the Gemfiles mentioned above and on a number of different Ruby versions.

Versioning

This gem uses Semantic Versioning.

The main branch corresponds to the current stable release of the gem.

The develop branch is used for development of features that will end up in the next minor release.

Open a Pull Request on the main branch if you're fixing a bug. For new new features, open a Pull Request on the develop branch.

Every stable and unstable release is tagged in git with a version tag.

Contributing

Thinking of contributing to our gem? Awesome! ๐Ÿš€

Please follow our Contributing guide in our documentation and follow our Code of Conduct.

Also, we would be very happy to send you Stroopwafles. Have look at everyone we send a package to so far on our Stroopwafles page.

Support

Contact us and speak directly with the engineers working on AppSignal. They will help you get set up, tweak your code and make sure you get the most out of using AppSignal.

Also see our SUPPORT.md file.

appsignal-ruby's People

Contributors

alanhala avatar alextk avatar andrielfn avatar arempe93 avatar bdewater-thatch avatar bobmaerten avatar cmer avatar dennisvdvliet avatar dwilkins avatar filipegiusti avatar grk avatar groguelon avatar hsbt avatar jacobvosmaer avatar jeffkreeftmeijer avatar jeromegn avatar julik avatar jvanbaarsen avatar lucasmazza avatar luismiramirez avatar manfred avatar manuelmeurer avatar matsimitsu avatar pixeltrix avatar stefanvermaas avatar suweller avatar thijsc avatar tombruijn avatar unflxw avatar wvengen avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

appsignal-ruby's Issues

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

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

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.

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.

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

`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

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

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.

`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?

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?

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:

  1. check if the middleware is present before adding ourself to the middleware stack based on it.
  2. 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

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

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.

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

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,

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.

  1. AppSignal should never crash my application
  2. When used in Rails, AppSignal should not log outside of the Rails root unless explicitly instructed to do so
  3. 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>

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?

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.

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.

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

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

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

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 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!

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

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

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>

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'

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

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.

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

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.

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>'

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:

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.

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.

[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

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!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.