this is the library we use to configure otel: https://github.com/jzelinskie/cobrautil/blob/main/otel.go#L107-L116 the grpc client by default assumes TLS is enabled. I don't think any of the other options make that assumption, so I think we should probably set

WithInsecure

there (and then separately we need to support config for configuring TLS to the collector) another option that should work without any changes to spicedb would be to ensure that the collector is serving TLS that is trusted by the system pool in the spicedb pod (i.e. by mounting the cert into the spicedb image in the right location)

hm, since I can configure the receiver pretty freely, would it be easier to configure jaeger or similar?

I don't think TLS makes a ton of sense for a sidecar

yep the other options should work without tls

agreed

https://github.com/jzelinskie/cobrautil/pull/12 went ahead and made this to discuss where we want to go

@ecordell great!

I'm now hitting the next roadbump, what is the expected format for the jaeger endpoint?

2022/05/03 14:29:21 Post "localhost:14250": unsupported protocol scheme "localhost"

does not compute 🙂

http://localhost:14250/api/traces

I think you want something like this

ok, even if I configured it for grpc?

oh hm, you might hit the same issue if you do jaeger over grpc

Is oltphttp without TLS?

I believe so, but jeager over http should work

also the options are thrift and http for jeager from what I can see here: https://pkg.go.dev/go.opentelemetry.io/otel/exporters/jaeger

and the otel library spicedb uses only configures jeager for http

Yes, the following I can collect: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/jaegerreceiver

it works fine! thank you

jaeger over http also works!

on another note, SpiceDB postgres provider seems to log a ton of things like

"level":"info","module":"pgx","args":[...],"commandTag":"SU5TRVJUIDAgNA==","pid":24135,"sql":"INSERT INTO relation_tuple (namespace,object_id,relation,userset_namespace,userset_object_id,userset_relation,created_transaction) VALUES ($1,$2,$3,$4,$5,$6,$7),($8,$9,$10,$11,$12,$13,$14),($15,$16,$17,$18,$19,$20,$21),($22,$23,$24,$25,$26,$27,$28)","time":4.190728,"time":"2022-05-03T14:41:40Z","message":"Exec"}

, is there a way to quiet it down?

or is that intentionally at level

info

?

👆 this is also what I had in mind when I mentioned the logs being very verbose a few days ago. I set

LOG_LEVEL=warn

, but I'd rather not have to!

yeah as william said, log verbosity is something we're open to feedback on and could improve the

pgx

specific ones are logged at that level by the pgx library; we may just need to offer knobs to turn off pgx logging if we can't adjust the level it logs at

ok, thx. My two cents: Logs that scale with the number of requests should probably not be on level

info

😉

there's definitely competing thoughts on that, webservers like nginx and apache definitely log all requests at their default log level, but apache was written before the web got to its current scale, and nginx probably copied that decision for compatibility reasons

I'm fine to have exactly one log per request, but as it is now it's a ton 😉

hey! I'm looking to replicate the expected relations tab from the playground with grpc calls, is it just backed by ReadRelations?

hey I m looking to replicate the

following up on the pgx logs: as far as I can tell the queries are not part of the traces though. Is this intentional? That's where I would expect them.

I doubt it's intentional, we're not very mature when it comes to tracing, if you want to open a PR to add the things you would expect, it would be welcome

i'm a little bit worried about the performance of sending so much data over the tracing interface, but we can work to pre-filter or make some attributes optional if it becomes a problem