A Sentry-compatible log & event gateway
with a steady write P95 under 2 ms.
Built on Go + Gin + NSQ + TimescaleDB. Existing Sentry SDKs work as-is — just point the DSN at LogTap. Structured logging ships with batching and gzip, plus search, funnels, retention, and alerting out of the box.
- /store/ /envelope/Sentry errors & exceptions
- /logs/Structured logs, batch + gzip
- /track/Event tracking, funnels & retention
- /logs/searchFull-text search & time-series aggregation
What a report request looks like
Pick an endpoint, send a simulated request, and see how the gateway responds. Latency numbers here are demo data — real measurements are in the benchmarks section below.
{
"level": "info",
"message": "payment.gateway.captured",
"fields": {
"provider": "stripe",
"amount": 4900,
"latency_ms": 32.1
}
}Two storage engines — pick by scale
The open-source edition runs on PostgreSQL/TimescaleDB: single-node to start, zero extra ops. The enterprise / cloud edition moves to ClickHouse column storage, designed for high throughput and low-cost long-term retention. Both share the same API and console, so you can migrate when scale demands it.
| Metric | Open source (PostgreSQL / TimescaleDB) | Enterprise / Cloud (ClickHouse engine) | Edge |
|---|---|---|---|
| Peak ingest EPS (events per second) Open source covers single nodes and small-to-mid teams; enterprise handles massive log streams | 10,000 ~ 20,000 EPS | 100,000 ~ 300,000+ EPS | 15× throughput headroom |
| Write P95 latency The HTTP gateway hands off to NSQ in-memory buffering and batch goroutines — reporting never blocks | 1.7–1.9 ms (flat within 120 VU) | < 1.5 ms (distributed parallel ingest) | Sub-millisecond responses |
| Storage compression ratio Hot/cold tiering and massive compression for long-retention logs | 1 : 1.5 ~ 1 : 2 (PostgreSQL B-tree, row store) | 1 : 5 ~ 1 : 10 (ClickHouse column store, LZ4/ZSTD) | 70–85% storage savings |
| Multi-dimensional analytics over 100M+ events Covers event aggregation, retention analysis, and conversion funnels | 3–10 s (single-core scans, composite indexes) | 0.1–0.5 s (vectorized engine) | Near-real-time computation |
| Operational complexity & dependencies One-command start with Docker Compose | Minimal (Postgres/Timescale + Redis + NSQ) | Distributed (ClickHouse cluster + distributed queues) | Batteries included vs horizontal scale |
Single-node benchmark (open-source edition)
Environment: single 32-core / 64 GB node — gateway + PostgreSQL 16 + Redis 7 + NSQd co-located
Errors, logs, events, alerts — one gateway
Stop maintaining Sentry, a logging stack, and an analytics service side by side. One project & key model, one storage.
Native Sentry SDK compatibility
Keep your existing Sentry SDKs — point the DSN at LogTap and you're done. The store and envelope endpoints implement the Sentry protocol, so stack traces, breadcrumbs, and tags are stored as-is; historical data can be imported from Sentry with the migration tool.
Structured logs
Report a single object or a batched JSON array, gzip supported. Keyword search runs on pg_trgm trigram indexes; list queries on time-descending indexes.
Event analytics & funnels
Once events are tracked, the console gives you DAU/MAU, top events, property breakdowns, retention cohorts, and custom funnels — no exporting to a BI tool.
Alerts & health checks
Rule hits on logs and metrics deliver via webhook, email, or SMS (Alibaba/Tencent Cloud). HTTP/TCP probes cover active dialing.
GeoIP distribution
Optionally enable GeoLite2 to resolve reporting IPs into country, city, and ASN — traffic origins and anomalies at a glance.
What happens after a request lands
Ingestion and persistence are separated by NSQ: the gateway is stateless and scales horizontally, and slow downstream queries can't take reporting down.
SDKs or cURL POST events — single or batched, with optional gzip compression.
Deserialize, authenticate, publish to NSQ — no database in the request path, so latency stays stable.
Events and logs fan out across topics and channels; database jitter never reaches the reporting side.
Consumers flush to TimescaleDB every 500 events or 20 ms — trading throughput for IO efficiency.
Integration code
Sentry SDKs need a one-line DSN change; other languages just POST JSON. Go and JS SDKs live in the repo's sdks/ directory.
curl -X POST "https://logtap.autotask.run/api/1/logs/" \
-H "Content-Type: application/json" \
-H "X-Project-Key: pk_live_sample7718" \
-d '[
{
"level": "info",
"message": "payment.settlement.succeeded",
"fields": {
"order_id": "ord_992144",
"amount": 29900,
"currency": "USD",
"duration_ms": 14.2
}
}
]'Up and running in three commands
Everything ships containerized — no manual database or queue setup. Once it's up, open logtap.autotask.run to start using it; for local deployments, visit localhost:8080.
git clone https://github.com/aak1247/logtap.git cd logtap/deploy # Generate AUTH_SECRET (base64, >= 32 bytes decoded) bash ../scripts/gen-auth-secret.sh # Start — ships with Postgres/TimescaleDB, Redis, NSQ docker compose up -d
For production, set POSTGRES_URL and run a dedicated alert worker. Full configuration lives in .env.example and docs/DEPLOYMENT.md in the repo.
Frequently asked questions about LogTap
Quick answers on migration cost, performance, licensing, and deployment.
What is LogTap?
LogTap is an open-source (MIT) high-throughput observability data gateway that combines error monitoring (Sentry-protocol compatible), structured log ingestion, event tracking with funnel and retention analysis, and multi-channel alerting. It is built on Go + NSQ + TimescaleDB / ClickHouse and deploys privately with a single Docker Compose command.
We already use Sentry. Does migrating to LogTap require code changes?
No. LogTap natively implements the Sentry Store and Envelope protocols, so SDKs like @sentry/browser and @sentry/node work unchanged — swap the DSN host to your LogTap gateway and the migration is done, with full stack traces and context preserved.
How do the open-source and enterprise editions differ?
The open-source edition runs on PostgreSQL / TimescaleDB and handles 10,000+ EPS on a single node with zero extra ops. The enterprise and cloud editions use the ClickHouse column-store engine for 100,000 ~ 300,000+ EPS, 1:5 ~ 1:10 storage compression, and multi-dimensional analytics over hundreds of millions of events in 0.1 ~ 0.5 seconds.
What is LogTap's write performance?
Measured on a single 32-core / 64 GB node with the gateway, PostgreSQL 16, Redis 7, and NSQd co-located: P95 write latency holds steady at 1.7 ~ 1.9 ms from 10 to 120 concurrent users at 5,600+ EPS, peaking at 11,200 EPS. Because the HTTP gateway is decoupled through NSQ, client reporting is never blocked by slow database queries.
How do I deploy LogTap?
Three steps: git clone the repo, run task auth:secret to generate an auth secret, then docker compose up -d --build in the deploy directory. The images bundle PostgreSQL, TimescaleDB, Redis, and NSQ — you are up in about a minute, locally or in production.
Which alerting channels does LogTap support?
Built-in HTTP / TCP health probes deliver alerts via WeCom, DingTalk, and Feishu webhooks, SMTP email, and Alibaba / Tencent Cloud SMS, with deduplication and noise suppression to prevent alert storms.
Is LogTap free and open source? What license does it use?
The open-source edition is completely free under the MIT license and can be used in commercial projects; the code lives at github.com/aak1247/logtap. Enterprise and cloud editions for massive-throughput scenarios are offered separately.
Does data pass through third parties? Is private deployment supported?
Fully private deployment is supported: all data lands directly in your own PostgreSQL / TimescaleDB / ClickHouse storage and never passes through a third-party service. GeoIP resolution uses the MaxMind GeoLite2 database bundled offline at build time — no external lookups.