appsignal

Gem 1.3: Giving Sinatra some love

Tom de Bruijn

Tom de Bruijn on

Hello there appsignal gem user!

We just released gem version 1.3 which improves our support for Sinatra and adds some awesome new gem features.

Sinatra use case improvements

Sinatra is a great framework which is very flexible in the many ways people can use it. Therefore supporting Sinatra for every use case out there is something we continue to work on. This 1.3 gem update update covers even more cases for Sinatra.

Modular app namespacing

When using modular apps you might have missed a mount path in the URIs inside the AppSignal event tree. Routes like /api/accounts would instead be shown as /accounts, missing the mount path. You can now see the whole path of the requests.

Modular app configuration

If you use Sinatra::Base or Sinatra::Application subclasses for your applications AppSignal will now load correctly by default. The Appsignal::Rack::SinatraInstrumentation middleware now gets included automatically, so you don't have to anymore.

Before, you installed appsignal into your Sinatra app like this:

1# Pre 1.3.0
2require 'sinatra'
3require 'appsignal/integrations/sinatra'
4class MyApp < Sinatra::Base
5  use Appsignal::Rack::SinatraInstrumentation
6end

Since version 1.3.0, you can drop the explicit use in your application class:

1# Since 1.3.0
2require 'sinatra' # 'sinatra/base' works too
3require 'appsignal/integrations/sinatra'
4class MyApp < Sinatra::Base
5end

If you use Sinatra, please check out the documentation page to read how we support Sinatra after these updates.

New features

AppSignal powered parameter filtering

The appsignal gem can now filter parameters everywhere, instead of only in Rails applications.

Inside Rails applications we continue to rely on Rails' built-in parameter filtering to filter out things like passwords on sign-in requests.

1# config/application.rb
2# or in config/initializers/filter_parameter_logging.rb (Rails 4+)
3class Application < Rails::Application
4  config.filter_parameters += [:password, :password_confirmation, :card_number, :card_cvc]
5end

For non-Rails applications you can now use AppSignal's own parameter filtering to do the same.

You can filter request parameters using a blocklist so you don't accidentally send all your users' passwords to our servers.

Start using it in gem version 1.3 by adding the following to your config file:

1# config/appsignal.yml
2production:
3  filter_parameters:
4    - password
5    - confirm_password

Or use an environment variable instead:

1export APPSIGNAL_FILTER_PARAMETERS="password,confirm_password"

Hostname config option

Set your application's hostname with the hostname config. Useful for when you run on servers with randomly generated hostnames.

Take back control of your hostnames as they appear in AppSignal by setting them to something more descriptive with this config setting.

1# config/appsignal.yml
2production:
3  hostname: frontend1

Alternatively, you can set a hostname with the APPSIGNAL_HOSTNAME environment variable per machine, if you run multiple machines.

1export APPSIGNAL_HOSTNAME="worker42"

Instrumentation for Ruby methods

We've added a new way to instrument your code. Using the new Method integration you can now track the performance of methods directly. This allows for better insights of individual methods in your application, so you can more easily identify which parts are not performing well.

1require 'appsignal/integrations/object'
2class Foo
3  def bar
4    1
5  end
6  appsignal_instrument_method :bar
7
8  def self.baz
9    sleep 10
10    2
11  end
12  appsignal_instrument_class_method :baz
13end
14
15Foo.new.bar
16# => 1
17Foo.baz
18# => 2

Read more about it on the documentation site.

Webmachine and DataMapper

We support Webmachine and DataMapper now! DataMapper works straight out of the box. For Webmachine you will need some manual configuration.

Host metrics on by default

Introduced in Gem 1.2, host metrics are now on by default.

Furthermore this release includes some other additions and refactorings of internals, too much to list here. See the change log for details. Get in touch with us if you run into problems after upgrading.

Enjoy!

Share this article

RSS
Tom de Bruijn

Tom de Bruijn

Tom is a developer at AppSignal, organizer, and writer from Amsterdam, The Netherlands.

All articles by Tom de Bruijn

AppSignal monitors your apps

AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!

Discover AppSignal
AppSignal monitors your apps