Hinweise zur Installation und Konfiguration
- Wenn beim Starten eine Fehlermeldung zu nicht ausreichendem Speicher auftaucht, kann dieser in der jvm.options aus dem Config-Unterordner mit „-Xms1g“ und „-Xmx1g“ auf ein GB reduziert werden. Diese Einstellung hat bei unseren Tests auch mit mehreren Anwengungs-Instanzen keine Probleme verursacht.
Erfahrungsgemäß sind diese Limits aber nur ein grober Anhaltspunkt und werden zur Laufzeit trotzdem überschritten. - Unter der URL „http://127.0.0.1:9200” bzw. bei aktivierter Sicherheit „https://127.0.0.1:9200” kann man prüfen, ob der Suchdienst läuft. Unter Chrome macht die Abfrage manchmal Probleme (zu lange Anfragelänge o.ä.), unter Firefox sollte es aber funktionieren. Es werden dann Clustername, Versionsstand und einige weitere Informationen ausgegeben.
- Beide Suchdienste sind standardmäßig auf 1000 Shards pro Node limitiert wobei pro Suchindex in CXM ca. 5 Shards verwendet werden. Bei mehreren CXM Instanzen pro Node kann das Limit erreicht werden. In diesem Fall kann die Einstellung wie folgt verändert werden:
curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_cluster/settings?pretty -d "{""persistent"":{""cluster.max_shards_per_node"": 2000}}" - Um zu prüfen, wie weit man von dem Limit noch entfernt ist
curl -s -XGET http://localhost:9200/_cluster/stats?filter_path=indices.shards.total
- Um zu prüfen, was aktuell als Limit konfiguriert ist (wird hier nichts ausgegeben, ist es der Standard von 1000)
curl -X GET "localhost:9200/_cluster/settings?pretty
Hinweise zur Anbindung
- Die URL zum Suchdienst und ggf. notwendige Zugangsdaten sowie weitere Optionen werden in der Customer.Config hinterlegt. Die dazu relevanten Parameter beginnen mit BA:Search.
- Auf der Service-Seite zur administrativen Übersicht gibt es eine Option zum Löschen von Suchindexen aus anderen Instanzen. Diese Funktion muss in Hosting-Umgebungen, bei denen mehrere Kunden dieselbe Suchdienst-Datenbank verwenden, per Customer.Config deaktiviert werden!
- Das „Hitlimit” des Suchdienstes darf nicht geändert werden: Standardmäßig liefert Elasticsearch maximal 10.000 Treffer. Diese Option nennt sich „index.max_result_window” und darf auf keinen Fall verändert werden, da ansonsten die reibungslose Änderungsversorgung nicht mehr gegeben ist. Auch dann nicht, wenn es erst einmal so aussieht, als würde alles funktionieren.
- Weitere Informationen zur Konfiguration der Suchindexe befinden sich hier.
Troubleshooting
- Wenn der Suchdienst keinerlei Änderungen mehr annimmt aber lesend noch wunderbar funktioniert, ist sie vielleicht mangels Speicherplatz vorausschauend in den Nur-Lesemodus gewechselt. Eine entsprechende Fehlermeldung findet sich dann im Logfile. In diesem Fall zunächst erst einmal Speicher frei machen und mit folgendem Curl-Befehl wieder das Schreiben ermöglichen:
curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d "{""index.blocks.read_only_allow_delete"": null}". Danach sollten die Indizes sicherheitshalber neu aufgebaut werden, damit die Daten auch konsistent sind.
- Log-Trace: Es ist möglich, eine erweiterte Protokollierung für den Indexer zu aktivieren. Das sollte nur kurzzeitig passieren, da die Logdateien sehr schnell sehr groß werden können! Das Logging erfolgt dann in dem normalen Logfile aus dem AppDate\Logs Ordner. Dazu muss der Logger per CustomNLog.config auf trace gestellt werden:
<nlog><rules> <logger name="*.IndexUpdateWorker" minlevel="Trace" writeTo="file"/> <logger name="*.SearchHelper" minlevel="Trace" writeTo="file"/> </rules></nlog>
- Bei großen Suchindexen kann im Log die Fehlermeldung
too_many_clauses maxClauseCount is set to 1024
ausgegeben werden. In dem Fall muss die ElasticSearch.yml bzw. OpenSearch.yml um diese Zeile ergänzt werden:
indices.query.bool.max_clause_count : 4096