4 ms·
I would love to see PostgreSQL integrate with something like Jaeger, specifically to have spans for triggers. Database triggers are terrible to introspect and d
by candiddevmike 6y ago
I would love to see PostgreSQL integrate with something like Jaeger, specifically to have spans for triggers. Database triggers are terrible to introspect and debug.
- brunoqc 6y agoDid you check https://github.com/open-telemetry/opentelemetry-js-contrib/tree/master/examples/postgres https://github.com/open-telemetry/opentelemetry-js-contrib/t... ? I'm not sure if it's the only one but opentelemetry.io does list PostgreSQL.
- candiddevmike 6y agoCorrect me if I'm wrong, but this just seems like using the opentelemetry library in node to send query info in a span. This doesn't seem like a full PostgreSQL integration?
- brunoqc 6y agoYeah it looks like it runs on the client side right? While I was expecting a proper plugin running on the postgresql side.
- sargun 6y agoWhy would you need any "server side" logic in PG?
- majewsky 6y agoThey want to trace the goings-on inside PG, e.g. if you have a query that runs in 3 seconds and joins five different tables, it might be interesting to see information like "spent 0.467 seconds joining table B and F". Like what EXPLAIN ANALYZE does, but live.
- awinter-py 6y agoyeah -- I wonder how DBs will change over the next few years. Their performance advantage is partially code quality, but partially that they can run complex searches 'close to the data'. You could do the latter with a stateful REST server too, and it would support a lot of modern tooling.
- sargun 6y agoI added integration for Zipkin in via Opencensus some time ago into a project I work on. This has been running in production for a while now: https://github.com/Netflix/titus-executor/tree/master/vpc/service/db/wrapper https://github.com/Netflix/titus-executor/tree/master/vpc/se... You need to: 1. Have an Opencensus tracing context 2. Have query logging setup on your PG server. There are a bunch of ways to do this with minimal overhead. You can log slow queries (say queries >5ms), or log queries that fail, or sample queries. Your query / log ends up getting something like: 2020-11-11 21:00:00 UTC:titusvpcservice@titusvpcservice: [60294]:HINT: The transaction might succeed if retried. 2020-11-11 21:00:00 UTC:titusvpcservice@titusvpcservice: [60294]:STATEMENT: /* md: {"spanID":"34c1a9f38fb44cad"} */ INSERT INTO assignments(branch_eni_association, assignment_id) VALUES ($1, $2) RETURNING id You can then look at a Zipkin, and use the value within MD (spanID) to get the trace. I did this originally, because I wanted to transparently wrap the PG SQL Driver for Zipkin. Postgres can be oblivious to the fact there's "Zipkin Inside", because it's a terminal node. You can get the span ID from the BEGIN TRANSACTION / first query, and then tie that to the pid and timestamp, and then use that to go back and look through things with standard(ish) postgres introspection, since almost all of it has the pg_backend_pid + timestamp in it.
- anarazel 6y agoHave you considered to add the span ID to the application name instead? Combined with including the application name in the log_line_prefix that will make the logs easier to inspect in quite a few cases. Also makes querying pg_stat_activity etc easier, since you can see the current application_name for each connection in there.