Modular event-observability SaaS foundation for backend event ingestion, processing, persistence and alerting.
3v3nTr4cer is a backend-first, modular SaaS foundation for handling application event pipelines in Python. Its capabilities are intentionally separated into independently structured modules so they can be deployed together as one platform or evolved into standalone products: event ingestion, asynchronous processing, durable storage, alerting and failure handling.
The current version is an MVP. The backend is the primary ingestion boundary and persists events in PostgreSQL. The collector, processor and alert engine provide separate processing capabilities, while the current in-memory queue and PostgreSQL-backed dead-letter table leave a clear path toward a durable broker such as RabbitMQ or Kafka.
- Features
- Requirements
- Installation
- Quick Start
- Usage Examples
- Project Structure
- Configuration
- Contributing
- Security
- License
- Modular SaaS architecture β Use the complete platform or evolve capabilities independently
- Backend ingestion boundary β FastAPI validates and persists application events
- Asynchronous processing β Concurrent workers through an
asyncio.Queue - Event and alert persistence β PostgreSQL models for events, alerts, users and failures
- Configurable alerting β Severity thresholds for warning, error and fatal events
- Retry and dead-letter handling β Failed processor deliveries are retained for inspection
- JWT authentication β Protected public event query and creation endpoints
- Docker Compose deployment β Reproducible local multi-service environment
The platform is designed around capabilities that can be combined or packaged separately:
| Module | Responsibility | Potential product form |
|---|---|---|
| Backend API | Authentication, validation, event queries and PostgreSQL persistence | Core event-ingestion and observability API |
| Collector | Receives or observes events before asynchronous processing | Client SDK, browser integration or ingestion service |
| Event Processor | Validation, delivery retries and dead-letter routing | Processing and reliability service |
| Alert Engine | Severity evaluation and alert persistence | Independent alerting and notification module |
This modularity is a product and ownership decision, not a claim that every component already runs as a fully independent production service. The current MVP uses the backend as the official entry point:
Client or fetchTrace
|
v
FastAPI backend
|
v
PostgreSQL
The asynchronous components are prepared for later integration through a durable queue when scale, replayability or horizontal deployment becomes a requirement.
- Python: 3.11 or higher
- PostgreSQL: 14 or higher (or use Docker)
- Docker: 20.10+ (optional, for containerized deployment)
- Docker Compose: 2.0+ (optional)
- Linux (Ubuntu 20.04+, Debian 11+, CentOS 8+)
- macOS (12.0+)
- Windows 10/11 (with WSL2 recommended)
git clone https://github.com/Rub3cK0r3/3v3nTr4cer.git
cd 3v3nTr4cerpython -m venv .venv
source .venv/bin/activate # macOS/Linux
# .venv\Scripts\activate # Windows
pip install --upgrade pip
pip install -r deploy/requirements.txtcd deploy
docker compose up -dCheck service status:
docker compose psStop services:
docker compose down -vThe Docker Compose service db already provisions eventdb and initializes db/init/V1_schema_dev.sql.
For local PostgreSQL:
createdb eventdb
psql -d eventdb -f db/init/V1_schema_dev.sqlexport POSTGRES_USER=devuser
export POSTGRES_PASSWORD=devpass
export POSTGRES_DB=eventdb
export DB_HOST=localhost
export DATABASE_URL="postgresql://devuser:devpass@localhost:5432/eventdb"
export SECRET_KEY="your-secret-key"
export ALERT_MIN_SEVERITY="error"export PYTHONPATH=src:$PYTHONPATH
uvicorn core.backend.main:app --host 0.0.0.0 --port 8000
python -m core.async_lib.collector.main
python -m core.async_lib.processor.main
python -m core.async_lib.alert_engine.main- Ensure a user exists in
userstable (with hashed password). - Request token:
curl -X POST "http://localhost:8000/token" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=admin&password=secret"Response:
{
"access_token": "...",
"token_type": "bearer"
}GET /v1/eventsβ list eventsGET /v1/events/{event_id}β get a single eventPOST /v1/eventsβ create eventPOST /internal/pipeline/eventsβ ingest pipeline eventPOST /internal/pipeline/alertsβ ingest pipeline alert
Events may include both resource and referrer. They describe different parts of the request context:
| Field | Meaning | Example |
|---|---|---|
resource |
The application resource affected by the event, such as a route, API endpoint, file, service, or component. | /checkout or /api/orders |
referrer |
The page or URL that led the client to the affected resource. It describes the request origin, not the failing resource. | https://example.com/cart |
For example, an event with resource: "/checkout" and referrer: "https://example.com/cart" means that the problem occurred on the checkout resource after the client came from the cart page. The referrer may be absent when the client did not provide one or when the event was not generated by a browser navigation.
curl -X POST "http://localhost:8000/v1/events" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"severity": "info",
"timestamp": 1700000000000,
"app_name": "my-app",
"endpoint_id": "client-123"
}'curl -X POST "http://localhost:8000/internal/pipeline/events" \
-H "Content-Type: application/json" \
-d '{
"type": "event",
"payload": {"id":"evt-100","app_name":"my-app","endpoint_id":"client-123","timestamp":1700000000000}
}'curl -X POST "http://localhost:8000/internal/pipeline/alerts" \
-H "Content-Type: application/json" \
-d '{
"severity": "error",
"resource": "service-A",
"payload": {"id":"alert-1","message":"error triggered"}
}'The examples/ directory contains browser reference helpers that wrap fetch:
fetch-trace.jsβ JavaScript versionfetch-trace.tsβ TypeScript version with typed options and events
The TypeScript helper can be used as follows:
import { createFetchTrace } from "./examples/fetch-trace";
const fetchTrace = createFetchTrace({
appName: "checkout-web",
appVersion: "1.0.0",
appStage: "production",
traceEndpoint: "http://localhost:8000/internal/pipeline/events"
});
const response = await fetchTrace("/api/orders");Both helpers report network failures and non-success HTTP responses using the pipeline event contract while preserving the original fetch behavior. resource identifies the affected route or endpoint, while referrer identifies the previous page that led to the request. The current collector consumes PostgreSQL notifications; configure traceEndpoint to use a dedicated collector HTTP route when one becomes available.
- Fork repo
- Create branch
feature/<name>orfix/<name> - Implement changes and tests
- Run tests
- Submit PR with description and context
- Keep clean Python style (PEP 8)
- Document functions and modules
- Avoid hardcoded credentials
- Use existing layers:
core.async_libfor async logic,core.backendfor API
pip install black flake8
black .
flake8 srccd /home/ruben/Desktop/github_repos/3v3nTr4cer
source .venv/bin/activate
PYTHONPATH=src python -m unittest discover -s src/tests -vsrc/tests/test_collector.pyβ event validationsrc/tests/test_alert_manager.pyβ alert threshold and validationsrc/tests/test_integration.pyβ pipeline integrationsrc/tests/test_processor.pyβ processor validator wrappersrc/tests/test_async_manager.pyβ async queue managementsrc/tests/test_collector_async.pyβ async collector API/WebSocket handlingsrc/tests/test_processor_async.pyβ async processor handling
MIT License. See LICENSE.
.
βββ CONTRIBUTING.md
βββ examples
βΒ Β βββ fetch-trace.js
βΒ Β βββ fetch-trace.ts
βββ db
βΒ Β βββ commands
βΒ Β βββ init
βββ deploy
βΒ Β βββ compose.yml
βΒ Β βββ docker
βΒ Β βββ requirements.txt
βββ installer.sh
βββ LICENSE
βββ logs.txt
βββ README.md
βββ setup.sh
βββ src
βΒ Β βββ alert_engine
βΒ Β βββ collector
βΒ Β βββ contracts
βΒ Β βββ core
βΒ Β βββ processor
βΒ Β βββ tests
βββ systemd
βββ 3v3nTr4cer.service
βββ setup.sh
We now have a functional MVP. The next steps will focus on making it work independently and eventually developing multiple fully functional, "market-ready" products.
