Posted on August 10, 2026 by Uzochukwu Nweneary | LFX Mentee I joined the LFX mentorship expecting to spend three months writing documentation. A few weeks later, I was deploying OpenTelemetry Collectors across AWS EC2 instances, debugging networking problems between machines, and trying to understand why a pipeline that looked healthy wasn't sending metrics. I went from having zero knowledge about observability to building and troubleshooting systems. This made the LFX Mentorship one of the most effective and exciting learning experiences I've had in engineering. I was exposed to how systems behave in reality.
That difference is what makes it one of the most effective ways to grow into cloud-native engineering. A few months before joining the LFX mentorship, I was a Frontend Developer exploring backend engineering. My first encounter with observability was curiosity leading me to articles about traces and metrics. For years, I looked forward to contributing and joining an active Open Source community. So when I came across this mentorship with Prometheus on improving the documentation for Prometheus and OpenTelemetry Interoperability, I thought this was a perfect opportunity to contribute.
I expected my contributions to focus solely on improving or creating documentation for both tools. Documentation was part of the experience. I contributed to OpenTelemetry documentation, and my pull requests were merged. That gave me direct exposure to how large CNCF projects review, refine, and maintain technical documentation at scale, but that was only the surface. Before long, my work had expanded beyond documentation. To properly document real systems, I first had to understand them. This led me to deploy and troubleshoot the systems I was writing about.
The deployment I made during the mentorship looked like this: Every component introduced another opportunity for failure. Most failures were silent: missing metrics, broken pipelines, or unreachable services that still appeared “healthy. ” The hardest debugging experiences were not tied to a single tool like OpenTelemetry or Prometheus. They came from interactions between components. At some point, debugging stopped being about individual services and became about understanding system behavior. I wrote about one of those debugging experiences in more detail [ here ].