README.md

# Lab 12: Tracing und Logging

In dem Ihnen zur Verfügung gestellten Cluster ist der sogeannte ELK-Stack (Elasticsearch + Kibana) vorbereitet. Genauer gesagt folgende Komponenten:

- [Elasticsearch](https://www.elastic.co/de/elasticsearch) Zeitreihendatenbank
- [FileBeat](https://www.elastic.co/de/beats/filebeat) Sammelt Logdaten des Kubernetes Clusters und laufender Pods und leitet diese an ES weiter.
- [APM](https://www.elastic.co/de/apm) Tracing und Monitoring Server
- [Kibana](https://www.elastic.co/de/kibana) Observability UI, um auf die so gesammelten Daten für Analysen zugreifen zu können.

Wir nutzen diesen Stack als Typrepräsentant, um das Tracing von verteilten Transaktionen in Service-Architekturen zu demonstrieren und die Möglichkeiten der Log-Konsolidierung zu veranschaulichen.

Der ELK-Stack hat den großen Vorteil, dass er aus einer Hand stammt ([Elastic](https://www.elastic.co)) und daher recht einfach und schnell mittels [Helm-Charts](https://github.com/elastic/helm-charts) in beliebigen Kubernetes Clustern installiert werden kann.

```Bash
# Nicht durch Sie in diesem Lab durchzuführen!!!
# Der Cluster ist bereits für Sie so vorbereitet.

> helm repo add elastic https://helm.elastic.co
> helm install elasticsearch elastic/elasticsearch
> helm install kibana elastic/kibana
> helm install filebeat elastic/filebeat
> helm install apm-server elastic/apm-server
```

Für die oben genannten Komponenten gibt es jedoch auch eine Vielzahl alternativer Produkte wie bspw. [Prometheus](https://prometheus.io), [Fluentd](https://www.fluentd.org), [Jaeger](https://www.jaegertracing.io)/[Zipkin](https://zipkin.io) oder [Grafana](https://grafana.com). Auch Managed Monitoring Services wie bspw. [Datadog](https://www.datadoghq.com) erfreuen sich zunehmender Beliebtheit. Ferner bieten insbesondere die kommerziellen Hyperscaler wie [AWS](https://aws.amazon.com/de), [Azure](https://azure.microsoft.com/de-de), [Google Cloud](https://cloud.google.com), etc. entsprechende Monitoring Lösungen (auch zum Zwecke der Kundenbindung) an, die daher häufig eng und tief mit den entsprechenden Infrastrukturen integriert sind (dafür dann jedoch auch entsprechendes Vendor Lock-In Potenzial mitbringen).

Die in diesem Lab veranschaulichten Prinzipien lassen sich dennoch auf alle oben genannten Produkte übertragen. Welcher Produktstack letztlich in konkreten Projekten eingesetzt wird, hängt oft entscheidend davon ab, welche Monitoring-Produkte bereits in Unternehmen für andere Projekte eingesetzt werden. Meist vermeidet man es mehrere Monitoring-Stacks parallel zu fahren. Aus diesem Lab kann daher keine Empfehlung für eines der genannenten Produkte abgeleitet werden. Die Wahl des ELK-Stacks erfolgte aus rein pragmatischen Gründen im Kontext dieses Moduls.

## Inhaltsverzeichnis
- [Lab 12: Tracing und Logging](#lab-12-tracing-und-logging)
  - [Inhaltsverzeichnis](#inhaltsverzeichnis)
  - [Vorbereitung](#vorbereitung)
  - [Übung 01: Instrumentieren von Microservices zum Zwecke des Tracings](#übung-01-instrumentieren-von-microservices-zum-zwecke-des-tracings)
  - [Übung 02: Propagieren von Traces zwischen Microservices](#übung-02-propagieren-von-traces-zwischen-microservices)
  - [Übung 03: Konsolidiertes Logging](#übung-03-konsolidiertes-logging)
  - [Links](#links)
  - [Was sollten Sie mitnehmen](#was-sollten-sie-mitnehmen)

## Vorbereitung

Sie benötigen auf Ihren lokalen Entwicklungsrechner:

- [Python 3](https://www.python.org/downloads)
- [Docker](https://www.docker.com/get-started)
- [Lens](https://k8slens.dev)
- [salvo](https://github.com/tarekziade/salvo) `python3 -m pip install salvo` *Sie können mit anderen HTTP Load Generatoren arbeiten. Diese Anleitung basiert jedoch auf `salvo`.*

Führen Sie anschließend bitte folgende Schritte aus:

1. [Forken](https://git.mylab.th-luebeck.de/cloud-native/lab-tracing/-/forks/new) Sie sich bitte dieses [Repository](https://git.mylab.th-luebeck.de/cloud-native/lab-tracing).
2. Erstellen Sie anschließend in Gitlab unter `Einstellungen -> Repository -> Bereitstellungstoken` für das in Schritt 1 geforkte Repository einen **Bereitstellungstoken**, um selbstgebaute Container Images deployen zu können.
   - **Name:** `Registry read access (deployment)`
   - **Username:** `image-registry` (bitte exakt so!)
   - **Scope:** `read-registry` (nicht mit *read repository* verwechseln!)
   - Klicken Sie anschließend auf `Bereitstellungstoken erstellen` und kopieren Sie sich dieses geheime Token in die Zwischenablage!
3. Hinterlegen Sie nun für Gitlab Build-Pipelines dieses geheime Token unter `Einstellungen -> CI/CD -> Variables` als CI/CD-Variable.
   - Klicken Sie auf `ADD Variable`
   - **Key:** `REGISTRY_READ_TOKEN` (exakt so)
   - **Value:** Fügen Sie hier das geheime Token (Schritt 2) aus der Zwischenablage ein.
   - **Type:** `Variable` (nichts anderes)
   - **Flags:** Selektieren Sie `Mask Variable` damit das geheime Token in Log-Dateien maskiert wird.
4. Setzen Sie bitte analog zu Schritt 3 die `KUBECONFIG` Variable in `Einstellungen -> CI/CD -> Variables` auf den Inhalt der Kubeconfig-Datei, die Sie für dieses Modul als Access Credential für den bereitgestellten Kubernetes Cluster erhalten haben (Type: `File`). Hierdurch erhält die Build Pipeline für das Deployment Zugriff auf den Cluster.

## Übung 01: Instrumentieren von Microservices zum Zwecke des Tracings

Die Deployment-Pipeline dieses Projekts ist so eingestellt, dass Ihnen eine Kibana Oberfläche in der `prepare`-Stage automatisch deployed wird. Kibana hat Zugriff auf den zentralen Elasticsearch Log- und Tracing-Store des Clusters.

Um Zugriff auf Kibana zu bekommen, geben Sie in einem Lens-Terminal folgendes ein:

```Bash
Terminal 1:> kubectl port-forward svc/kibana-kibana 55601:5601
```

Anschließend können Sie unter [http://localhost:55601](http://localhost:55601) die Kibana Oberfläche für dieses Lab einsehen.

![UI](Kibana-Observability.png)

**Halten Sie bitte das Terminal 1 für die gesamte Dauer des Labs offen!**

Die Instrumentierung mit APM ist extrem einfach und wesentlich komfortabler als bspw. mit [OpenTracing](https://opentracing.io/guides/python) o. ähnl. Bibliotheken, da APM viel Instrumentierung schon abnimmt, wenn es mit unterstützen [Webframeworks](https://www.elastic.co/guide/en/apm/agent/python/current/supported-technologies.html) eingesetzt wird.

Für [Flask](https://flask.palletsprojects.com) muss man bspw. nur die folgenden Zeilen nutzen, um das Flask `app`-Objekt mit einem Tracing Layer zu "umgeben". Dadurch werden bereits alle Requests an den Service getraced und auch automatisch Spans für ausgehende HTTP-Requests erzeugt.

```Python
app = Flask(__name__)
apm = ElasticAPM(app, service_name="my-service")
```

Den zu verwendenden APM Tracing Server können Sie dem Prozess mittels der Umgebungsvariable `ELASTIC_APM_SERVER_URL` mit geben. Das Service Deployment in `deploy/space-deploy+svc.yaml` ist bereits entsprechend vorbereitet. Der Tracing Server selber ist in der `.gitlab-ci.yml` Datei in der Umgebungsvariablen `TRACING_SERVER` hinterlegt.

1. Lesen Sie sich vorher etwas in die Instrumentierung mittels APM/Python/Flask in diesem [Tutorial](https://www.elastic.co/guide/en/apm/agent/python/current/flask-support.html) ein. Weitere Spans können mittels den Hinweisen zu [Instrumenting Custom Code](https://www.elastic.co/guide/en/apm/agent/python/current/instrumenting-custom-code.html) eingefügt werden.
2. Ergänzen Sie nun in der Datei `space/service.py` das Tracing mittels APM. Der `service_name` soll dabei aus der Umgebungsvariable `SERVICE` ausgelesen werden.
3. Committen und Pushen Sie Ihre Änderungen nun an Gitlab.
4. Warten Sie bis die Deployment Pipeline durchgelaufen ist. Und starten Sie dann in Gitlab den manuellen `space-svc`-Job (Play Button drücken) in der `deploy`-Stage.

Dies erzeugt den schon bekannten "Space-Service" aus den vorhergehenden Labs, der die ISS-Position und weitere Daten abfragt. Forwarden Sie nun den Service auf Ihren lokalen Rechner. Wenn der `space-svc`-Job durchgelaufen ist, öffnen Sie in Lens ein weiteres Terminal.

```Bash
Terminal 2:> kubectl port-forward svc/space-svc 58080:80
```

Halten Sie nun dieses Terminal für die Dauer dieser Übung offen und prüfen Sie, ob Sie JSON-Daten unter [http://localhost:58080](http://localhost:58080) erhalten. Sie sollten nun aktuelle People-, Passtime- und Position-Daten der ISS sehen.

Geben Sie nun etwas Last in das System. Öffnen Sie dazu ein drittes Terminal in Lens, um diesen Service nun 20-mal durch drei User abzufragen.

```Bash
Terminal 3:> salvo -c 3 -n 20 http://localhost:58080
```

Sehen Sie sich nun in [http://localhost:55601/app/apm](http://localhost:55601/app/apm) (Kibana) die Tracings an. Sie sollten Ihren Service (und ggf. weitere Tracings von anderen Kursteilnehmern und Cluster-Nutzern sehen).

- Wählen Sie den Zeitraum `letzte 15min aus`
- Klicken Sie auf den von Ihnen verantworteten Service im Format `space-<namespace>-svc`.
- Klicken Sie auf die Transaction `GET /space`. Sie sollten dann vermutlich eine Auswertung sehen, die so ähnlich wie diese hier aussieht.

![Space Tracing](kibana-space-tracings.png)

Spielen Sie nun gerne ein wenig mit Kibana herum. Sehen Sie sich die Statistiken und Auswertungen an, um ein Gefühl zu bekommen, was man mit Tracing so alles machen kann. Stellen Sie sich auch gerne einmal die folgenden Fragen:

__Verständnisfragen:__

- Wie unterscheiden sich die Spans am kurzen und am langen Ende der Latenz-Distrubtion?
- Woran könnte das liegen?
- Wie könnte man die Wartezeiten zwischen den Spans vermutlich reduzieren (vor allem am langen Ende)?
- Umwieviel Prozent ließe sich die Gesamtlatenz damit in etwa reduzieren?
- Könnte man die Gesamtlatenz noch anders reduzieren?
- Was hat mehr Effekt auf die Performance (Reduktion der Latenz) im vorliegenden Fall: Paralleles Absetzen der HTTP-Requests mittels asychronen Sprachmitteln (async/await)? Horizontales Upscaling der Pods?

> __Hinweis:__
> Wenn Sie gar nicht weiterkommen, können Sie mit
> `> cp/cheat/service-ue1.py space/service.py`
> ggf. etwas abkürzen.

Sie können nun den Forwarding Prozess in Terminal 2 löschen.

## Übung 02: Propagieren von Traces zwischen Microservices

Für diese Übung ist Ihnen einen "Hiphop"-Service gegeben, der Service Interaktion entlang von Aufrufketten von Services demonstrieren soll. Der Hiphop Service ist wie folgt aufgebaut.

```
 +----------+      +----------+      +----------+      +----------+
 | hh-svc-1 | ---> | hh-svc-2 | ---> | hh-svc-3 | ---> | hh-svc-4 |
 +----------+      +----------+      +----------+      +----------+
```

1. Bringen Sie diesen nun mit der Deployment Pipeline über den manuellen `hiphop-svc`-Job der `deploy`-Stage ausbringen können.
2. Starten Sie in Lens in einem 2. Terminal folgendes Port Forwarding:
   ```Bash
   Terminal 2:> kubectl port-forward svc/hiphop-svc 58888:80
   ```
3. Unter [http://localhost:58888](http://localhost:58888) sollte nun "Hip -> hop -> hop -> hop -> END" stehen.



![UI](Kibana-UI.png)

Wenn Sie auf `hiphop-svc-1` klicken, sollten Sie eine derartige Auswertung sehen. Insbesondere die Latency Distribution ist hier von Interesse, da Sie diese nutzen können, um die Verteilung von Latenzen in Ihren Requests zu sehen.

Vergleichen Sie doch einmal die Spans von Requests mit kurzen Latenzen mit den Spans von langen Latenzen.

- Was fällt Ihnen auf?
- Wie entstehen vermutlich die Wartezeiten?
- Was für Ideen haben Sie, diese Wartezeiten zu reduzieren?

![Tracing](Kibana-Tracing.png)

> __Hinweis:__
> Wenn Sie gar nicht weiterkommen, können Sie mit
> `> cp/cheat/service-ue2.py hiphop/service.py`
> ggf. etwas abkürzen.

## Übung 03: Konsolidiertes Logging


## Links

- [ELK Stack Helm-Charts](https://github.com/elastic/helm-charts)
- [Elasticsearch](https://www.elastic.co/de/elasticsearch)
- [FileBeat](https://www.elastic.co/de/beats/filebeat)
- [APM](https://www.elastic.co/de/apm)
- [APM Python Agent](https://www.elastic.co/guide/en/apm/agent/python/current/index.html)
- [Flask](https://flask.palletsprojects.com)
- [Kibana](https://www.elastic.co/de/kibana)
- [OpenTracing](https://opentracing.io)

## Was sollten Sie mitnehmen

- a
- b
- c