We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.

Sentry is a powerful service that allows apps to send arbitrary events, messages, exceptions, and bread-crumbs (logs) to your sentry account. In simplest terms, it’s a dial-home service but also has a rich feature set including event filtering, data scrubbing, several SDKs, and custom and release tagging, as well as integration with third party tools such as Slack, GitHub.

Although Sentry reporting is on by default, starting from v20.03.1 and v20.07.0, there is a configuration flag enable-sentry which can be used to completely turn off Sentry events reporting.

​
Basic Integration

​
Panics (runtime and manual)

  • As of now, at Dgraph, we use Sentry reporting for capturing panics only. For manual panics anywhere in the code, sentry.CaptureException() API is called.

  • For runtime panics, Sentry doesn’t have a native method. After further research, we chose the approach of a wrapper process to capture these panics. The basic idea for this is that whenever a dgraph instance is started, a second monitoring process is started whose only job is to monitor the stderr for panics of the monitored process. When a panic is seen, it’s reported back to sentry via the CaptureException API.

​
Reporting

Each event is tagged with the release version, environment, timestamp, tags, and the panic stack trace as explained below.

​
Release

This is the release version string of the Dgraph instance.

​
Environments

We’ve defined 4 environments:

dev-oss / dev-enterprise: these are events seen on non-released / local developer builds.

prod-oss/prod-enterprise: these are events on released version. Events in this category are also sent on a slack channel private to Dgraph

Tags:

Tags are key-value pairs that provide additional context for an event. We’ve defined the following tags:

dgraph: this tag can have values zero or alpha depending on which sub-command saw the panic/exception.

​
Data handling

We strive to handle your data with care in a variety of ways when sending events to Sentry

  1. Event Selection: only panic events are sent to Sentry from Dgraph.
  2. Data in Transit: events sent from the SDK to the Sentry server are encrypted on the wire with industry-standard TLS protocol with 256 bit AES Cipher.
  3. Data at rest: events on the Sentry server are also encrypted with 256 bit AES cipher. Sentry is hosted on Google Cloud and as such physical access is tightly controlled. Logical access is only available to sentry approved officials.
  4. Data Retention: Sentry stores events only for 90 days after which they are removed permanently.
  5. Data Scrubbing: the Data Scrubber option (default: on) in Sentry’s settings ensures personally identifiable information doesn’t get sent to or stored on Sentry’s servers, automatically removing any values that look like they contain sensitive information for values that contain various strings. The strings we currently monitor and scrub are:
  • password
  • secret
  • passwd
  • api_key
  • apikey
  • access_token
  • auth_token
  • credentials
  • mysql_pwd
  • stripetoken
  • card[number]
  • ip addresses

We’re overhauling Dgraph’s docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.

Sentry is a powerful service that allows apps to send arbitrary events, messages, exceptions, and bread-crumbs (logs) to your sentry account. In simplest terms, it’s a dial-home service but also has a rich feature set including event filtering, data scrubbing, several SDKs, and custom and release tagging, as well as integration with third party tools such as Slack, GitHub.

Although Sentry reporting is on by default, starting from v20.03.1 and v20.07.0, there is a configuration flag enable-sentry which can be used to completely turn off Sentry events reporting.

​
Basic Integration

​
Panics (runtime and manual)

  • As of now, at Dgraph, we use Sentry reporting for capturing panics only. For manual panics anywhere in the code, sentry.CaptureException() API is called.

  • For runtime panics, Sentry doesn’t have a native method. After further research, we chose the approach of a wrapper process to capture these panics. The basic idea for this is that whenever a dgraph instance is started, a second monitoring process is started whose only job is to monitor the stderr for panics of the monitored process. When a panic is seen, it’s reported back to sentry via the CaptureException API.

​
Reporting

Each event is tagged with the release version, environment, timestamp, tags, and the panic stack trace as explained below.

​
Release

This is the release version string of the Dgraph instance.

​
Environments

We’ve defined 4 environments:

dev-oss / dev-enterprise: these are events seen on non-released / local developer builds.

prod-oss/prod-enterprise: these are events on released version. Events in this category are also sent on a slack channel private to Dgraph

Tags:

Tags are key-value pairs that provide additional context for an event. We’ve defined the following tags:

dgraph: this tag can have values zero or alpha depending on which sub-command saw the panic/exception.

​
Data handling

We strive to handle your data with care in a variety of ways when sending events to Sentry

  1. Event Selection: only panic events are sent to Sentry from Dgraph.
  2. Data in Transit: events sent from the SDK to the Sentry server are encrypted on the wire with industry-standard TLS protocol with 256 bit AES Cipher.
  3. Data at rest: events on the Sentry server are also encrypted with 256 bit AES cipher. Sentry is hosted on Google Cloud and as such physical access is tightly controlled. Logical access is only available to sentry approved officials.
  4. Data Retention: Sentry stores events only for 90 days after which they are removed permanently.
  5. Data Scrubbing: the Data Scrubber option (default: on) in Sentry’s settings ensures personally identifiable information doesn’t get sent to or stored on Sentry’s servers, automatically removing any values that look like they contain sensitive information for values that contain various strings. The strings we currently monitor and scrub are:
  • password
  • secret
  • passwd
  • api_key
  • apikey
  • access_token
  • auth_token
  • credentials
  • mysql_pwd
  • stripetoken
  • card[number]
  • ip addresses