2.1.1 X-Ray Subsegment Trial
What types of data would you include in your spans for tracing and observability? I tried to send the name of the current git branch which will change over the coming weeks of Cruddur development.
Last updated
What types of data would you include in your spans for tracing and observability? I tried to send the name of the current git branch which will change over the coming weeks of Cruddur development.
Last updated
Video: personal micro-project branching out of the original Cruddur
Andrew's repo
My branch repo: 02-01-01-xray-subsegment-trial
The below code is what I got from my dear friend ChatGPT. I'm so happy to chat with ChatGPT because it never gets mad at me for having infinite questions
line 1: the subprocess module allows you to spawn new processes, connect to their input/output/error pipes, and obtain their return codes.
Meaning, I can run bash script using Python and store the return value in a Python variable!
line 5: the function subprocess.run
runs terminal commands.
git rev-parse --abbrev-ref HEAD
: this command grabs the name of the current branch.
As this is a bash command, it returns the branch name only as a string:
02-01-01-xray-subsegment-trial
line 8: however, we are grabbing the current branch name in bash using python, so we need some string processing.
The codes for these tasks don't work and isn't important for the discussion. You can still look here:
Honeycomb and X-Ray in:
I tried customising the Honeycomb span by adding a new attribute app.branch
. This attribute would have the name of the current git branch.
In my mind, as I will move through the weeks, I will continue to create more branches, and the value of the app.branch
will be dynamically updated!
So it would be really cool to have spans coming in on Honeycomb which clearly marks which phases of the development they were captured at.
However, it failed because the backend is containerised. This means that the backend-container has to:
have git
installed
should be in sync with this repository all the time.
Generally speaking, docker containers used in development and production should never be the same. Dev containers usually contain many more dependencies than prod containers for troubleshooting and testing purposes.
Speaking of which, installing git in the prod container would be a bad idea, as it can become a security vulnerability. In order to identify the branch name, Git has to be in sync with the remote repo. Furthermore, I'll have to provide a Git credential.
Even for a dev container, this seems to be a waste of compute power. Packge Git, include my Git credentials as env variables in the docker container... (why would you install a tool that can control the versions of your production source code, even if the Github credential you are providing doesn't have permissions to change the repo?)
It is too costly for an experiment and it will never be adopted in the prod container down the road. Sso I discarded the idea.
I also failed sending segments and subsegments to X-Ray
. It does not pick up the subsegments. I might as well retry this after completing the episode "X-Ray Subsegments Solved"
So this trial ended up being more of a thought experiment than coding. However, it still was a valuable experience. As the docker dev and prod containerisation, we will learn more about this consideration again in the coming weeks.
Python: subprocess