Idea for discussion - would people find it valuable to know which docker container holds the logs for errors that pop up? I know I am sometimes doing a lot of guesswork as to where to track down a stack trace when the UI shows a short error message and no details. I discovered that from inside a running docker container, we can obtain the hash form of that container id, with the following:

cat /proc/self/cgroup | head -1 | cut -d'/' -f3

So theoretically it would be possible to tell the running app which container it’s in (via an env var or something) so that it could report that information with any exceptions, and we could pass that up to the UI for a More Details display or somesuch. This might have some value as horizontal scale-out happens, too — sometimes a particular node gets corrupted and it’s helpful to know which node in a cluster is spitting out the errors. My primary goal, though, is just to make it easier on ops and developers to discover the underlying stack trace when something breaks anywhere. Thoughts?

Thread for discussion.

I’d prefer to keep logic like that outside of the connector. Feels like a better abstraction since we can’t enforce 3rd party containers to add this functionality even though it’s useful. I think the easiest thing would be to do the pattern we have in kubernetes. We name the pod and log that name so it’s possible to debug and access. We can do this for docker as well if we add a

--name

option to the process’s cmd in

DockerProcessFactory

have it log that value. Even something simple like

airbyte-randomalphanumeric

would help here.

Yeah that sounds helpful. Would that let us optionally expose the identity through the web app, when errors are shown to the user? I don’t just mean job-run errors. I also mean things like connection checks and other supplementary behaviors. Even though the error is presented via the UI, if I’m not going to find its logs in airbyte-webapp, I’d like it to tell me where else to look (especially from the devops perspective at a customer site, rather than our own dev team).

Ah. I missed that.

I think we’d do it the same way, but we’d need to expose that upwards to the UI. We might want to make it work differently for OSS and cloud since cloud users won’t be able to access the specific pod or image.