Sentry Go SDK with ZipLogger: setup and support

Set up

In ZipLogger, open Settings → API keys and create a key with Can read data unchecked. Copy the Sentry DSN shown under it (shown once, like the key).
Install the SDK: go get github.com/getsentry/sentry-go
Initialise it with that DSN. If you already use Sentry, only the DSN changes.

Set release to <service>@<git sha>. ZipLogger has no project per service: the part before @ is the service, and the SHA is the commit the regression engine blames from.

The DSN carries the key hex-encoded and always ends in /1. Point it at your workspace address (https://<workspace>.ziplogger.ai) or app.ziplogger.ai; both work.

err := sentry.Init(sentry.ClientOptions{
	Dsn:              "https://[email protected]/1",
	Release:          "checkout-api@" + gitSHA, // service@commit
	Environment:      "production",
	EnableTracing:    true,
	TracesSampleRate: 0.2,
})
if err != nil {
	log.Fatal(err)
}
defer sentry.Flush(2 * time.Second)

What arrives

The test sample captured the same error twice inside a POST /checkout transaction with a database span and an HTTP span, sent a warning message, two structured logs and a cron check-in pair, then crashed with an unhandled error. Each answer was read back through ZipLogger’s own API.

Signal	With sentry-go 0.50.0
Errors and Issues	Yes. `capture_exception` / `captureException` is an error line and an Issue; the same error twice is one Issue with two events, titled by the error type and culprit function.
Unhandled errors	Go has no global hook: recover the panic yourself (at the top of `main` and of each goroutine), report it with `sentry.CurrentHub().Recover(err)`, flush, then re-panic. The SDK marks it fatal but does not say whether it was handled. The SDK's HTTP middlewares (`sentryhttp` and the framework packages) do this for request handlers (not part of this test).
Stack frames, in_app, source lines	Frames and in_app, yes. Source lines, no: sentry-go 0.50 sends the file and line only. Errors wrapped with `github.com/pkg/errors` or `fmt.Errorf("%w")` are titled after the error's own type, not the wrapper's.
Breadcrumbs, tags, user, contexts	Yes. Shown on the Issue page; tags are searchable as `tag.<name>`, the user as `userId`.
Release and environment	Yes. `release: "checkout-api@3f9a2c1"` gives the service `checkout-api` and the commit `3f9a2c1`; the release is listed under Releases.
Tracing	Yes. The transaction and its child spans become a trace (server root, client children), and the service appears in APM within a minute or two. Errors inside the transaction link to it.
Structured logs	Yes. Logger records become log lines at their level, grouped by their message template.
Cron check-ins	Yes. Each check-in is a log line; with a `monitor_config` the heartbeat is created and its schedule kept in step. A failed or missed run opens an incident.
Profiling	No: sentry-go has no profiler. Send Go profiles to ZipLogger with the Pyroscope SDK instead (Profiling in the docs).

Good to know

Capture errors on the hub of the request's context (sentry.GetHubFromContext(ctx)), so the error carries the trace it happened in.
Wrap errors with github.com/pkg/errors (or another wrapper the SDK reads stacks from) to get the stack of where the error was created; a plain errors.New only has the stack of where it was captured.
Not stored: replays recorded by the Sentry SDK, attachments, user feedback and client reports. The SDK gets a normal success answer for them. Past events stay in Sentry.

What carries over from Sentry, and what does not → · Sentry SDKs in the docs →