chore(sync-service): Expand the set of OT span attributes assigned in ServeShapePlug

[alco]

Part of #1664.

@KyleAMathews WIP so far:

[netlify]

✅ Deploy Preview for electric-next ready!

Name	Link
🔨 Latest commit	a85d8d2
🔍 Latest deploy log	https://app.netlify.com/sites/electric-next/deploys/66fd022755dd240008a9f82c
😎 Deploy Preview	https://deploy-preview-1736--electric-next.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[KyleAMathews]

Looks great!

[alco]

@KyleAMathews Just pushed new changes that largely implement the ideas described in #1664.

The name of the root span for shape requests is now ShapeGet:

Grouping by shape_req.is_cached:

Serving a largish initial snapshot or 2000 linearlite issues:

Bits that are still no there:

• propagating tracing context on the write path, all the way from Postgres to individual shape logs
• recording exceptions in ShapeGet processing as errors in the OT span (can be done by using Plug.ErrorHandler)
• estimating shape size and assigning it as an attribute to tracing spans. This is doable by keeping track of how much data has been streamed to the client and then setting that as a dynamic attr on the span.

[KyleAMathews]

• is ShapeGet.load_shape_data when we run the actual SQL query? It'd be nice to have it clear what's the query. Also adding the query as an attribute would be great too.
• ShapeGet is camel case while all the sub-spans are snake case — perhaps just do shape_get as well?

Nice progress!

[alco]

• is ShapeGet.load_shape_data when we run the actual SQL query? It'd be nice to have it clear what's the query. Also adding the query as an attribute would be great too.

You're probably referring to load_shape_info. This span covers the "get_or_create_shape_id" function, so it's going to be cached data after the shape is first created. It makes sense to only trace the shape creation bit. I'll try adding the SQL query to that.

• ShapeGet is camel case while all the sub-spans are snake case — perhaps just do shape_get as well?

Naming convention can be anything we like here. I kinda like the way the root span's name stands out. Also makes it easy to see when a non-root span shows up as a root one in Honeycomb because of incorrect context tracking in the code.

So I would make all root spans use CamelCase. But we could use some other convention to keep everything snake case, e.g. _shape_get or R_shape_get for the root span.

[KyleAMathews]

I kinda like the way the root span's name stands out

Hmm yeah interesting point. I don't feel that strongly about specifics of the conventions — just that we're consistent.

[robacourt]

Great work!