4teamwork / ftw.raven

Plone addon for sentry

Table of Contents

• Purpose
• Installation and configuration
• Configuration-Test
• Release tracking
  • Version of a released distribution
  • Git SHA of checkout
• Ignored exceptions
• Report JavaScript errors
• Additional tags
• Links
• Copyright

Purpose

This package extends raven, the Sentry integration with a Plone integration wich is not logger based but hooks into the Zope exception handling.

Be aware that there is already a standard logging based Zope / Plone integration for raven. You should use the standard implementation unless you want the exception hook based integration.

Installation and configuration

• Add the ftw.raven package to your dependencies.
• Configure the raven client with environment variables in buildout

Example configuration for buildout:

[instance]
eggs +=
    ftw.raven
environment-vars +=
    RAVEN_DSN https://123:[email protected]/2

Configuration-Test

You can test your configuration by visiting the view raven-test on any context as Manager-user. This will trigger an exception which should appear in your sentry project.

Note that it's possible that the trigger doesn't work on local test systems in some cases.

In JavaScript you can call the function raven_test() in your javascript console, which will also trigger an exception.

Release tracking

When an exception is reported, the release can be sent along. A release can either be the version number of a released distribution (e.g. released on pypi) or the HEAD SHA of a project checkout when the app is not released on pypi.

Version of a released distribution

For using a distribution version as release, the environment variable RAVEN_PROJECT_DIST must contain the name of the distribution, e.g.

[instance]
environment-vars +=
    RAVEN_PROJECT_DIST my.project

Git SHA of checkout

Usually the buildout root is a checkout of the project, thus we need to configured the RAVEN_BUILDOUT_ROOT so that the git repository is found:

[instance]
environment-vars +=
    RAVEN_BUILDOUT_ROOT ${buildout:directory}

Ignored exceptions

By default, not all exceptions are reported, because some exceptions such as redirects or 404s are not errors but are implemented as exceptions. Without configuration, the exceptions NotFound, Unauthorized, Redirect and Intercepted.

Reporting of those exceptions can be enabled by with the environment variable RAVEN_ENABLE_EXCEPTIONS:

[instance]
environment-vars +=
    RAVEN_ENABLE_EXCEPTIONS NotFound, Redirect

If you need to disable custom exceptions, you can do that with the environment variable RAVEN_DISABLE_EXCEPTIONS:

[instance]
environment-vars +=
    RAVEN_DISABLE_EXCEPTIONS UnimportantError

Report JavaScript errors

In order to be able to report JavaScript-errors, the ftw.raven:default Generic Setup profile must be installed, which registers a JavaScript including the raven library and the configuration.

Additional tags

It is possible to report additional, predefined tags for a deployment. The tags may be directly declared as JSON in the environment variable RAVEN_TAGS or the variable RAVEN_TAGS_FILE may contain a path to a json-file. These two methods may be combined, and the respective dictionaries will be merged (with tags from the RAVEN_TAGS variable taking precedence).

The JSON must be a one-level hash containing strings as keys and values.

Examples:

[instance]
environment-vars +=
    RAVEN_TAGS {"deployment": "production"}

[instance]
environment-vars +=
    RAVEN_TAGS_FILE ${buildout:directory}/conf/raven_tags.json

Links

• Github: https://github.com/4teamwork/ftw.raven
• Issues: https://github.com/4teamwork/ftw.raven/issues
• Pypi: http://pypi.python.org/pypi/ftw.raven
• Continuous integration: https://jenkins.4teamwork.ch/search?q=ftw.raven

Copyright

This package is copyright by 4teamwork.

ftw.raven is licensed under GNU General Public License, version 2.

ftw.raven's Issues

Releases: append git hash when dist is checked out

When a RAVEN_PROJECT_DIST is configured (and no RAVEN_BUILDOUT_ROOT), we should detect a source checkout (maybe based on .dev0 version ending).
If it is a source checkout, we should try to get the git SHA1 and append it to the release (e.g. 3.2.1.dev0@945a4ee).

Intercepted exceptions from plone.caching should also be ignored by default

JavaScript should not contain error_log_id

There is an error_log_id in the javascript config, which should not be there.

JavaScript: wrong typeof condition

diff --git a/ftw/raven/browser/resources/raven-integration.js b/ftw/raven/browser/resources/raven-integration.js
index 9712ffe..ce7b2f1 100644
--- a/ftw/raven/browser/resources/raven-integration.js
+++ b/ftw/raven/browser/resources/raven-integration.js
@@ -1,4 +1,4 @@
-if (typeof(raven_config) != undefined) {
+if (typeof(raven_config) != typeof(undefined)) {
   // From: https://gist.github.com/impressiver/5092952
   var ravenOptions = {
     // Will cause a deprecation warning, but the demise of `ignoreErrors` is still under discussion.

JavaScript: include default ignore urls

With #9 I've added default configs from https://gist.github.com/impressiver/5092952, but accidentally did not include ignoreUrls.
We should also include ignoreUrls.

Not working in Plone 5

Can we have a version of this that works with Plone 5? The main issues are the resource-registration and plone.app.linkintegrity with was rewritten to no longer monkeypatch the zpublisher_exception_hook

Include the error number of error_log when possible

A user usually sees a error number when an error occurs on Plone.
It would be great if the error in sentry could be found with this number.

We're currently not reporting the number, since this is another part of error handling, but we should try to do so.

optimize raven.js caching

At the moment, the raven.js is loaded at each request, possibly blocking.
We should add caches.
The problem is that it contains user-specific details at the moment.
We could probably use inline rendering for the user details for improving speed.

Support for adding custom tags

It would be nice if we could supply user-defined tags.

This would for example allow us to sum up a couple staging deployments (DEV, TEST, ...) under the same Sentry project, but distinguish them via the corresponding tags.

From what I can tell, these would need to be included in the prepared data structure here.

Wrong IP reported when proxies are used

Currently, the reported user IP is 127.0.0.1 when using Apache or another proxy.

We're currently using request.getClientAddr, which returns the IP of the proxy.

@buchi Should getClientAddr work?
I tend to get the right IP manually, as it is done here.

resolved conflict errors are reported

When conflict errors are resolved by retrying, the are reported anyway.
Since this is an expected behavior and not wrong, they should maybe not be reported.