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
-
Die Bearbeitung der Abfragen dauert maximal X Sekunden. -
Es entstehen auch bei komplexeren Abfragen mit Filtern keine Timeouts.
Implementation plan (to be completed by the developer)
-
... -
... -
... -
Definition of Done was checked.