This is not specific to open telemetry collector but overall in terms of distributed tracing, due to the nature of things it is getting extremely complicated. Especially in the Kubernetes context.
Another remark is that blog posts and tutorials include configuration not recommended for prod usage. ( in this case grpc SSL insecure option ) These quickly become foot-guns living in production
Moreover, due to the nature of go applications' static compilation mindset each component include various plugins hence their configuration quickly becoming a large file nobody except DevOps understands or configures.
Obviously original documentation is sufficient and explains well enough but nobody reads these fully. I have came across multiple times that engineers “made it work” using external service names and whatnot. Soon enough the production may hit by increasingly high response times due to both infrastructure level and tracing level misconfigurations.
I went a bit off topic and ranting here but open telemetry is a quite large piece thus should be taken carefully while implementing on a live platform.
Another remark is that blog posts and tutorials include configuration not recommended for prod usage. ( in this case grpc SSL insecure option ) These quickly become foot-guns living in production
Moreover, due to the nature of go applications' static compilation mindset each component include various plugins hence their configuration quickly becoming a large file nobody except DevOps understands or configures.
Obviously original documentation is sufficient and explains well enough but nobody reads these fully. I have came across multiple times that engineers “made it work” using external service names and whatnot. Soon enough the production may hit by increasingly high response times due to both infrastructure level and tracing level misconfigurations.
I went a bit off topic and ranting here but open telemetry is a quite large piece thus should be taken carefully while implementing on a live platform.