README.md in sentry-raven-0.6.1 vs README.md in sentry-raven-0.7.1
- old
+ new
@@ -4,11 +4,11 @@
A client and integration layer for the [Sentry](https://github.com/getsentry/sentry) error reporting API.
## Requirements
-We test on Ruby MRI 1.8.7, 1.9.2, 1.9.3 and 2.0.0. Other versions/VMs are untested but we will accept pull requests to support them.
+We test on Ruby MRI 1.8.7, 1.9.3 and 2.0.0. Rubinius and JRuby support is experimental.
## Installation
```ruby
gem "sentry-raven" #, :github => "getsentry/raven-ruby"
@@ -39,16 +39,28 @@
No support for Rails 2 yet, but it is being worked on.
### Rack
-Add ```use Raven::Rack``` to your ```config.ru``` (or other rackup file).
+Add ```use Raven::Rack``` to your ```config.ru``` (or other rackup file).
### Sinatra
Like any other Rack middleware, add ```use Raven::Rack``` to your Sinatra app.
+### Sidekiq
+
+Raven includes [Sidekiq middleware](https://github.com/mperham/sidekiq/wiki/Middleware) which takes
+care of reporting errors that occur in Sidekiq jobs. To use it, just require the middleware by doing
+
+```ruby
+require 'raven/sidekiq'
+```
+after you require Sidekiq. If you are using Sidekiq with Rails, just put this
+require somewhere in the initializers.
+
+
## Capturing Events
Many implementations will automatically capture uncaught exceptions (such as Rails, Sidekiq or by using
the Rack middleware). Sometimes you may want to catch those exceptions, but still report on them.
@@ -95,10 +107,45 @@
* `level`: a string representing the level of this event (fatal, error, warning, info, debug)
* `server_name`: the hostname of the server
* `tags`: a mapping of [tags](https://www.getsentry.com/docs/tags/) describing this event
* `extra`: a mapping of arbitrary context
+## Providing Request Context
+
+Most of the time you're not actually calling out to Raven directly, but you still want to provide some additional context. This lifecycle generally constists of something like the following:
+
+- Set some context via a middleware (e.g. the logged in user)
+- Send all given context with any events during the request lifecycle
+- Cleanup context
+
+There are three primary methods for providing request context:
+
+```ruby
+# bind the logged in user
+Raven.user_context({'email' => 'foo@example.com'})
+
+# tag the request with something interesting
+Raven.tags_context({'interesting' => 'yes'})
+
+# provide a bit of additional context
+Raven.extra_context({'happiness' => 'very'})
+```
+
+Additionally, if you're using Rack (without the middleware), you can easily provide context with the ``rack_context`` helper:
+
+```ruby
+Raven.rack_context(env)
+```
+
+If you're using the Rack middleware, we've already taken care of cleanup for you, otherwise you'll need to ensure you perform it manually:
+
+```ruby
+Raven.context.clear!
+```
+
+Note: the rack and user context will perform a set operation, whereas tags and extra context will merge with any existing request context.
+
## Configuration
### SENTRY_DSN
After you complete setting up a project, you'll be given a value which we call a DSN, or Data Source Name. It looks a lot like a standard URL, but it's actually just a representation of the configuration required by Raven (the Sentry client). It consists of a few pieces, including the protocol, public and secret keys, the server address, and the project identifier.
@@ -166,10 +213,24 @@
```ruby
Raven.configure do |config|
config.ssl_verification = true
```
+### Logging
+
+You can use any logger with Raven - just set config.logger. Raven respects logger
+levels.
+
+```ruby
+logger = ::Logger.new(STDOUT)
+logger.level = ::Logger::WARN
+
+Raven.configure do |config|
+ config.logger = logger
+end
+```
+
## Sanitizing Data (Processors)
If you need to sanitize or pre-process (before its sent to the server) data, you can do so using the Processors
implementation. By default, a single processor is installed (Raven::Processor::SanitizeData), which will attempt to
sanitize keys that match various patterns (e.g. password) and values that resemble credit card numbers.
@@ -201,11 +262,11 @@
Done!
```
A couple of things to note:
-* This won't test your environment configuration. The test CLI forces the your
- coniguration to represent itself as if it were running in the production env.
+* This won't test your environment configuration. The test CLI forces your
+ configuration to represent itself as if it were running in the production env.
* If you're running within Rails (or anywhere else that will bootstrap the
rake environment), you should be able to omit the DSN argument.
## Contributing