Re: oracle and DIH
Hello Mike.
If it hangs you may see it in Thread Dump in Solr Admin or via jstack etc.
Probably it may give a clue what's going on there.
On Wed, Feb 5, 2025 at 3:02 AM Mike Phillips
wrote:
> I have solr 9.8.0 running the data import handler in standalone mode.
> All the documented steps fail in zoo keeper mode (bummer).
>
> I can import data from MySQL and Postgres but when I try oracle it
> fails. The output in the solr log looks like it is going to connect and
> then it just does nothing.
>
> Here is the log output when doing a Full Import in 8.4.1
>
> 2025-02-04 13:39:13.301 INFO (qtp599782425-69) [ x:rat_11]
> o.a.s.h.d.DataImporter Loading DIH Configuration: data-config.xml
> 2025-02-04 13:39:13.337 INFO (qtp599782425-69) [ x:rat_11]
> o.a.s.h.d.c.DIHConfiguration The field :clientName present in DataConfig
> does not have a counterpart in Solr Schema
> 2025-02-04 13:39:13.337 INFO (qtp599782425-69) [ x:rat_11]
> o.a.s.h.d.DataImporter Data Configuration loaded successfully
> 2025-02-04 13:39:13.360 INFO (Thread-24) [ ] o.a.s.h.d.DataImporter
> Starting Full Import
> 2025-02-04 13:39:13.360 INFO (qtp599782425-69) [ x:rat_11]
> o.a.s.c.S.Request [rat_11] webapp=/solr path=/DmeImport
> params={commit=true&clean=true&wt=xml&command=full-import} status=0
> QTime=65
> 2025-02-04 13:39:13.389 WARN (Thread-24) [ ]
> o.a.s.h.d.SimplePropertiesWriter Unable to read: DmeImport.properties
> 2025-02-04 13:39:13.637 INFO (Thread-24) [ ] o.a.s.h.d.JdbcDataSource
> Creating a connection for entity asset_core with URL:
> jdbc:oracle:thin:@rat:52689:dme1
> 2025-02-04 13:39:14.183 INFO (Thread-24) [ ] o.a.s.h.d.JdbcDataSource
> Time taken for getConnection(): 545
> 2025-02-04 13:39:14.331 INFO (Thread-24) [ ] o.a.s.h.d.JdbcDataSource
> Creating a connection for entity asset_dmeaccount with URL:
> jdbc:oracle:thin:@rat:52689:dme1
> ...
> After here the rest of my tables connect and import
>
>
> Here is the log output for solr 9.8.0
>
> 2025-02-04 15:04:57.366 INFO (qtp142099757-26-null-12) [c: s: r:
> x:rat_11 t:null-12] o.a.s.h.d.DataImporter Loading DIH Configuration:
> data-config.xml
> 2025-02-04 15:04:57.429 INFO (qtp142099757-26-null-12) [c: s: r:
> x:rat_11 t:null-12] o.a.s.h.d.c.DIHConfiguration The field :clientName
> present in DataConfig does not have a counterpart in Solr Schema
> 2025-02-04 15:04:57.429 INFO (qtp142099757-26-null-12) [c: s: r:
> x:rat_11 t:null-12] o.a.s.h.d.DataImporter Data Configuration loaded
> successfully
> 2025-02-04 15:04:57.451 INFO (qtp142099757-26-null-12) [c: s: r:
> x:rat_11 t:null-12] o.a.s.c.S.Request webapp=/solr path=/DmeImport
> params={commit=true&clean=true&wt=xml&command=full-import} status=0
> QTime=86
> 2025-02-04 15:04:57.451 INFO (Thread-23) [c: s: r: x: t:]
> o.a.s.h.d.DataImporter Starting Full Import
> 2025-02-04 15:04:57.475 INFO (Thread-23) [c: s: r: x: t:]
> o.a.s.h.d.SimplePropertiesWriter Read DmeImport.properties
> 2025-02-04 15:04:57.623 INFO (Thread-23) [c: s: r: x: t:]
> o.a.s.h.d.JdbcDataSource Creating a connection for entity asset_core
> with URL: jdbc:oracle:thin:@rat:52689:dme1
> 2025-02-04 15:04:57.838 INFO (Thread-23) [c: s: r: x: t:]
> o.a.s.u.p.LogUpdateProcessorFactory webapp=/solr path=/DmeImport
> params={commit=true&clean=true&wt=xml&command=full-import} status=0
> QTime=86{deleteByQuery=*:* (-1823169888949108736)} 0 474
>
> It just stops here.
>
> I used a lib directory parallel with the conf directory and I put:
>
> data-import-handler-9.7.0.jar
> ojdbc6.jar
>
> Anybody got any suggestions?
>
--
Sincerely yours
Mikhail Khludnev
Re: basic steps for data-import-handler do not work without exceptions
This error with this path was already fixed in repository.json for previous
versions of DIH, but it reoccur in new releases:
https://github.com/SearchScale/dataimporthandler/issues/85
Have no idea why and what to do.
On Tue, Feb 4, 2025 at 11:53 PM Mike Phillips <
m.phill...@prosperodigital.com> wrote:
> I have a non cloud 8.4.1 solr version with built in DIH working and I am
> looking to migrate.
>
> This are the steps I did to try and have a solr test system with the
> data-import-hander plugin.
>
> # as root
> 1) install_solr_service.sh solr-9.7.0.tgz -f -i /opt -d /var/solr-data
> -u solruser -s solr -p 8983
>
> # as solruser
> 2) solr stop -p 8983
>
> 3) solr start --cloud -Denable.packages=true
>
> 4) solr package add-repo data-import-handler
> "
> https://raw.githubusercontent.com/searchscale/dataimporthandler/master/repo/
> "
> Neither --zk-host or --solr-url parameters provided so assuming solr url
> is http://localhost:8983.
> Added repository: data-import-handler
>
> 5) solr package list-available
> Neither --zk-host or --solr-url parameters provided so assuming solr url
> is http://localhost:8983.
> Available packages:
> -
> data-import-handler A utility to import documents from a
> database system into Apache Solr
> Version: 9.2.1
> Version: 9.0.0
> Version: 8.10.0
> Version: 8.6.0
> Version: 9.3.0
> Version: 9.4.0
> Version: 9.6.1
> Version: 9.7.0
>
> 6) solr package install data-import-handler
> Neither --zk-host or --solr-url parameters provided so assuming solr url
> is http://localhost:8983.
> Posting manifest...
> Posting artifacts...
> Executing Package API to register this package...
> Response: {
>"responseHeader":{
> "status":0,
> "QTime":144}}
> data-import-handler installed.
>
>
> 7) curl
> "
> http://localhost:8983/solr/admin/collections?action=CREATE&name=oel1_6&numShards=1
> "
> {
>"responseHeader":{
> "status":0,
> "QTime":5294
>},
>"success":{
> "localhost:8983_solr":{
>"responseHeader":{
> "status":0,
> "QTime":2450
>},
>"core":"oel1_6_shard1_replica_n1"
> }
>},
>"warning":"Using _default configset. Data driven schema functionality
> is enabled by default, which is NOT RECOMMENDED for production use. To
> turn it off: curl http://{host:port}/solr/oel1_6/config -d
> '{\"set-user-property\": {\"update.autoCreateFields\":\"false\"}}'"
>
>
> 8) solr package deploy data-import-handler:9.7.0 -y -collections oel1_6
> Neither --zk-host or --solr-url parameters provided so assuming solr url
> is http://localhost:8983.
> Executing
> {"add-requesthandler":{"name":"/dataimport","class":"data-import-handler:org.apache.solr.handler.dataimport.DataImportHandler","defaults":{"config":"data-config.xml"}}}
>
> for path:/api/collections/oel1_6/config
> Executing
>
> http://localhost:8983/api/collections/oel1_6/config/requestHandler?componentName=/dataimport&meta=true
> for collection:oel1_6
> {
>"responseHeader":{
> "status":0,
> "QTime":2},
>"config":{"requestHandler":{"/dataimport":{
> "name":"/dataimport",
>
> "class":"data-import-handler:org.apache.solr.handler.dataimport.DataImportHandler",
> "defaults":{"config":"data-config.xml"},
> "_packageinfo_":{
>"package":"data-import-handler",
>"version":"9.7.0",
>"files":[
> "/package/data-import-handler/9.7.0/data-import-handler-9.7.0.jar",
> "/package/data-import-handler/9.7.0/mariadb-java-client-2.6.0.jar"],
> "manifest":"/package/data-import-handler/9.7.0/manifest.json",
>
> "manifestSHA512":"2bba2115d6105cf39b935980553b9c85d06121e0a406888595b2e5cf922b4e09df882076b572a32957a60c9b67d3e7a39b0e79f512c5d12b3003e3be0857629b"}
> com.jayway.jsonpath.InvalidPathException: Error in JSON
> Path:$[config].[requestHandler].[HANDLER-PATH].[_packageinfo_].[version]
> at
>
> org.apache.solr.packagemanager.PackageManager.jsonPathRead(PackageManager.java:870)
> at
>
> org.apache.solr.packagemanager.PackageManager.verify(PackageManager.java:834)
> at
>
> org.apache.solr.packagemanager.PackageManager.deployPackage(PackageManager.java:366)
> at
>
> org.apache.solr.packagemanager.PackageManager.deploy(PackageManager.java:947)
> at org.apache.solr.cli.PackageTool.runImpl(PackageTool.java:184)
> at org.apache.solr.cli.ToolBase.runTool(ToolBase.java:52)
> at org.apache.solr.cli.SolrCLI.main(SolrCLI.java:227)
> Caused by: com.jayway.jsonpath.InvalidPathException: Could not parse
> token starting at position 1. Expected ?, ', 0-9, *
> at
> com.jayway.jsonpath.internal.path.PathCompiler.fail(PathCompiler.java:642)
> at
>
> com.jayway.jsonpath.internal.path.PathCompiler.readNextToken(PathCompiler.java:139)
> at
>
> com.jayway.jsonpath.internal.path.PathCompiler.readContextToken(PathCompiler.java:123)
> at
>
> com.jayway.jsonpath.internal.path.PathCompiler.compile(PathCompiler.java:58)
RE: Upgrade issues 9.1 to 9.7
Really could do with some insight on this. One of the nodes on the server reports constant connection errors in and out. I see things like: 2025-02-05 10:03:47.518 WARN (qtp1959239586-70) [] o.a.s.h.a.AdminHandlersProxy Exception when fetching result from node GIG01SRVWCRSOL1:18983_solr => java.util.concurrent.ExecutionException: org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error from server at http://GIG01SRVWCRSOL1:18983/solr: Expected mime type application/octet-stream but got text/html. Error 401 Expired key request timestamp, elapsed=11518 HTTP ERROR 401 Expired key request timestamp, elapsed=11518 URI:/solr/admin/metrics STATUS:401 MESSAGE:Expired key request timestamp, elapsed=11518 SERVLET:default at java.base/java.util.concurrent.FutureTask.report(Unknown Source) java.util.concurrent.ExecutionException: org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: Error from server at http://GIG01SRVWCRSOL1:18983/solr: Expected mime type application/octet-stream but got text/html. Error 401 Expired key request timestamp, elapsed=11518 HTTP ERROR 401 Expired key request timestamp, elapsed=11518 URI:/solr/admin/metrics STATUS:401 MESSAGE:Expired key request timestamp, elapsed=11518 SERVLET:default -Original Message- From: Joe Jones (DHCW - Software Development) Sent: 04 February 2025 15:50 To: users@solr.apache.org Subject: Upgrade issues 9.1 to 9.7 WARNING: This email originated from outside of NHS Wales. Do not open links or attachments unless you know the content is safe. Hello all, I attempted a rolling upgrade of our Solr Cloud Windows based installation today from version 9.1 to 9.7. We have 12 shards split across 2 data centers with 3 servers in each. After the first upgrade I noticed the admin GUI was not responding properly, mostly a blank page with a spinning wheel in the corner. The query engine underneath appeared fine but the admin panels were slow at best to respond. The errors seen were around "PKIAuthenticationPlugin": Expired key request timestamp Exception trying to get public key from: (http://SERVER NAME HERE) Key is null when attempting to validate signature Could not validate PKI header We have basic authentication enabled. I rolled back the upgrade on the server and still see issues with responsiveness for the nodes (restarted the vm a couple of times). Other nodes reporting "Timeout when fetching result from node " against the server the upgrade was attempted on. We did upgrade a small SIT environment but that was from 9.2 to 9.7. Any advice on how to clear this residual issue out and what can be done for a future upgrade? Thanks. Joe. Rydym yn croesawu derbyn gohebiaeth yn Gymraeg. Byddwn yn ateb y fath ohebiaeth yn Gymraeg ac ni fydd hyn yn arwain at oedi. We welcome receiving correspondence in Welsh. We will reply to such correspondence in Welsh and this will not lead to a delay.
Re: facet.method=enum is required when using PathHierarchyTokenizer for facet.field in Solr 9.8
Hello Mingchun.
Perhaps it can not "uninvert" (obtain docValues/fieldcache -like
representation) for a text field.
facet=enum uses inverted index to deal with text fields: it just loops term
dictionary and check an intersection count between result docset and term's
docset.
>From the other side: analysis is not applied for string fields that does
not allow to apply a tokenizer.
However if an application code create pathes /a /a/b /a/b/c itself,
faceting over doc values will work.
On Thu, Feb 6, 2025 at 2:56 AM Mingchun Zhao
wrote:
> Hi,
>
> Why does faceting not work in Solr 9.8 when using PathHierarchyTokenizer
> for facet.field without specifying the facet.method=enum parameter?
>
> Here are the details:
>
> - fieldType
>
> ```xml
>
>
>
>
>
>
>
>
> ```
>
> - field
>
> ```xml
> "false" required="false" multiValued="false"/>
> ```
>
> - index data
>
> ```json
> [
> {
> "id": "1",
> "category_path": "foo/bar/baz"
> }
> ]
> ```
>
> - query without facet.method=enum
>
> ```bash
> curl "
>
> http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path
> "
> ```
>
> ```json
> "facet_counts":{
> "facet_queries":{ },
> "facet_fields":{
> "category_path":[ ]
> },
> "facet_ranges":{ },
> "facet_intervals":{ },
> "facet_heatmaps":{ }
> }
> ```
>
> - query with facet.method=enum
>
> ```bash
> curl "
>
> http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path&facet.method=enum
> "
> ```
>
> ```json
> "facet_counts":{
> "facet_queries":{ },
> "facet_fields":{
> "category_path":["foo",1,"foo/bar",1,"foo/bar/baz",1]
> },
> "facet_ranges":{ },
> "facet_intervals":{ },
> "facet_heatmaps":{ }
> }
> ```
>
> Regards,
> Mingchun
>
--
Sincerely yours
Mikhail Khludnev
Re: facet.method=enum is required when using PathHierarchyTokenizer for facet.field in Solr 9.8
Hi Mikhail,
Thanks for your explanation! I fully understand now.
Best regards,
Mingchun
2025年2月6日(木) 15:55 Mikhail Khludnev :
> Hello Mingchun.
> Perhaps it can not "uninvert" (obtain docValues/fieldcache -like
> representation) for a text field.
> facet=enum uses inverted index to deal with text fields: it just loops term
> dictionary and check an intersection count between result docset and term's
> docset.
> From the other side: analysis is not applied for string fields that does
> not allow to apply a tokenizer.
> However if an application code create pathes /a /a/b /a/b/c itself,
> faceting over doc values will work.
>
> On Thu, Feb 6, 2025 at 2:56 AM Mingchun Zhao
> wrote:
>
> > Hi,
> >
> > Why does faceting not work in Solr 9.8 when using PathHierarchyTokenizer
> > for facet.field without specifying the facet.method=enum parameter?
> >
> > Here are the details:
> >
> > - fieldType
> >
> > ```xml
> >
> >
> >
> >
> >
> >
> >
> >
> > ```
> >
> > - field
> >
> > ```xml
> > > "false" required="false" multiValued="false"/>
> > ```
> >
> > - index data
> >
> > ```json
> > [
> > {
> > "id": "1",
> > "category_path": "foo/bar/baz"
> > }
> > ]
> > ```
> >
> > - query without facet.method=enum
> >
> > ```bash
> > curl "
> >
> >
> http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path
> > "
> > ```
> >
> > ```json
> > "facet_counts":{
> > "facet_queries":{ },
> > "facet_fields":{
> > "category_path":[ ]
> > },
> > "facet_ranges":{ },
> > "facet_intervals":{ },
> > "facet_heatmaps":{ }
> > }
> > ```
> >
> > - query with facet.method=enum
> >
> > ```bash
> > curl "
> >
> >
> http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path&facet.method=enum
> > "
> > ```
> >
> > ```json
> > "facet_counts":{
> > "facet_queries":{ },
> > "facet_fields":{
> > "category_path":["foo",1,"foo/bar",1,"foo/bar/baz",1]
> > },
> > "facet_ranges":{ },
> > "facet_intervals":{ },
> > "facet_heatmaps":{ }
> > }
> > ```
> >
> > Regards,
> > Mingchun
> >
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
facet.method=enum is required when using PathHierarchyTokenizer for facet.field in Solr 9.8
Hi,
Why does faceting not work in Solr 9.8 when using PathHierarchyTokenizer
for facet.field without specifying the facet.method=enum parameter?
Here are the details:
- fieldType
```xml
```
- field
```xml
```
- index data
```json
[
{
"id": "1",
"category_path": "foo/bar/baz"
}
]
```
- query without facet.method=enum
```bash
curl "
http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path
"
```
```json
"facet_counts":{
"facet_queries":{ },
"facet_fields":{
"category_path":[ ]
},
"facet_ranges":{ },
"facet_intervals":{ },
"facet_heatmaps":{ }
}
```
- query with facet.method=enum
```bash
curl "
http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path&facet.method=enum
"
```
```json
"facet_counts":{
"facet_queries":{ },
"facet_fields":{
"category_path":["foo",1,"foo/bar",1,"foo/bar/baz",1]
},
"facet_ranges":{ },
"facet_intervals":{ },
"facet_heatmaps":{ }
}
```
Regards,
Mingchun
facet.method=enum is required when using PathHierarchyTokenizer for facet.field in Solr 9.8
Hi,
Why does faceting not work in Solr 9.8 when using PathHierarchyTokenizer
for facet.field without specifying the facet.method=enum parameter?
Here are the details:
- fieldType
```xml
```
- field
```xml
```
- index data
```json
[
{
"id": "1",
"category_path": "foo/bar/baz"
}
]
```
- query without facet.method=enum
```bash
curl "
http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path
"
```
```json
"facet_counts":{
"facet_queries":{ },
"facet_fields":{
"category_path":[ ]
},
"facet_ranges":{ },
"facet_intervals":{ },
"facet_heatmaps":{ }
}
```
- query with facet.method=enum
```bash
curl "
http://localhost:8983/solr/core/select?q=*:*&facet=true&facet.field=category_path&facet.method=enum
"
```
```json
"facet_counts":{
"facet_queries":{ },
"facet_fields":{
"category_path":["foo",1,"foo/bar",1,"foo/bar/baz",1]
},
"facet_ranges":{ },
"facet_intervals":{ },
"facet_heatmaps":{ }
}
```
Regards,
Mingchun
Re: Upgrade issues 9.1 to 9.7
Hi, Have you checked that the date/time of all six servers are 100% in sync? Have you read through the Upgrade Notes for all 9.x versions to figure out if you need to take special precaution during rolling upgrade between those versions? The PKI auth method is used for internal traffic betwen nodes, such as leg 2 of a distributed request. The nodes involved will exhange PKI key information and part of the protocol is time sensitive. It is likely that the keys change during the upgrade too, but I'm not sure how the nodes handle retrying of key exhange. In any event it is strange that even after a rollback the problems would persist. There could be recoveries going on adding load to the cluster, just a guess. Jan > 5. feb. 2025 kl. 11:09 skrev Joe Jones (DHCW - Software Development) > : > > Really could do with some insight on this. > > One of the nodes on the server reports constant connection errors in and out. > > I see things like: > 2025-02-05 10:03:47.518 WARN (qtp1959239586-70) [] > o.a.s.h.a.AdminHandlersProxy Exception when fetching result from node > GIG01SRVWCRSOL1:18983_solr => java.util.concurrent.ExecutionException: > org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: > Error from server at http://GIG01SRVWCRSOL1:18983/solr: Expected mime type > application/octet-stream but got text/html. > > > Error 401 Expired key request timestamp, elapsed=11518 > > HTTP ERROR 401 Expired key request timestamp, elapsed=11518 > > URI:/solr/admin/metrics > STATUS:401 > MESSAGE:Expired key request timestamp, > elapsed=11518 > SERVLET:default > > > > > > at java.base/java.util.concurrent.FutureTask.report(Unknown Source) > java.util.concurrent.ExecutionException: > org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException: > Error from server at http://GIG01SRVWCRSOL1:18983/solr: Expected mime type > application/octet-stream but got text/html. > > > Error 401 Expired key request timestamp, elapsed=11518 > > HTTP ERROR 401 Expired key request timestamp, elapsed=11518 > > URI:/solr/admin/metrics > STATUS:401 > MESSAGE:Expired key request timestamp, > elapsed=11518 > SERVLET:default > > -Original Message- > From: Joe Jones (DHCW - Software Development) > > Sent: 04 February 2025 15:50 > To: users@solr.apache.org > Subject: Upgrade issues 9.1 to 9.7 > > WARNING: This email originated from outside of NHS Wales. Do not open links > or attachments unless you know the content is safe. > > > Hello all, > > I attempted a rolling upgrade of our Solr Cloud Windows based installation > today from version 9.1 to 9.7. > We have 12 shards split across 2 data centers with 3 servers in each. > > After the first upgrade I noticed the admin GUI was not responding properly, > mostly a blank page with a spinning wheel in the corner. The query engine > underneath appeared fine but the admin panels were slow at best to respond. > > The errors seen were around "PKIAuthenticationPlugin": > Expired key request timestamp > Exception trying to get public key from: (http://SERVER NAME HERE) Key is > null when attempting to validate signature Could not validate PKI header > > We have basic authentication enabled. > > I rolled back the upgrade on the server and still see issues with > responsiveness for the nodes (restarted the vm a couple of times). > Other nodes reporting "Timeout when fetching result from node " against the > server the upgrade was attempted on. > > We did upgrade a small SIT environment but that was from 9.2 to 9.7. > > Any advice on how to clear this residual issue out and what can be done for a > future upgrade? > > Thanks. > > Joe. > > Rydym yn croesawu derbyn gohebiaeth yn Gymraeg. Byddwn yn ateb y fath > ohebiaeth yn Gymraeg ac ni fydd hyn yn arwain at oedi. > We welcome receiving correspondence in Welsh. We will reply to such > correspondence in Welsh and this will not lead to a delay.
Re: Alertmanager or grafana rules for solr core state not firing
Hi,
Have a look at https://issues.apache.org/jira/browse/SOLR-15767 and assiciated
PR which proposes some common alerting rules.
Jan
> 4. feb. 2025 kl. 17:08 skrev Afroz, Neshat (NIH/NLM/NCBI) [C]
> :
>
> Hello
>
> I am setting up solr monitoring using Prometheus, solr-exporter and Grafana.
> I also went ahead and installed alertmanager. Now my collection clusterstatus
> looks as below:
>
>
> curl -u "solradmin:x"
> 'http://host01:8940/solr/admin/collections?action=CLUSTERSTATUS&wt=json&indent=true'
> {
> "responseHeader":{
>"status":0,
>"QTime":1
> },
> "cluster":{
>"collections":{
> "test_coll1":{
>"pullReplicas":0,
>"configName":"test_coll1",
>"replicationFactor":1,
>"router":{
> "name":"compositeId"
>},
>"nrtReplicas":1,
>"tlogReplicas":0,
>"shards":{
> "shard1":{
>"range":"8000-7fff",
>"state":"active",
>"stateTimestamp":"1733764681612235673",
>"replicas":{
> "core_node2":{
>"core":"test_coll1_shard1_replica_n1",
>"node_name":"host01:8940_solr",
>"type":"NRT",
>"state":"active",
>"leader":"true",
>"force_set_state":"false",
>"base_url":http://host01:8940/solr
> }
>},
>"health":"GREEN"
> }
>},
>"health":"GREEN",
>"znodeVersion":39,
>"creationTimeMillis":1733764591523
> },
> "test_coll2":{
>"pullReplicas":0,
>"configName":"test_coll2",
>"replicationFactor":1,
>"router":{
> "name":"compositeId"
>},
>"nrtReplicas":1,
>"tlogReplicas":0,
>"shards":{
> "shard1":{
>"range":"8000-7fff",
>"state":"active",
>"stateTimestamp":"1733765402371289174",
>"replicas":{
> "core_node2":{
>"core":"test_coll2_shard1_replica_n1",
>"node_name":"host01:8940_solr",
>"type":"NRT",
>"state":"active",
>"leader":"true",
>"force_set_state":"false",
>"base_url":http://host01:8940/solr
> }
>},
>"health":"GREEN"
> }
>},
>"health":"GREEN",
>"znodeVersion":39,
>"creationTimeMillis":1733765317706
> }
>},
>"live_nodes":["host01:8940_solr"]
> }
> }
>
>
> I am looking to get alerted when the state of core changes. As per
> https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-node-management.html#clusterstatus
> I can have 4 states i.e. red, orange, yellow and green. I am looking to
> setup an alert for the same either through Grafana or alertmanager to be
> emailed when either of these states happen.
>
> I have the below entry in rules.yml in Prometheus:
> # Alert for collection core status solr_collections_shard_state
> - alert: SolrCoreDown
># Condition for alerting
>expr: solr_collections_shard_state < 1.00
>for: 1m
># Annotation - additional informational labels to store more information
>annotations:
> summary: "Solr shard {{ $labels.collection }}-{{ $labels.shard }} is
> down"
> description: "The Solr shard {{ $labels.collection }}-{{ $labels.shard
> }} has been in a non-active state for 1 minutes."
>
> I don't get alerted with the above rule. I assume that it would be the same
> expression or query that can be used in Grafana as well. I would appreciate
> guidance with writing the rule/query above either in alertmanager or Grafana
> to get the desired alerts.
>
> Thanks
Deprecating ExternalFileField
FYI I plan to deprecate ExternalFileField for removal in Solr 10 https://issues.apache.org/jira/browse/SOLR-17655 It's been obsolete for many years. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
