Flask and SQLAlchemy Telemetry: from boundary to verified row
Use Flask and SQLAlchemy Telemetry at a controlled application boundary, keep the event contract small, and verify a known outcome before building aggregate views.
- 1
Choose the outcome
Flask API reliability
- 2
Define the contract
request_id, endpoint, route_template, method, and status_code
- 3
Instrument the boundary
Use Flask's matched url_rule instead of request.path so identifiers do not create cardinality or privacy problems.
- 4
Verify the evidence
Exercise a known fixture, then inspect api_request_completed for one correctly typed terminal row.
Before you start
Prerequisites and boundaries
- telemetry-sh initialized once in each Flask worker process
- A stable Flask endpoint taxonomy and monotonic request timer
- SQLAlchemy event listeners limited to counts, durations, and safe operation metadata
Delivery setup
Install and initialize server-side
Initialize Telemetry for synchronous code or TelemetryAsync for asyncio code once per process with a server-side key. Keep ingestion credentials out of browser bundles, client-visible environment variables, source control, logs, and exception messages.
pip installation
python -m pip install telemetry-sh- 1Prepare one reusable server-side delivery client with bounded network behavior.
- 2Add the outcome event at the success, failure, retry, or timeout boundary.
- 3Send controlled fixtures and inspect the stored rows before enabling an alert.
Snippet
Start with one structured event
Add this shape where the workflow completes, fails, or retries. Then build the dashboard from real fields.
Flask and SQLAlchemy Telemetry event
from flask import g, request
from time import monotonic
@app.before_request
def start_request_timer():
g.request_started_at = monotonic()
g.db_query_count = 0
@app.after_request
def record_request_outcome(response):
route = request.url_rule.rule if request.url_rule else "unmatched"
telemetry.log("api_request_completed", {
"request_id": request.headers.get("X-Request-ID"),
"endpoint": request.endpoint or "unmatched",
"route_template": route,
"method": request.method,
"status_code": response.status_code,
"status": "failed" if response.status_code >= 500 else "success",
"latency_ms": round((monotonic() - g.request_started_at) * 1000),
"db_query_count": g.db_query_count,
"release": app.config.get("APP_RELEASE"),
})
return responseEvent contract
request_id, endpoint, route_template, method, and status_code
status, latency_ms, db_query_count, rollback_count, and error_type
service, environment, release, and approved tenant context
Implementation checkpoints
Checkpoint 1
Use Flask's matched url_rule instead of request.path so identifiers do not create cardinality or privacy problems.
Checkpoint 2
Store per-request counters in flask.g and update them from reviewed SQLAlchemy hooks; never send SQL text, bound parameters, connection strings, or ORM objects.
Checkpoint 3
A teardown exception can occur after a response is constructed, so model request outcome and transaction rollback as distinct events when both questions matter.
Verification
Prove the event arrived
Run this after exercising known success and failure cases. Replace the fallback table name if your final event contract differs from the snippet.
Flask and SQLAlchemy Telemetry verification query
SELECT *
FROM api_request_completed
ORDER BY timestamp_utc DESC
LIMIT 20;Implementation references
Review the event contract, data-safety guidance, and upstream primary documentation before enabling a new production path.
Production boundary
Keep the outcome event small and recoverable
This pattern provides
- A bounded, SQL-ready outcome beside the upstream workflow.
- Stable fields for dashboards, alerts, and cross-event correlation.
- A fixture-driven path for validating success, failure, retry, and timeout behavior.
This pattern does not provide
- An OTLP exporter, automatic collection pipeline, or replacement for detailed traces and diagnostic logs.
- Exactly-once delivery merely because the payload contains an event ID.
- Permission to collect raw provider payloads, user content, credentials, or regulated data.
Event schema starting points
Event contracts for this workflow
Review the row grain, emit boundary, required types, privacy classes, example payload, and validation checklist before adapting a query or snippet to production.
Related product capability
Continue this workflow in Alerts
Promote the reviewed reliability query into an owned threshold and response workflow.
Related SQL recipes
Answer the next question with SQL
Run the query against the structured fields from this workflow, inspect the example result, and turn a useful answer into a dashboard or alert.
Calculate API Error Rate by Route
Which API routes have the highest meaningful 5xx error rate?
Open recipeCalculate p50, p95, and p99 API Latency
Which endpoints have the worst tail latency?
Open recipeFind Slow Database Queries by Fingerprint
Which database operations are consistently slow enough to investigate?
Open recipeCalculate Database Transaction Rollback Rate
Which services roll back an unusual share of database transactions?
Open recipeRank Database Queries by Total Time Impact
Which database operation consumes the most cumulative request time?
Open recipeBrowse by implementation family
Compare related integration patterns
Templates to pair with this integration
Database Reliability Monitoring Template
Instrument slow operation fingerprints, pool contention, transaction rollbacks, locks, replication lag, and migration outcomes with safe structured events.
Open templateAPI Error And Latency Monitor
Watch request volume, status codes, route latency, failed endpoints, and customer-impacting API incidents.
Open templateMore integrations
MongoDB Operation Telemetry
Track named MongoDB operations, latency, result counts, retries, transaction outcomes, and release regressions without collecting documents or query values.
Open guideMySQL Query and Pool Telemetry
Track normalized MySQL operations, pool wait, transaction outcomes, controlled error categories, and release regressions without storing raw SQL or parameters.
Open guidePrisma ORM Database Telemetry
Measure Prisma operation fingerprints, model and method latency, failures, result counts, releases, and database-dependent workflows without collecting raw query parameters.
Open guide