iam-veeramalla/observability-zero-to-hero: a 7-day Kubernetes observability course in Go and YAML

What the 7-day series actually covers, and who should follow it

The repository is a teaching sequence, not a tool. Its README describes a "7-Day Observability Tutorial Series" whose stated purpose is setting up and understanding observability in Kubernetes using Prometheus, Grafana, Elasticsearch Fluentbit, Kibana, Jaeger, groundcover(eBPF) and opentelemetry. Each day is a folder in the repository root, and the folder names (day-1/ through day-7/) match the days in the README outline, so the syllabus and the code sit side by side.

The intended reader is an engineer who already has a Kubernetes cluster and wants to wire up the standard open source observability stack in order. Day 1 is conceptual: observability versus monitoring, the tool categories, and how the problem differs between bare-metal servers and Kubernetes. Days 2 and 3 are metrics, first installing Prometheus and Grafana through kube-prometheus-stack with Helm, then learning PromQL aggregation and functions. Day 4 turns to instrumentation, covering Counter, Gauge, Histogram and Summary metric types, custom metrics in a Node.js application through the prom-client library, Dockerizing that application, and Alertmanager rules on top of the custom metrics. Day 5 is the EFK stack for logs. Day 6 is Jaeger for distributed tracing. Day 7 is OpenTelemetry as the unifying layer, with a Golang microservice as the worked example.

That ordering is the strongest design decision here. Most engineers meet these tools as separate tutorials with separate assumptions about cluster state, and the result is three half-installed stacks. This repository sequences them and, per the README, includes cleanup steps after the EFK and Jaeger days. The Go language tag on the repository comes from the day-7 microservice rather than from any library code you would import.

How the day folders and the opensearch-stack directory fit together

The mechanism is deliberately plain: one directory per day, each holding the manifests, Helm values and application code for that day's exercise. There is no shared framework, no build system that ties the days together, and no library to depend on. You read the README outline, open the matching folder, and apply what is inside to a cluster.

The README's day descriptions name the concrete artifacts you should expect. Day 2 covers installation of kube-prometheus-stack with Helm and its integration with Grafana. Day 4 names the prom-client library for Node.js and mentions Dockerizing the application before deploying it to Kubernetes. Day 6 covers setting up Jaeger in a Kubernetes cluster using Helm and instrumenting services with OpenTelemetry so traces appear in the Jaeger UI. Day 7 covers the OpenTelemetry Collector alongside Prometheus, Jaeger and Elasticsearch to monitor a Golang microservice.

The opensearch-stack/ directory sits outside the numbered days. The README does not describe it in the day-by-day outline, so its exact role is not documented in the available files. Given the name, it is most plausibly a variant of the logging day built on OpenSearch instead of Elasticsearch, but that is an inference from the directory name and not something the README states. Treat it as an extra and read its contents directly before assuming it maps to day 5.

The data flow across the week is the standard one. Applications expose metrics on an HTTP endpoint, Prometheus scrapes them, Grafana queries Prometheus, Fluentbit ships container logs into Elasticsearch for Kibana to display, services emit spans that Jaeger stores and renders, and OpenTelemetry provides the instrumentation and collector layer that can feed several of those backends at once. The repository is a set of working configurations for that flow, not an abstraction over it.

Installing the stack and running a first Prometheus query

There is no package to install. You clone the repository and work through the day folders against a Kubernetes cluster, and the README gives no separate installation instructions beyond that structure. Because the metrics days target an EKS cluster in the README wording, confirm your kubeconfig points at the cluster you intend to modify before applying anything.

The day-2 exercise is the natural first stop. It installs kube-prometheus-stack with Helm and integrates it with Grafana. The README does not publish the exact Helm values, so read the files inside day-2/ for the release name, namespace and chart version used there before running anything. The README states that Prometheus is installed on Kubernetes with Helm, but it does not reproduce the commands, so the exact flags and release names have to come from the day-2/ files rather than from this article.

After the release settles, check that the pods in the monitoring namespace reach a running state. What you should see is a Prometheus server, a Grafana deployment and the operator components that kube-prometheus-stack ships, which is the baseline the rest of the week builds on.

Day 3 is where you actually query. The day-3 folder covers PromQL and basic querying techniques plus aggregation and functions to analyze metrics data. Open the Prometheus expression browser and start with a simple metric name to confirm scraping works, then move to the aggregation and function examples the folder covers. If a metric returns no series, the scrape target is the thing to inspect first, not the query. The README does not document a rollback procedure for the Helm release, so if you are installing into a shared cluster, plan the uninstall step yourself before you start.

Where this repository stops being the right tool

The clearest limitation is scope. Every day in the README outline is framed around Kubernetes, and the comparison in day 1 is explicitly between bare-metal servers and Kubernetes rather than a general treatment of observability. If your workloads run on virtual machines, on serverless platforms, or in a managed observability product, most of the manifests here will not transfer and you will be reading the concepts and skipping the code.

The second limitation is that this is a tutorial repository with no releases. It is not versioned for consumption, so there is no tagged artifact to pin against and no changelog to consult when a chart or CRD changes upstream. The Helm charts it installs, kube-prometheus-stack among them, move independently of this repository, which means instructions that worked when a day was written can drift as the charts evolve. The README does not state which chart versions were used, so you cannot tell from the outline alone whether a given day still matches current upstream defaults.

The third is the licence. The repository metadata does not declare one. That matters less for reading the explanations and more if you intend to copy the manifests or the day-7 Go service into your own codebase, because without a declared licence you have no stated grant to redistribute. The README is silent on this, and it is worth resolving before you lift code rather than after.

Finally, the repository is a course, so it optimizes for a linear path through seven topics. It does not cover operating any of these stacks over time: retention, cardinality control, cost, upgrade procedures, or what happens when Elasticsearch fills a node. Those are the questions that arrive in week three, and the files do not address them.

How it compares with the official quickstarts and with a course platform

The obvious alternative is the upstream documentation for each component: the Prometheus and Grafana docs, the OpenTelemetry documentation, and the Helm chart READMEs. The difference in approach is real. Upstream docs are authoritative and current for one tool at a time, and they assume you already know why you are installing that tool. This repository assumes the opposite: it supplies the why first, in day 1, and then a specific ordered path through five tools. What you give up is currency and depth per tool; what you get is a sequence and a working example application tying the pieces together.

A second alternative is a hosted training platform or video course covering the same stack. Those typically provide a managed lab environment, so you never fight cluster state, and they usually come with support and updates. This repository gives you the manifests and Helm commands to run against your own cluster, which is closer to the production experience and worse for a first attempt, since any mistake in cluster setup is yours to debug. The related searches around this project include "Kubernetes zero to hero youtube" and "Abhishek youtube", which suggests video material is the companion people pair with the written days. If you learn better from a walkthrough, that pairing is the intended one.

A third comparison is the day-5 logging stack against the opensearch-stack/ directory. If you are choosing between Elasticsearch and OpenSearch for the logging layer, the repository appears to contain material for both, but the README only documents the EFK path. The OpenSearch variant is undocumented in the outline, so it is not a like-for-like alternative you can evaluate from the README alone.

Maintenance, upgrades and what the licence does not say

The repository is not archived, and the last push was on 2026-06-26. That is recent enough that the day folders are unlikely to have rotted badly, but it is a tutorial repository, so a push may be a new explanation or a corrected manifest rather than a maintenance commitment. There are no releases, which means there is no upgrade path to follow: you pull the latest commit on main and read the diff.

The upgrade cost that matters is not in this repository, it is in what it installs. kube-prometheus-stack, the EFK components, Jaeger and the OpenTelemetry Collector all version independently. When you return to a day folder months later, the Helm commands may need chart versions pinned, and CRDs from the Prometheus operator in particular tend to require attention across chart majors. The README does not document rollback for any of the Helm releases, so the safe pattern is to install into a namespace you are willing to delete and to record the chart versions you used.

On licensing, the repository metadata does not declare a licence, and the README does not mention one. That is a gap rather than a restriction you can reason about. Reading the tutorials and running them locally raises no question the files can answer; copying the day-7 Go service or the manifests into a product is a different matter, and the absence of a licence file means there is no stated permission to rely on. This is not legal advice, and if you need to redistribute the code, the licence question is the first thing to resolve with the repository owner.

Editorial conclusion

Adopt this repository if you already run Kubernetes and want a guided sequence through Prometheus, EFK, Jaeger and OpenTelemetry rather than a pile of unrelated quickstarts. Skip it if you need a maintained library, an installable package, or a course that covers bare-metal and VM observability, because the README scopes everything to Kubernetes and the repository ships no releases. Before you start, check the day-7/ and opensearch-stack/ directories to confirm the manifests match your cluster version, and confirm the licence, since the repository metadata does not declare one.

Frequently asked questions

Official sources

1. iam-veeramalla/observability-zero-to-hero on GitHub
2. Issues
3. README