Kong API-Gateway – Observability mit Prometheus, Grafana und OpsGenie

Keine Kommentare

Im vorherigen Blogpost habe ich das bestehende Demo-Setup um decK und Konga erweitert. Nun soll es darum gehen, die vorhandenen Daten der APIs sichtbarer werden zu lassen. Hierzu möchte ich zwei Observability Patterns, nämlich Monitoring und Alerting, in Verbindung mit einem API-Gateway, im Speziellen Kong, betrachten. Doch was bedeutet eigentlich Observability?

Observability

Der Begriff Observability stammt ursprünglich aus der mathematischen Kontrolltheorie und ist eine Messgröße, die Rückschlüsse auf den inneren Zustand eines Systems zulassen soll. Geprägt wurde dieser Begriff von Robert E. Kalman. Dies kann auch auf Applikationen als Systeme übertragen werden. Im Folgenden wird das API-Gateway die Rolle eines zu beobachteten Systems einnehmen. Um nun die entsprechenden Patterns anwenden zu können, werde ich auf die darauffolgenden Tools zurückgreifen und diese jeweils kurz erläutern.

Monitoring

Beim Monitoring befassen wir uns mit der Überwachung von Metriken, was in unserem Fall die Güte einer Verbindung bei Verwendung einer bestimmten Route meint. Diese Metriken erfassen wir mittels Prometheus und eines entsprechenden Kong-Plug-ins (https://docs.konghq.com/hub/kong-inc/prometheus/). Das Plug-in wird am Service mithilfe von decK eingerichtet. Dazu wird unter plugins: die YAML-Datei um folgende Einträge erweitert.

- name: prometheus
    enabled: true
    run_on: first
    protocols:
    - grpc
    - grpcs
    - http
    - https

Prometheus

Um Prometheus starten zu können, muss es noch zur docker-compose-Datei hinzugefügt werden.

prometheus:
    image: prom/prometheus
    container_name: prometheus
    restart: always
    volumes: 
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    command: "--config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/prometheus"
    ports: 
      - 9090:9090

Es muss eine Konfiguration mittels prometheus.yml erstellt werden.

global:
  scrape_interval:      15s
  evaluation_interval:  15s

scrape_configs:
  - job_name: 'prometheus' 
    metrics_path: /metrics
    honor_labels: false
    honor_timestamps: true
    sample_limit: 0
    static_configs:
      - targets: ['localhost:9090','host.docker.internal:8001']

Nach dem Aufruf von „docker-compose up“ startet Prometheus und steht unter http://localhost:9090 zur Verfügung. Da die Oberfläche sehr spartanisch ist und sich hauptsächlich für schnelle Abfragen und Debugging eignet, kommt ein weiteres Tool ins Spiel, Grafana.

Grafana

Wie Prometheus ist auch Grafana ein Open-Source Produkt. Grafana versetzt den User in die Lage, Dashboards für das Monitoring von Systemen zu erstellen.

Hierzu füge ich Grafana ebenfalls zur vorhandenen docker-compose-Datei hinzu.

grafana:
    image: grafana/grafana
    container_name: grafana
    restart: always
    volumes: 
      - ./grafana/provisioning/:/etc/grafana/provisioning
    ports:
      - 3000:3000

Im Unterordner grafana/provisioningbefinden sich die Konfiguration für die möglichen vorgefertigten Dashboards und Datasources. Für Kong greife ich auf das offizielle Grafana Dashboard von Kong zurück. Dieses ist auch im Unterordner hinterlegt.

Mit docker-compose upstarte ich Grafana und es steht unter http://localhost:3000 im Anschluss zur Verfügung. Nach der Anmeldung mittels admin:administ der Aufruf des Dashboards „Kong (official)“ möglich.

Alerting

Zu diesem Zeitpunkt ist eine Monitoring-Lösung für das API-Gateway integriert. Was noch fehlt, sind Hinweise und Warnungen, wenn das Gateway vorher vereinbarte Schwellenwerte erreicht. Genau damit eröffnet sich der Weg in Richtung Alerting. Für die Beispielarchitektur gilt es nun ein entsprechendes Alerting auf Basis von Grafana herzustellen. Dies könnte auch über Prometheus erfolgen, hierzu müsste ein weiterer Container zur Multi-Container-Umgebung hinzugefügt werden.

Als erstes werde ich nun einen Notification Channel angelegen, und zwar konkret für OpsGenie. Auf dem Bild sind noch viele weitere Kanäle erkennbar. Für die Integration mit OpsGenie wird ein API-Key und eine URL benötigt.

Oberservability: Alert Notification

Des Weiteren lege ich noch ein neues Dashboard mit einem neuen Panel an. Als Metrik sollen alle HTTP Status Code vom Typ 401 erfasst werden. Als Alert lege ich einen Schwellenwert fest, der im Beispiel entweder dem Typ max() oder avg() zuzuordnen ist. Zum Schluss muss nur noch der entsprechende Notification Channel ausgewählt werden. Ebenso können zusätzliche Nachrichten oder Tags hinterlegt werden. Somit ist die Konfiguration seitens Grafana abgeschlossen.

Grafana Dashboard

OpsGenie

OpsGenie stellt das zweite Tool innerhalb des Alerting-Prozesses dar. Grafana ist zwar in der Lage entsprechende Alerts auszulösen, aber eine wirkliche Benachrichtigung mit einem Hinweis ist in Grafana nicht direkt vorgesehen. Hier kommt OpsGenie ins Spiel. OpsGenie ist eine Incident Management Platform, die auf Basis von Alerts arbeitet. Aufgrund der bidirektionalen Integrationsansatzes und der Vielzahl von Integrationen lässt sie sich theoretisch in jede Architektur integrieren.

Die Integrationen werden immer pro Team vorgenommen.

OpsGenie Integrations

Wie auf dem Bild zu erkennen, ist eine Integration für Grafana schon eingerichtet. Hier findet man auch den API-Key und die URL. Nun sind die beiden Tools miteinander verbunden. Entsprechend der Einstellungen von OpsGenie werden die Alerts von Grafana nun als Sprachnachricht, SMS oder E-Mail an die entsprechenden Personen des Teams weitergeleitet.

Somit ist ein guter erster Schritt in Richtung Observability für das Kong API-Gateway getan.Die Erweiterungen findet ihr im Repo bei GitHub unter dem Branch observe.

Daniel Kocot

Seit Oktober 2016 ist Daniel ein Teil des Teams der codecentric AG am Standort in Solingen. Schon seit Anfang der 2000er Jahre widmet er sich dem Thema der Digitalen Transformation. Neben den aktuellen Schwerpunkten API-Management, Application Lifecycle Management Tooling, Continuous Documentation und Voice UI ist er auch Experte für den Einsatz von Produktinformationssystemen (PIM) und Database-Publishing mithilfe von Rendering-Technologien.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.