Solr 8.9.0でprometheus-exporterを使用しているときに、重複したサンプルエラーが発生する

(The bot translated the original post https://lists.apache.org/thread/ql921tnmjntk0s7pjfofzxzf7ylg5gld into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
私たちの組織では、プロダクションユースケースのためにSolr 8.9.0を実装しました。メトリクスの収集と保存にはPrometheusを標準化しています。Solrクラスターからメトリクスをエクスポートするために、バージョン8.9.0のパブリックSolrイメージをEC2インスタンスにデプロイし、Dockerを使用して同じホスト上で実行されているSolrに対してエクスポーターバイナリを実行しています。Kubernetesにホストされ、Helmチャートを介して構成されたPrometheusスクレイパーは、各スクレイプで次のようなエラーを報告します:
ts=2021-08-10T16:44:13.929Z caller=dedupe.go:112 component=remote level=error remote_name=11d3d0 url=https://our.endpoint/push msg="non-recoverable error" count=500 err="server returned HTTP status 400 Bad Request: user=nnnnn: err: duplicate sample for timestamp. timestamp=2021-08-10T16:44:13.317Z, series={__name__="solr_metrics_core_time_seconds_total", aws_account="our-account", base_url="http://fqdn.for.solr.server:32080/solr", category="QUERY", cluster="our-cluster", collection="a-collection", core="a_collection_shard1_replica_t13", dc="aws", handler="/select", instance=" fqdn.for.solr.server:8984", job="solr", replica="replica_t13", shard="shard1"}"
Prometheusエクスポーターをクエリしたところ、重複する時系列が存在することを確認しました。以下は重複する時系列のサンプルです:
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t1",collection="a_collection",shard="shard1",replica="replica_t1",base_url="http://fqdn3.for.solr.server:32080/solr",} 1.533471301599E9
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t1",collection="a_collection",shard="shard1",replica="replica_t1",base_url="http://fqdn3.for.solr.server:32080/solr",} 8.89078653472891E11
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t1",collection="a_collection",shard="shard1",replica="replica_t1",base_url="http://fqdn3.for.solr.server:32080/solr",} 8.9061212477449E11
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t3",collection="a_collection",shard="shard1",replica="replica_t3",base_url="http://fqdn2.for.solr.server:32080/solr",} 1.63796914645E9
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t3",collection="a_collection",shard="shard1",replica="replica_t3",base_url="http://fqdn2.for.solr.server:32080/solr",} 9.05314998357273E11
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t3",collection="a_collection",shard="shard1",replica="replica_t3",base_url="http://fqdn2.for.solr.server:32080/solr",} 9.06952967503723E11
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t5",collection="a_collection",shard="shard1",replica="replica_t5",base_url="http://fqdn1.for.solr.server:32080/solr",} 1.667842814432E9
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t5",collection="a_collection",shard="shard1",replica="replica_t5",base_url="http://fqdn1.for.solr.server:32080/solr",} 9.1289401347629E11
solr_metrics_core_time_seconds_total{category="QUERY",handler="/select",core="a_collection_shard1_replica_t5",collection="a_collection",shard="shard1",replica="replica_t5",base_url="http://fqdn1.for.solr.server:32080/solr",} 9.14561856290722E11
これはエクスポーターコンテナを実行するsystemdユニットファイルです:
[Unit]
Description=Solr Exporter Docker
After=network.target
Wants=network.target
Requires=docker.service
After=docker.service
[Service]
Type=simple
ExecStart=/usr/bin/docker run --rm --name=solr-exporter --net=host --user=solr solr:8.9.0 /opt/solr/contrib/prometheus-exporter/bin/solr-exporter -p 8984 -z the-various-zookeeper-endpoints -f /opt/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml -n 4
ExecStop=/usr/bin/docker stop -t 2 solr-exporter
Restart=on-failure
[Install]
WantedBy=multi-user.target
PrometheusエクスポーターのXML設定を8.6.2(以前使用していたバージョン)と最新バージョンで調べましたが、最近大規模なリファクタリングが行われたようです。何か見落としている点があるのでしょうか?8.9でこの問題を再現できる方はいらっしゃいますか?
よろしくお願いします、
Joshua Hendrickson
過去の類似のお問い合わせ
- Solr 8.7 を Java 11 Open J9 で起動するときに、コマンドラインオプションが認識されない
(The bot translated the original post https://lists.apache.org/thread/p3t5jbhwzy7xgyv1rlyzcqyl5d4295b5
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、Java 8 から Java 11 への移行を進めています。
Windows上でOpenJ9 Javaを使ってSolr 8.7.0を起動すると、次のメッセージが表示されます:
JVMJ9VM007W Command-line option unrecognised: -Xlog:gc*:file="C:\solr\server\logs\solr_gc.log":time,uptime:filecount=9,filesize=20M JVMJ9GC063E Unable to open file '"C' for writing
その後、コンソールにはガベージコレクションの出力が続きますが、Solrは問題なく起動し、動作しているように見えます。同じリリースのJava 11 Hotspotに変更すると、警告や他の問題は見られません。
Ubuntu上のJava 11 Open J9でも同様の問題が発生します。Solrログには「Command-line option unrecognised」というメッセージが表示されますが、コンソールには表示されません。
solr_gc
ログは正しく作成され、内容も記録されています。これを確認したのは、OpenJDK 11.0.10+9リリースを使用した場合です。
以下は私たちの起動コマンドの例です:
C:/solr/bin/solr.cmd start -c -p 8983 -s C:/data/solr/8/clusters/is_cluster/nodes/node1 -a "-Dcom.ibm.crypto.provider.DoRSATypeChecking=false -Djetty.server=com.i2group.disco.search.solr.jetty.wrapper.XmlConfigurationWrapper -Dpkiauth.ttl=60000 -Dsolr-node-id=node1 -DzkCredentialsProvider=com.i2group.disco.search.solr.common.zookeeper.auth.internal.EncodedZkCredentialsProvider -Djdk.nativeCrypto=false" -m 2g -z "localhost:9983/is_cluster"
よろしくお願いします。
Lisa
- ZooKeeperのupconfigはZK_HOST形式のURLを認識しません
(The bot translated the original post https://lists.apache.org/thread/tfpn1tlgosx67n5omzpkmrdzvsbr02bd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
Solrのコントロールスクリプトを使用して新しいconfigsetをZooKeeperにアップロードしようとしたところ、-zパラメータがZK_HOST形式の文字列を認識しませんでした。
たとえば、
<ip-1>,<ip-2>,<ip-3>/solr
を使用すると、configが/solr znodeではなく、直接<ip-1>
にアップロードされます。これが意図された動作かどうかについて助けていただけないでしょうか?
注:
<ip-1>/solr,<ip-2>/solr,<ip-3>/solr
はうまく機能するようです。 - CustomBreakIteratorのパフォーマンスに関する問題
(The bot translated the original post https://lists.apache.org/thread/4kryrpfp9bdl3dbyb77vnmlfdlcg0dcd
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)こんにちは、
現在、統合ハイライト機能でカスタムBreakIteratorを動作させる作業をしており、パフォーマンスに苦労しています。
私はパッセージの見出しをきれいにハイライトするためにBreakIteratorが必要です。これにより、ハイライトの開始が文の開始であり、終了が単語の終わりであるようにしたいです。また、いくつかの奇妙なエッジケースもあります。
すでにBreakIteratorをコーディングし、カスタムUnifiedHighlighterクラスに統合しましたが、このIteratorを使用すると、すべてのリクエストのqTimeが約1000から12000以上に上昇し、このアプリケーションでは許容できません。
こちらが私の実装へのリンクです。どこが非常に非効率的なのかを見つけることができません。(これらの関数が非常に頻繁に呼び出されることはわかっています)
他のアプローチも含め、すべての提案を歓迎します。
したがって、BreakIteratorや関連する情報について詳しく学ぶための良いリソースはありますか?ここではコードの調査が非常に難しいです。
次に検討しているもう1つのアプローチは、最終的なハイライトが見つかったときにこのハイライトの「トリミング」を行うことです。これにより、呼び出されるロジックの量が減少しますが、SOLRのスコアリングシステムが正しく考慮されない可能性があると思われます。
私が言ったように、すべての提案を歓迎し、先にお礼を申し上げます。
Jan Ulrich Robens
- 検索ストリーミング式で特定のシャードからドキュメントを取得
(The bot translated the original post https://lists.apache.org/thread/vdqjcy6frv9c2kg97xh244ppj1v5jgc2
into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)「Search streaming expression」で単一の特定のシャード(または特定のレプリカ)からすべてのドキュメントをストリームできますか? 通常の「shards」パラメータを使用しても、Search streaming exprと一緒に使用すると効果がないと思います。
--ufuk
- 音声検索
javadocによると、BeiderMorseFilterFactory はStandardTokenizerの後に使用することが推奨されています。
おそらく、GermanNormalizationFilterFactoryやGermanLightStemFilterFactoryはBeiderMorseFilterFactoryと一緒に使用すべきではありません。ステムが切り捨てられると、その発音が一致しなくなる可能性があります。
一方、異なる表記法(ß <-> ss)で書かれたドイツ語の単語を一致させたいだけなら、GermanNormalizationFilterFactoryだけで十分です。BeiderMorseFilterFactoryは必要ありません。
追伸:私はドイツ語の話者ではなく、上記の主張を実際にテストしたわけではありません。ただの推測です。
トピックへ返信するには、ログインが必要です。