Performance Optimierung Kibana (Elasticsearch) DEV/TEST

User Story

Als Betreiber und Entwickler von FIT-Connect müssen wir effizientes Troubleshooting durchführen können.

Why

Abfragen auf der DEV/TEST Kibana Instanz dauern im Vergleich zu PROD deutlich zu lang (teils >1 Minute). Auch kommt es immer wieder zu Timeouts. Insbesondre Team ZSD hatte in letzter Zeit hiermit öfter Probleme.

Links, Notes, Remarks

MS Teams Meldung/Konservation (CME): https://teams.microsoft.com/l/message/19:3c8c024266b94b55af647c39dca46072@thread.tacv2/1700819330110?tenantId=7030c8e1-cbee-4c02-b830-5e125ef65978&groupId=17f45aa2-4261-48d2-845f-afd6cf3a2b97&parentMessageId=1700819330110&teamName=FIT-Connect&channelName=Infrastruktur%20(FCT)&createdTime=1700819330110

Lösungsvorschläge

"Eine Möglichkeit wäre die Anzahl der Shards zu erhöhen. Zurzeit ist der Wert 1: "Shards are basically used to parallelize work on an index. When you send a bulk request to index a list of documents, they will be split and divided among all available primary shards." "Indexing is usually quicker when you have more shards, as each document needs to be stored only once per shard. If fast ingestion is your biggest concern, you should have at least one shard per data node. Alternatively, you can also have a number that is evenly divisible by the number of data nodes." https://opster.com/guides/elasticsearch/capacity-planning/elasticsearch-number-of-shards/

Je nachdem welche Optionen die API bietet könnten wir die Server Ressourcen mit Prometheus monitoren und die Anzahl der Shards anhand der Auslastung einstellen. "

Acceptance criteria

  1. Die Bearbeitung der Abfragen dauert maximal X Sekunden.
  2. Es entstehen auch bei komplexeren Abfragen mit Filtern keine Timeouts.

Implementation plan (to be completed by the developer)

Edited by Maik Böttner