Sentry e GlitchTip parlano entrambi lo stesso protocollo Sentry SDK. La configurazione lato Elido è identica per entrambi — l'unica differenza è il DSN che incollate.
Questa guida copre due direzioni: instradare gli avvisi Elido nel tuo error tracker (in modo che i problemi di abuso / TLS / API appaiano come issue da triagere), e usare Elido insieme alla tua configurazione Sentry esistente se stai già eseguendo GlitchTip in self-hosting.
Perché connetterli#
Elido emette eventi operativi utili come issue Sentry:
abuse.flagged— il nostro scanner ha contrassegnato un URL di destinazione come malware / phishing.domain.tls_renewed(variante failure) — Caddy non è riuscito a rinnovare un certificato TLS.webhook.delivery_failed— il tuo endpoint webhook ha smesso di rispondere.link.clicked.aggregated(variante anomalia) — improvviso picco di traffico 10× su un singolo link.
Probabilmente non li vuoi tutti come issue — scegli quelli che richiedono una risposta umana.
Aggiungi l'integrazione#
- Dashboard → Integrazioni → Sentry / GlitchTip.
- Incolla il tuo Sentry DSN. I DSN GlitchTip usano lo stesso formato e funzionano nello stesso campo.
- Scegli i tipi di evento da inoltrare. Il default è solo
abuse.flaggede i failure di rinnovo TLS. - Fai clic su Invia evento di test. Dovresti vedere una "issue di test" nel tuo progetto Sentry entro 10 secondi.
- Salva.
L'integrazione viene eseguita lato server. Non carichiamo il Sentry browser SDK nella tua dashboard — il tuo DSN non raggiunge mai il browser del visitatore.
Come appare l'issue#
Ogni evento inoltrato diventa un'issue formattata Sentry con:
event_id= ID evento Elido (per la de-duplicazione).level=errorper abuso + failure TLS,warningper failure di consegna webhook,infoper anomalie di picco.fingerprint= workspace ID + tipo evento + ID risorsa rilevante, così i ri-trigger della stessa issue si raggruppano correttamente in Sentry.extra= payload completo dell'evento Elido.tags=workspace,event_kind, più il tag specifico della risorsa (link_slug,domain, ecc.).
Note su GlitchTip#
GlitchTip implementa l'API di ingestione eventi Sentry ma non il set completo di funzionalità Sentry. L'integrazione invia eventi solo attraverso l'endpoint di ingestione, quindi qualsiasi funzionalità in quel scope (raggruppamento issue, fingerprint, ricerca, alerting) funziona anche in GlitchTip. Le performance trace, i replay e il profiling no, ma Elido non li invia comunque.
Se stai eseguendo GlitchTip in self-hosting dietro una rete privata, dai agli IP di uscita di Elido accesso HTTP. L'elenco completo è nella nostra pagina trust; la versione breve è 5.75.0.0/16 (Hetzner FRA) e 51.79.0.0/16 (OVH SGP).
Disabilita#
Fai clic su Disconnetti nella pagina dell'integrazione. Il DSN viene cancellato e non vengono inviati ulteriori eventi. Le tue issue Sentry esistenti non vengono eliminate — rimangono nel tuo progetto Sentry.
Limiti#
- 1 destinazione Sentry per workspace. Se hai bisogno di distribuire su più progetti Sentry, usa i webhook e un piccolo proxy.
- Rispettiamo il limite di frequenza predefinito di Sentry di 50/s per progetto. Le anomalie di picco vengono campionate prima dell'invio per rimanere sotto il limite.
Risoluzione dei problemi#
L'evento di test arriva ma gli eventi reali no. Controlla di aver selezionato i tipi di evento giusti nelle impostazioni dell'integrazione. La selezione predefinita è conservativa.
Gli eventi arrivano ma tags sono vuoti. Sentry a volte tronca i valori dei tag più lunghi di 200 caratteri (slug, domini) — diventano unknown. Questo è un limite di Sentry, non nostro.
L'endpoint di ingestione GlitchTip rifiuta con 429. La tua istanza GlitchTip sta applicando il rate limiting. O alza il limite per progetto nell'admin di GlitchTip, o filtra i tipi di evento verso quelli di cui hai bisogno.
Il DSN è stato ruotato e ora riceviamo 401. Aggiorna il DSN nella pagina dell'integrazione. Non c'è auto-detect per la rotazione del DSN.