iam-veeramalla/observability-zero-to-hero

1. This repository is a 7-part observability tutorial, not a single product. Each day-* folder is a mostly self-contained lab that adds one layer of the observability stack on top of Kubernetes.

2. The architectural center of the repo is Kubernetes. Almost every day introduces manifests or Helm values that deploy components into a cluster, so the diagram should show Kubernetes as the hosting boundary for the apps and observability services.

3. Days 1–3 focus on metrics. The stack is Prometheus for collection/storage, Grafana for visualization, and kube-prometheus-stack-style installation/configuration for cluster-level monitoring. Day 3 adds PromQL as the query layer over Prometheus data.

4. Day 4 adds application instrumentation. There are two Node.js services, service-a and service-b, each containerized with a Dockerfile and deployed via Kubernetes manifests. They export custom metrics via prom-client, and the services are the primary telemetry sources in this stage.

5. The Day 4 application flow is service-to-service: service-a and service-b are deployed separately and exposed with their own Kubernetes Services. This is also where the repo introduces Alertmanager, so the metrics flow becomes: app metrics → Prometheus → alert rules → Alertmanager → email notification config.

6. Day 5 introduces logging. The repo contains a log pipeline built around Fluent Bit, with Kubernetes configuration for collecting container logs from the cluster and forwarding them to a log backend. The folder naming and README imply an EFK-style pattern, while the included manifests suggest an OpenSearch/Fluent Bit deployment variant.

7. Day 6 introduces distributed tracing with Jaeger. The architecture adds trace generation from instrumented services and sends traces to Jaeger, which becomes the trace storage and UI layer. This is a separate telemetry plane from metrics and logs, but still deployed in Kubernetes via Helm values.

8. Day 7 is the most integrated setup. It contains two Go microservices, microservice-a and microservice-b, plus OpenTelemetry Collector configuration, Prometheus config, and Jaeger values. This is the unified observability stage where one app emits metrics and traces through OpenTelemetry-enabled pipelines.

9. The Day 7 data flow is the key architecture pattern for the repo: Go services → OpenTelemetry instrumentation/Collector → backends such as Prometheus for metrics and Jaeger for traces. The repo also includes Kubernetes manifests for the services, showing the separation between workload deployment and telemetry pipeline deployment.

10. The opensearch-stack directory is a standalone logging subsystem. It contains a Fluent Bit DaemonSet, Fluent Bit config, and a log generator, so it should be shown as an independent log-ingestion path that can run alongside the other observability components.

11. Cross-cutting infrastructure includes Docker for packaging the sample services, Helm values for installing observability operators/components, and Kustomize-style manifests for assembling Kubernetes resources. The repo’s structure is therefore “lab modules + runtime manifests,” not a monolithic application codebase.

12. If you draw one overall diagram, the main boundaries are: sample workloads on one side, Kubernetes as the orchestration layer in the middle, and observability backends on the other side. The telemetry streams split into three paths: metrics to Prometheus/Grafana/Alertmanager, logs to Fluent Bit plus a log store/UI, and traces to Jaeger or an OpenTelemetry-backed trace pipeline.