Fehlersuche bei Elasticsearch

Hallo,

habe mir jetzt Elasticsearch eingerichtet und die Produkte entsprechend initialisieren lassen mit sw:es:index:populate . Gab auch keinen Fehler.

Nun ist aber das Problem, dass in den Listings keine Artikel angezeigt werden. Dachte zuerst, es könnte an meinem Template liegen. Daher habe ich zum testen das Responsive Theme genommen, aber auch hier werden keine Artikel angezeigt.

Kann mir jemand verraten, wie ich hier auf die Fehlersuche gehe und vor allem, wo? Am Theme kann es ja nicht liegen, sonst würde es im Responsive funktionieren. 

Vielen Dank für eure Hilfe.

HEPI

Wie sieht denn deine config.php aus und betreibst du elasticsearch im Cluster oder als einzelnen Node?

Elasticsearch ist auf meinem Server bei @TimmeHosting‍ Ob im Cluster oder einzelne Node kann ich garnicht mal sagen. 

Die config.php :

'es' => [
	'enabled' => true,
	'number_of_replicas' => null,
	'number_of_shards' => null,
	'dynamicMappingEnabled' => true,
	'version' => '5.6.16',
		'client' => [
		    'hosts' => [
			'localhost:9200'
		    ]
		]
    ],

Gerade überlege ich, ob es ggf an meiner Erweiterung für das Listing liegen kann? Ich greife auf folgende Events zu:

 'Enlight\_Controller\_Action\_PostDispatch\_Frontend\_Listing' =\> 'Shopware\_Controllers\_Frontend\_Search::defaultSearchAction::after' =\> 

Damit lade ich weitere Informationen zur Darstellung des Listings und des Suchergebnisses (Farbfelder, Infotext). Muss ich hier ggf auch noch Elasticsearch mit einbinden?

Vielen Dank für die Hilfe.

HEPI

Hast du die Erweiterung mal deaktiviert? So kannst du es ja schnell prüfen

Die Idee mit der Erweiterung kam mir beim schreiben. Aber habe diese mal deaktiviert und es funktioniert leider immer noch nicht. 

Habe nun einen neuen Artikel angelegt. Der wird mir angezeigt.

Dann stellt sich mir jetzt aber die Frage, warum der neue Artikel und nicht die Alten? Wo kann hier das Problem sein?

[EDIT] Habe noch einen weiteren Fehler im Testshop festgestellt bei den Artikeln. Könnte an einem “dreckigen Script” aus der Testumgebung liegen. Denn der Fehler ist im scharfen Shop nicht. Daher teste ich Elasticsearch in den nächsten Tagen im scharfen Shop. Wenn es hier auch Probleme gibt, melde ich mich erneut. Schon Mal vielen Dank an die Helfer [/EDIT]

Du musst die config anpassen wenn es kein Cluster ist, steht auch so in der Doku. Bei Replicas müsstest du 0 statt null eintragen. Elasticsearch nutzt per default Cluster Settings und wenn es nur einen Node gibt, funktionieren die defaults entsprechend nicht.

Das werde ich nachher testen. Da habe ich die Doku aber falsch verstanden. Wann habe ich denn ein „Cluster“ und wann einen „Node“ ? 

Ist Cluster, wenn ich direkt bei Elasticsearch hoste und Node, wenn ich Elasticsearch auf meinen Server installiert habe?
Dachte, dass damit gemeint ist, dass Elasticsearch bei vielen Daten diese in mehrere Gruppen aufteilt, je nach Einstellung.

Dass ein Cluster aus mehreren Nodes besteht, habe ich verstanden.

@Moritz Naczenski‍ Gibt es denn noch eine andere Doku als diese? Elasticsearch setup

Dort ist es nämlich mit „null“ aufgeführt bei replicas.

Wir haben übrigens auch Probleme ElasticSearch an den Start zu bringen. (Auch Timme, derzeit Shopware 5.5.7.)

  • Indexierung klappt nur, wenn wir diese mit PHP 5.6 anstoßen. Bei PHP 7.x kommt es immer wieder zu Fehlermeldungen.
  • Nach der Indexierung sind die Artikellisten in den Kategorien leer. (Spannend dabei: Die Filtermöglichkeiten passen.)

Im Backend funktioniert die Indexierung und Nutzung von ElasticSearch. Allerdings mit folgenden Nachteilen:

  • Artikelfilter funktionieren nicht.
  • Variantennamen werden ohne Attributbezeichnungen ausgegeben.
  • Suche nach Artikeln (Feld rechts oben) funktioniert nicht. *
  • Filter bei Bestellungen müssen zuerst zurückgesetzt werden ehe man filtert. Sonst gibt es eine Fehlermeldung.

*) 50/50 Chance in diesem Fall, dass es an der ElasticSearch-Implementierung oder einem Plugin liegt.

Glücklicherweise ist ES nichts, auf das wir angewiesen sind. Ursprünglich war der Einsatz geplant, um die schlechte Performance an verschiedenen Stellen in den Griff zu bekommen. Durch Anpassungen an anderen Stellen, haben wir es aber auch so weitgehend in den Griff bekommen.

Im Backend wäre ES „nice to have“, wenn die genannten Nachteile nicht wären. Die deutlich besseren Suchergebnisse über das blaue Suchfeld sind schon für sich allein ein schlagendes Argument. Rein von der Performance bräuchten wir ES im Backend aber nicht.

Im Frontend wäre ES toll, weil wir damit die letzten Performance-Dellen ausbügeln könnten und den einen oder anderen Workaround bzw. Kompromiss hinter uns lassen könnten. Die Performance ohne Artikel ist natürlich super. :wink: Das Gleiche jetzt bitte noch mit Artikeln.

@naturdrogerie schrieb:

@Moritz Naczenski‍ Gibt es denn noch eine andere Doku als diese? https://developers.shopware.com/sysadmins-guide/elasticsearch-setup/

Dort ist es nämlich mit „null“ aufgeführt bei replicas.

Da ist eine große blaue Box darunter:

Note:  For a single node configuration, which is sufficient for a development environment, it is necessary to configure a number_of_replicas of 0, otherwise the indexing process would wait for cluster health green, which can’t be reached if no replicas can be applied. 

 

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍ Touché! Die habe ich tatsächlich übersehen, weil ich mich vor allem auf die Beispielkonfigurationen konzentriert habe.

Das ist dann so korrekt?

'number_of_replicas' => 0,
'number_of_shards' => null,

 

Ja, genau.

Elasticsearch ist für den Cluster-Betrieb angelegt und wenn es nur ein Node gibt, dann ist der Cluster “Health Status” nur gelb oder rot, statt grün. Entsprechend funktioniert das nicht richtig. Wenn man ihm explizit sagt, dass es nur einen Node gibt, dann wird der Status grün und alles funktioniert Ordnungsgemäß. Ohne diese Einstellung sucht er nach neuen Nodes und wartet bis einer auftaucht. Man kann das aber auch in der ES-Konfiguration setzen - hat also speziell nichts mit SW zu tun, du kannst nur die Settings auch per config.php setzen.

@HEPI‍ und mir keine Artikel in den Kategorien auftauchen. Heute wieder getestet: nüscht.

Naja, kann durchaus an den Artikeln liegen, die elasticsearch Integration ist bei weitem nicht so tolerant wie die DB. Werden denn Fehler ins log geschrieben? Die aktuelle Integration zeigt die ja beim indexieren an. Ich hab keine Probleme damit und es sind ja auch viele Shops online wo es funktioniert.

Richtige Versionsnummer von ES in der config angegeben?

 

Versionsnummer angepasst. Ist jetzt tatsächlich 5.6.16 statt 5.6.10.

Das Kuriose ist beim polpulate ja nach wie vor, dass unter PHP 7.x der Prozess mit einer Fehlermeldung abbricht, mit PHP 5.6 läuft es durch.

Hier der Fehler, der bei PHP 7.x kommt:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Shopware\Bundle\ESIndexingBundle\Product\ProductListingVariationLoader::createSplitting() must be of the type array, null given, called in /var/www/clients/client1/web1/web/stageware3/engine/Shopware/Bundle/ESIndexingBundle/Product/ProductListingVariationLoader.php on line 198 and defined in /var/www/clients/client1/web1/web/stageware3/engine/Shopware/Bundle/ESIndexingBundle/Product/ProductListingVariationLoader.php:225

Mit PHP 5.6 sieht es so aus:

Indexing properties
 8/8 [============================] 100% < 1 sec/< 1 sec

 Evaluation:
  Total: 7 items
  Error: 0 items
  Success: 7 items


Indexing products
 4244/4244 [============================] 100% 13 secs/13 secs

 Evaluation:
  Total: 2979 items
  Error: 6 items
  Success: 2973 items

Die Fehler im Log sind alle ähnlich den beiden:

type":"illegal_argument_exception","reason":"mapper [calculatedPrices.AMA_1.rule.unit.purchaseUnit] cannot be changed from type [float] to [long]"

"type":"illegal_argument_exception","reason":"mapper [listingVariationPrices.AMA_1.g5] cannot be changed from type [long] to [float]"

Es sind also vereinzelt Preise das Problem. Ich verstehe nur nicht so ganz wieso.

Mal davon ausgegangen, dass die _id im Log sich auf die Artikelnummer (also ordernumber in der DB) bezieht, dann sehen die Preise der betreffenden Produkte im Backend ganz normal aus. In der DB finde ich auch keine Fehler – bei den Produkten mit dem Purchasre-Unit-Fehler sind nicht mal Staffelpreise definiert.

Bist du sicher, dass du noch ES 5 im Einsatz hast? Generell sollte das zwar auch funktionieren, aber die wird schon 2 Monate nicht mehr weiterentwickelt und ist End Of Life. Bekommt also keine Sicherheits- und Fehlerkorrekturen mehr.

Am besten legst du dir mal einen Testshop an und spielst damit etwas rum. Im ersten Schritt würde ich mal die Variantenauffächerung deaktivieren und schauen ob es grundsätzlich funktioniert. Die Fehlermeldung geht m.M.n. in diese Richtung.

Ziemlich sicher:

$ curl localhost:9200
{
  "name" : "DEMoog4",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "thxxB2jnTEqVewEerqkMRg",
  "version" : {
    "number" : "5.6.16",
    "build_hash" : "3a740d1",
    "build_date" : "2019-03-13T15:33:36.565Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.1"
  },
  "tagline" : "You Know, for Search"
}

Ich teste das logischerweise ohnehin schon mit einem Stagingsystem und nicht dem Liveshop. :wink:

An welcher Stelle genau soll ich die Variantenauffächerung deaktivieren? Ich dachte das gibt es nur bei Filtern? Soll ich da den Filter “Varianten” rausnehmen?

Schalte mal dynamic mapping aus https://github.com/shopware/shopware/blob/5.5/engine/Shopware/Configs/Default.php#L151

@Shyim‍ Hat nicht wirklich etwas verändert. Populate mit PHP 7 bricht immer noch mit der selben Fehlermeldung ab. Mit PHP 5.6 schwankt es zwischen 3 und 8 Fehlern – je nach Durchlauf.

[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ Kannst Du noch kurz sagen, ob es sich um den Filter “Varianten” handelt, was Du gemeint hast oder was anderes?

Ja, ich meine die Filterung nach Varianten/Auffächerung der Varianten.

@Shyim‍: Danke für die großartige Unterstützung. Das hat mich endlich auf die richtige Fährte gebracht.

Eben hatte ich einen gewissen Verdacht und habe ein bestimmtes Plugin deaktiviert: “Varianten-Eigenschaften”. Danach wurden die Produkte angezeigt. Ich muss jetzt noch mal intensiver testen, warum es nicht damit laufen will und ob der Hersteller ggf. Hand anlegen muss.

Mit den anderen Einstellungen (wie der Auffächerung der Varianten) werde ich ebenfalls noch etwas herumprobieren. Wahrscheinlich kann ich das ohne Probleme wieder aktivieren.

Mit PHP 7.x läuft populate jetzt übrigens auch durch. Da muss ich noch mal schauen, ob es die Auffächerung oder das Plugin war, was den Fehler ausgelöst hat. (Wobei es schon merkwürdig ist, dass es mit PHP 5.6 immer durchgelaufen ist.)

Weiterhin gibt es zwischen 0 und 4 Fehlern beim populate. Die beteffenden Produkte tauchen aber normal im Listing auf. Einen negativen Einfluss kann ich im ersten Augenblick nicht erkennen.