# Sentry (Self-Hosted) ## Overview Sentry is the centralized error tracking and observability platform used across the SilverLinux infrastructure. It is deployed as a full self-hosted distributed system composed of multiple interconnected services. This deployment is production-ready and runs as an isolated Docker Compose stack. --- ## Service Status - Status: Running - Compose Project: sentry-self-hosted - Container Count: 70+ services --- ## Public Access Sentry is exposed via Nginx Proxy Manager: - Domain: https://sentry.silveressence.net - Internal proxy container: sentry-self-hosted-nginx-1 - Port: 9000 → 80 (internal nginx proxy mapping) Only the Nginx entry container is exposed externally. All other services are internal-only. --- ## Architecture Overview Sentry is a distributed event processing pipeline: ``` Client Applications → Relay → Kafka → Snuba → ClickHouse → Web API (UI + Query Layer) ``` --- ## Core Components ### Web Interface - Container: sentry-self-hosted-web-1 - Purpose: UI + API layer ### Relay - Container: sentry-self-hosted-relay-1 - Purpose: event ingestion gateway ### Kafka - Container: sentry-self-hosted-kafka-1 - Purpose: event streaming backbone ### Snuba - Multiple consumer containers - Purpose: event processing and query engine ### ClickHouse - Container: sentry-self-hosted-clickhouse-1 - Purpose: high-performance event storage ### PostgreSQL - Container: sentry-self-hosted-postgres-1 - Purpose: metadata storage ### Redis - Container: sentry-self-hosted-redis-1 - Purpose: caching and coordination ### Workers Multiple background services: - taskworker - cron - cleanup - subscription consumers - metrics processors - ingestion pipelines ### Storage - SeaweedFS used for object/file storage --- ## Networking - Docker network: sentry-self-hosted_default - External exposure: ONLY nginx container via proxy network - All processing services remain isolated internally --- ## Data Flow 1. Application sends events to Sentry SDK 2. Relay receives and validates events 3. Kafka buffers event streams 4. Snuba processes and transforms events 5. ClickHouse stores event data 6. Web service queries and displays results --- ## Data Storage - PostgreSQL → metadata - ClickHouse → event storage - Kafka → event streaming buffer - Redis → caching/coordination - SeaweedFS → attachments and file objects --- ## Backup Requirements The following must be backed up: - PostgreSQL database volume - ClickHouse data volume - Sentry configuration files - Any persistent Kafka data (if enabled) --- ## Management with slcompose ### Start Sentry ```bash slcompose up sentry ``` ### Stop Sentry ```bash slcompose down sentry ``` ### Restart Sentry ```bash slcompose restart sentry ``` ### View Live Logs ```bash slcompose logs sentry ``` ### View Recent Logs ```bash slcompose logs-tail sentry 500 ``` ### View Injected Environment Variables ```bash slcompose env sentry ``` --- ## Important Notes - This is a distributed system; services must not be split or partially deployed. - Updates must preserve service group integrity. - Only the web/nginx layer should be exposed publicly. - All 70+ containers are managed as a single atomic unit via slcompose. --- ## Related Documentation - [orchestration.md](orchestration.md) — Service orchestration with slcompose - [AI_CONTEXT.md](AI_CONTEXT.md) — Infrastructure overview - [services.md](services.md) — All services on SilverLinux