Sentry

With Sentry, the agent can see what broke when the requester hit the problem: the error, the line of code it happened on, what the app did just before, and the request. It reads only. It never changes anything in Sentry, never resolves an issue, and never reads anything outside the projects you choose.

Sentry sits beside your logs. A platform can have Sentry and a log source (Loki, Elasticsearch, OpenSearch or Datadog) at the same time: one holds errors, the other everything else.

The log watcher uses the same connection: new Sentry issues can become tickets, like errors in your logs.

Connect it#

1. 1

   Go to Settings › Live system. Click Connect a cluster, logs or Sentry (or Connect another), and choose Sentry, under Errors. Its Errors row shows under the card.

2. 2

   Choose Where your Sentry is: sentry.io in the US, sentry.io in the EU, or your own Sentry server. For your own server, enter its Server address.

3. 3

   Enter the Organisation: its short name, as in your Sentry address (acme in acme.sentry.io).

4. 4

   Enter the Auth token (see Make a token below).

5. 5

   Click Save, under the fields. The projects the token sees are listed.

6. 6

   Tick this platform's Projects, and click Save again.

7. 7

   Click Check connection.

If you save with no project ticked, every project the token sees then is saved. Projects added to Sentry later are read only once you tick them.

If you change Where your Sentry is, the server address or the organisation, the saved token is removed when you save, so it never goes to the new place. Enter it again.

Check connection signs in with the token, and says which organisation it reads, which projects, and how many unresolved issues they had in the last 24 hours. It says so if Sentry refused the token, or the token can't read issues.

Make a token#

The token only needs to read. The best is an internal integration's token, which isn't tied to a person.

1. 1

   In Sentry, open Settings › Developer Settings › Custom Integrations, and click Create New Integration. Choose Internal Integration.

2. 2

   Name it Cerberius Agents. Under Permissions, set Project, Issue & Event and Organization to Read. Leave everything else at No Access.

3. 3

   Save it, then copy its token under Tokens.

A personal token works too: User settings › Personal Tokens, with the scopes org:read, project:read and event:read. It reads what that person can see, and stops working if they leave.

What the agent reads#

• Issues: searched in your projects, with Sentry's own search words, such as is:unresolved, "payment failed" or user.email:[email protected].
• One issue with one of its events: the exception and its stack trace, with the line of code, what happened before it (breadcrumbs), the request, the user, the release and tags.
• An issue's latest events: when, which release, which environment, which user.

Values that can hold secrets are hidden before the agent sees them: request headers (all but a few harmless ones, like the browser's name), cookies, environment variables, and every field whose name says password, token, key, secret or session. The names stay, so the agent still knows they were there.

The log watcher and Sentry#

When the log watcher is on, it also looks at Sentry every 5 minutes, unless you switch Sentry off on its page:

The same wait, daily limit and quiet days apply as for your logs. A Sentry issue seen while a log error's ticket waits joins that ticket, and the other way round: one incident, one ticket.