PgX – Debug Postgres performance in the context of your application code
1–10 of 12 posts
Re: PgX – Debug Postgres performance in the context of your application code
#2what does it do? the page doesn't even mention a product until near the end and then...doesn't explain?
Re: PgX – Debug Postgres performance in the context of your application code
#3> The engineer is forced into manual correlation: jumping between dashboards, aligning timelines by eye, [and] inferring causality from coincidence
I just generate a random UUID in the application and make sure to log it everywhere across the entire stack along with a timestamp.
Any old log aggregator can give me an accurate timeline grouped by request UUID across every backend component all in one dashboard.
It's the very first thing that I have the application do when handling a request. It's injected it at the log handler level. There's nothing to break and nothing to think about.
So, I have no problem knowing precise cause and effect with regard to all logs for a given isolated request, but I agree that there may be blips that affect multiple requests (outages, etc.). We have synthetic tests for outages though.
I too am struggling to understand what this tool does beyond grouping all logs by a unique request identifier.
Re: PgX – Debug Postgres performance in the context of your application code
#4what does it do? the page doesn't even mention a product until near the end and then...doesn't explain?
At this point I’m closing posts after skimming the subheadings that haven’t even been changed from obvious LLM output.
Re: PgX – Debug Postgres performance in the context of your application code
#5Looked for a way to install/actually set up something.
> Before configuring pgX, you need to set up PostgreSQL metrics collection:
Click the link.
> Prerequisites > PostgreSQL instance > Scout account and API credentials > Scout Collector installed and configured (see Quick Start)
Multiple clicks to find out I need a separate account somewhere (wth is scout?). That's gonna be a no from me dawg.
At least when places like Datadog do content marketing they provide ways to monitor the services using tools that don't require paying them money.
Re: PgX – Debug Postgres performance in the context of your application code
#6> The engineer is forced into manual correlation: jumping between dashboards, aligning timelines by eye, [and] inferring causality from coincidence I just generate a random UUID in the application and make sure to log it everywhere across the entire stack along with a timestamp. Any old log aggregator can give me an accurate timeline grouped by request UUID across every backend component all in one dashboard. It's th…
If you use OpenTelemetry, it basically does exactly that and you can send traces to some self-hosted FOSS visualizer, like Jaeger. You can also easily get the UUID of the spans/traces and have your logger automatically put them in every log message.
Re: PgX – Debug Postgres performance in the context of your application code
#7> The engineer is forced into manual correlation: jumping between dashboards, aligning timelines by eye, [and] inferring causality from coincidence I just generate a random UUID in the application and make sure to log it everywhere across the entire stack along with a timestamp. Any old log aggregator can give me an accurate timeline grouped by request UUID across every backend component all in one dashboard. It's th…
If you use OpenTelemetry, it basically does exactly that and you can send traces to some self-hosted FOSS visualizer, like Jaeger. You can also easily get the UUID of the spans/traces and have your logger automatically put them in every log message.
I have no doubt there are many tools, but I specifically mentioned my solution because it doesn't require any tools at all and just a matter of log hygiene.
They spend the whole page talking about a scenario that I've only seen happen in production when there were no app devs involved and people are allergic to writing a log format string let alone a single line of code.
Re: PgX – Debug Postgres performance in the context of your application code
#8There is a popular postgres client for Go called pgx. This naming will likely sow confusion
Re: PgX – Debug Postgres performance in the context of your application code
#9Looked for a way to install/actually set up something. > Before configuring pgX, you need to set up PostgreSQL metrics collection: Click the link. > Prerequisites > PostgreSQL instance > Scout account and API credentials > Scout Collector installed and configured (see Quick Start) Multiple clicks to find out I need a separate account somewhere (wth is scout?). That's gonna be a no from me dawg. At least when places l…
> wth is scout?
This is a feature of an observability product called Scout. It's not a standalone tool.
Re: PgX – Debug Postgres performance in the context of your application code
#10what does it do? the page doesn't even mention a product until near the end and then...doesn't explain?
founder at base14 here, the company that is building Scout. Thanks for the feedback, I will work on bettering my messaging.
Scout is an otel-native observability platform (data lake, UI, alerts, analytics, mcp, the works). We are building some specialised explorers (suffix 'X' for explorers) like pgX for postgres. Essentially we are building telemetry readers for components that send relevant metrics and logs through to a telemetry data lake. for each component/domain we find from experts what they look at for analysis and incidents, and bring that to a full stack "unified" dashboard. and we go beyond what a regular prometheus endpoint provides. thanks again.