Number of records processed in logstash - elasticsearch

We're using logstash to sync Elastic search and we've around 3 million documents. It takes 3 to 4 hours to sync. Currently all we get is, it is started and stopped. Is there any way to see how many records processed in logstash ?

If you're using Logstash 5 and higher, the Logstash Monitoring API can help you. You can see and monitor what's happening inside Logstash as it processes events. If you hit the Pipeline stats API you'll get the total number of processed events per stage and plugin (input/filter/output):
curl -XGET 'localhost:9600/_node/stats/pipelines?pretty'
You'll get this type of response in which you can clearly see at any time how many events have been processed:
{
"pipelines" : {
"test" : {
"events" : {
"duration_in_millis" : 365495,
"in" : 216485,
"filtered" : 216485,
"out" : 216485,
"queue_push_duration_in_millis" : 342466
},
"plugins" : {
"inputs" : [ {
"id" : "35131f351e2dc5ed13ee04265a8a5a1f95292165-1",
"events" : {
"out" : 216485,
"queue_push_duration_in_millis" : 342466
},
"name" : "beats"
} ],
"filters" : [ {
"id" : "35131f351e2dc5ed13ee04265a8a5a1f95292165-2",
"events" : {
"duration_in_millis" : 55969,
"in" : 216485,
"out" : 216485
},
"failures" : 216485,
"patterns_per_field" : {
"message" : 1
},
"name" : "grok"
}, {
"id" : "35131f351e2dc5ed13ee04265a8a5a1f95292165-3",
"events" : {
"duration_in_millis" : 3326,
"in" : 216485,
"out" : 216485
},
"name" : "geoip"
} ],
"outputs" : [ {
"id" : "35131f351e2dc5ed13ee04265a8a5a1f95292165-4",
"events" : {
"duration_in_millis" : 278557,
"in" : 216485,
"out" : 216485
},
"name" : "elasticsearch"
} ]
},
"reloads" : {
"last_error" : null,
"successes" : 0,
"last_success_timestamp" : null,
"last_failure_timestamp" : null,
"failures" : 0
},
"queue" : {
"type" : "memory"
}
}
}

Related

Error in elasticsearch: Invalid snapshot name snapshot with the same name already in-progress

I have a problem.
I want to store an index that is in elasticsearch. I created a new repository for this and this repository does not have any snapshots. But when I ran the code blog below, it returned me the error message "Invalid snapshot name snapshot with the same name already in-progress ". How can I fix this problem?
I created a new repository with the following code block:
PUT /_snapshot/backup_repository
{
"type": "fs",
"settings": {
"compress" : "true",
"location": "C:/backups/backup_my_index"
}
}
just to be sure i used the code block below and the query returned me this result:
GET /_snapshot/backup_repository/_status
result:
{
"snapshots" : [ ]
}
I wanted to make a backup with the following code block:
PUT /_snapshot/backup_repository/my_snapshot?wait_for_completion=true
{
"indices": "my_index",
"ignore_unavailable": true,
"include_global_state": false,
"metadata": {
"taken_by": "busra duygu",
"taken_because": "backup for my_index"
}
}
Error :
{
"error" : {
"root_cause" : [
{
"type" : "invalid_snapshot_name_exception",
"reason" : "[backup_repository:my_snapshot] Invalid snapshot name [my_snapshot], snapshot with the same name is already in-progress"
}
],
"type" : "invalid_snapshot_name_exception",
"reason" : "[backup_repository:my_snapshot] Invalid snapshot name [my_snapshot], snapshot with the same name is already in-progress"
},
"status" : 400
}
I would be very happy if you could help me.
To see if there is a snapshot that already exist with this name
GET /_snapshot/backup_repository/_all
You will also get the state of it (SUCCESS/FAILED,...)
#ExploZe
As you said i ran this query and it returned me the following result.
Query:
GET /_snapshot/backup_repository/_all
Result:
{
"snapshots" : [
{
"snapshot" : "my_snapshot",
"uuid" : "4Sv055VjQDSZvpBqSvCxpg",
"version_id" : 7100199,
"version" : "7.10.1",
"indices" : [
"my_index"
],
"data_streams" : [ ],
"include_global_state" : false,
"metadata" : {
"taken_by" : "busra duygu",
"taken_because" : "backup for my_index"
},
"state" : "IN_PROGRESS",
"start_time" : "2021-09-09T06:22:16.414Z",
"start_time_in_millis" : 1631168536414,
"end_time" : "1970-01-01T00:00:00.000Z",
"end_time_in_millis" : 0,
"duration_in_millis" : 0,
"failures" : [ ],
"shards" : {
"total" : 0,
"failed" : 0,
"successful" : 0
}
}
]
}

Elasticsearch ILM not rolling

I have configured my ILM to rollover when the indice size be 20GB or after passing 30 days in the hot node
but my indice passed 20GB and still didn't pass to the cold node
and when I run: GET _cat/indices?v I get:
green open packetbeat-7.9.2-2020.10.22-000001 RRAnRZrrRZiihscJ3bymig 10 1 63833049 0 44.1gb 22gb
Could you tell me how to solve that please !
Knowing that in my packetbeat file configuration, I have just changed the number of shards:
setup.template.settings:
index.number_of_shards: 10
index.number_of_replicas: 1
when I run the command GET packetbeat-7.9.2-2020.10.22-000001/_settings I get this output:
{
"packetbeat-7.9.2-2020.10.22-000001" : {
"settings" : {
"index" : {
"lifecycle" : {
"name" : "packetbeat",
"rollover_alias" : "packetbeat-7.9.2"
},
"routing" : {
"allocation" : {
"include" : {
"_tier_preference" : "data_content"
}
}
},
"mapping" : {
"total_fields" : {
"limit" : "10000"
}
},
"refresh_interval" : "5s",
"number_of_shards" : "10",
"provided_name" : "<packetbeat-7.9.2-{now/d}-000001>",
"max_docvalue_fields_search" : "200",
"query" : {
"default_field" : [
"message",
"tags",
"agent.ephemeral_id",
"agent.id",
"agent.name",
"agent.type",
"agent.version",
"as.organization.name",
"client.address",
"client.as.organization.name",
and the output of the command GET /packetbeat-7.9.2-2020.10.22-000001/_ilm/explain is :
{
"indices" : {
"packetbeat-7.9.2-2020.10.22-000001" : {
"index" : "packetbeat-7.9.2-2020.10.22-000001",
"managed" : true,
"policy" : "packetbeat",
"lifecycle_date_millis" : 1603359683835,
"age" : "15.04d",
"phase" : "hot",
"phase_time_millis" : 1603359684332,
"action" : "rollover",
"action_time_millis" : 1603360173138,
"step" : "check-rollover-ready",
"step_time_millis" : 1603360173138,
"phase_execution" : {
"policy" : "packetbeat",
"phase_definition" : {
"min_age" : "0ms",
"actions" : {
"rollover" : {
"max_size" : "50gb",
"max_age" : "30d"
}
}
},
"version" : 1,
"modified_date_in_millis" : 1603359683339
}
}
}
}
It's weird that it's 50GB !!
Thanks for your help
So I found the solution of this problem.
After updating the policy, I removed the policy from the index using it, and then added it again to those index.

Couldn't find any Elasticsearch data

when I start kibana and looking in the management tab it is displaying a message
Couldn't find any Elasticsearch data
You'll need to index some data into Elasticsearch before you can create an index pattern
These are the data which are displayed in my elasticsearch cluster through the browser
http://localhost:9200/_cat/indices?v
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open .kibana-event-log-7.9.3-000001 JBL1C589TZWBEIjhe63f1w 1 0 3 0 16.2kb 16.2kb
green open .apm-custom-link nqIKOV7rR8OhzG4Y6UntSA 1 0 0 0 208b 208b
green open .kibana_task_manager_1 3RbGcb5nTrelAfjr8cQ8Gg 1 0 6 38 150.3kb 150.3kb
green open .apm-agent-configuration llIcAZAGTWanNghptfymVQ 1 0 0 0 208b 208b
green open .kibana_1 tMQMj0UdRd-sCZPb631Y5g 1 0 23 9 10.4mb 10.4mb
I can not see logstash index and logstash is running under port 9600
http://localhost:9600/
{"host":"DESKTOP","version":"7.9.3","http_address":"127.0.0.1:9600","id":"b92c8d86-6159-4821-9ace-01bd5328f6af","name":"DESKTOP-MTG14LM","ephemeral_id":"4332a47b-ad63-4e02-a02e-5c233d7a3773","status":"green","snapshot":false,"pipeline":{"workers":4,"batch_size":125,"batch_delay":50},"build_date":"2020-10-16T12:25:47Z","build_sha":"d296f0087bdce367c37596241d5a1f00c9279193","build_snapshot":false}
logstash-sample.conf
input {
file{
type => "syslog"
path => ["D:\Spring Boot Project\demo-gradle\another-log.log"]
}
output {
stdout{
codec => rubydebug
}
elasticsearch {
hosts => ["http://localhost:9200"]
index => "%{[#metadata][beat]}-%{[#metadata][version]}-%{+YYYY.MM.dd}"
#user => "elastic"
#password => "changeme"
}
}
kindly support me to resolve this issue
http://localhost:9600/_node/stats/?pretty
{
"host" : "DESKTOP",
"version" : "7.9.3",
"http_address" : "127.0.0.1:9600",
"id" : "b92c8d86-6159-4821-9ace-01bd5328f6af",
"name" : "DESKTOP",
"ephemeral_id" : "15e38fba-b37a-4b7d-9e58-6a89e2082799",
"status" : "green",
"snapshot" : false,
"pipeline" : {
"workers" : 4,
"batch_size" : 125,
"batch_delay" : 50
},
"jvm" : {
"threads" : {
"count" : 30,
"peak_count" : 32
},
"mem" : {
"heap_used_percent" : 24,
"heap_committed_in_bytes" : 1038876672,
"heap_max_in_bytes" : 1038876672,
"heap_used_in_bytes" : 255060960,
"non_heap_used_in_bytes" : 174032152,
"non_heap_committed_in_bytes" : 196833280,
"pools" : {
"old" : {
"max_in_bytes" : 724828160,
"peak_max_in_bytes" : 724828160,
"used_in_bytes" : 125286040,
"committed_in_bytes" : 724828160,
"peak_used_in_bytes" : 226688920
},
"young" : {
"max_in_bytes" : 279183360,
"peak_max_in_bytes" : 279183360,
"used_in_bytes" : 102941904,
"committed_in_bytes" : 279183360,
"peak_used_in_bytes" : 279183360
},
"survivor" : {
"max_in_bytes" : 34865152,
"peak_max_in_bytes" : 34865152,
"used_in_bytes" : 26833016,
"committed_in_bytes" : 34865152,
"peak_used_in_bytes" : 34865144
}
}
},
"gc" : {
"collectors" : {
"old" : {
"collection_time_in_millis" : 713,
"collection_count" : 4
},
"young" : {
"collection_time_in_millis" : 501,
"collection_count" : 8
}
}
},
"uptime_in_millis" : 815971
},
"process" : {
"open_file_descriptors" : -1,
"peak_open_file_descriptors" : -1,
"max_file_descriptors" : -1,
"mem" : {
"total_virtual_in_bytes" : -1
},
"cpu" : {
"total_in_millis" : -1,
"percent" : -3,
"load_average" : null
}
},
"events" : {
"in" : 0,
"filtered" : 0,
"out" : 0,
"duration_in_millis" : 0,
"queue_push_duration_in_millis" : 0
},
"pipelines" : {
"main" : {
"events" : {
"queue_push_duration_in_millis" : 0,
"out" : 0,
"duration_in_millis" : 0,
"in" : 0,
"filtered" : 0
},
"plugins" : {
"inputs" : [ {
"id" : "09ae4aa0701a92b926aee6c9c0abef34b22fe75695ed89371fb40e0ce5666067",
"name" : "file",
"events" : {
"queue_push_duration_in_millis" : 0,
"out" : 0
}
} ],
"codecs" : [ {
"id" : "plain_09312af1-ced8-4a87-8be0-7425fe846651",
"name" : "plain",
"encode" : {
"writes_in" : 0,
"duration_in_millis" : 0
},
"decode" : {
"out" : 0,
"writes_in" : 0,
"duration_in_millis" : 0
}
}, {
"id" : "rubydebug_88397be3-dcbe-4553-a788-aa3d4474e141",
"name" : "rubydebug",
"encode" : {
"writes_in" : 0,
"duration_in_millis" : 3
},
"decode" : {
"out" : 0,
"writes_in" : 0,
"duration_in_millis" : 0
}
}, {
"id" : "plain_497bb40b-2eab-4852-a002-e2c7ee4d7ab3",
"name" : "plain",
"encode" : {
"writes_in" : 0,
"duration_in_millis" : 0
},
"decode" : {
"out" : 0,
"writes_in" : 0,
"duration_in_millis" : 0
}
} ],
"filters" : [ ],
"outputs" : [ {
"id" : "e48f703a97c1645df3afa1d1b8937faffe8a408694f8a6ba5be6bb23bed53001",
"name" : "stdout",
"events" : {
"out" : 0,
"in" : 0,
"duration_in_millis" : 33
}
}, {
"id" : "ad540803354821020198353da7d7314b73309c07babecea3df737a197017449a",
"name" : "elasticsearch",
"events" : {
"out" : 0,
"in" : 0,
"duration_in_millis" : 4
}
} ]
},
"reloads" : {
"failures" : 0,
"successes" : 0,
"last_success_timestamp" : null,
"last_error" : null,
"last_failure_timestamp" : null
},
"queue" : {
"type" : "memory",
"events_count" : 0,
"queue_size_in_bytes" : 0,
"max_queue_size_in_bytes" : 0
},
"hash" : "661080585b2691f01bac24b363c27f0cfc03a009fbb302424abe96cc1ae50fb5",
"ephemeral_id" : "faf3face-77dc-455f-8632-1ff2e1ebdd7c"
}
},
"reloads" : {
"failures" : 0,
"successes" : 0
},
"os" : { },
"queue" : {
"events_count" : 0
}
bin/logstash --log.level debug
[2020-11-16T21:59:20,627][DEBUG][logstash.runner ] monitoring.elasticsearch.hosts: ["http://localhost:9200"]
[2020-11-16T21:59:20,630][DEBUG][logstash.runner ] monitoring.collection.interval: #<LogStash::Util::TimeValue:0xa362681 #duration=10, #time_unit=:second>
[2020-11-16T21:59:20,635][DEBUG][logstash.runner ] monitoring.collection.timeout_interval: #<LogStash::Util::TimeValue:0x228ca300 #duration=10, #time_unit=:minute>
[2020-11-16T21:59:20,637][DEBUG][logstash.runner ] monitoring.elasticsearch.username: "logstash_system"
[2020-11-16T21:59:20,639][DEBUG][logstash.runner ] monitoring.elasticsearch.ssl.verification_mode: "certificate"
[2020-11-16T21:59:20,640][DEBUG][logstash.runner ] monitoring.elasticsearch.sniffing: false
[2020-11-16T21:59:20,641][DEBUG][logstash.runner ] monitoring.collection.pipeline.details.enabled: true
[2020-11-16T21:59:20,643][DEBUG][logstash.runner ] monitoring.collection.config.enabled: true
[2020-11-16T21:59:20,644][DEBUG][logstash.runner ] node.uuid: ""
[2020-11-16T21:59:20,645][DEBUG][logstash.runner ] --------------- Logstash Settings -------------------
[2020-11-16T21:59:20,711][DEBUG][logstash.config.source.multilocal] Reading pipeline configurations from YAML {:location=>"D:/ELK stack/logstash/config/pipelines.yml"}
ERROR: Pipelines YAML file is empty. Location: D:/ELK stack/logstash/config/pipelines.yml
usage:
bin/logstash -f CONFIG_PATH [-t] [-r] [] [-w COUNT] [-l LOG]
bin/logstash --modules MODULE_NAME [-M "MODULE_NAME.var.PLUGIN_TYPE.PLUGIN_NAME.VARIABLE_NAME=VALUE"] [-t] [-w COUNT] [-l LOG]
bin/logstash -e CONFIG_STR [-t] [--log.level fatal|error|warn|info|debug|trace] [-w COUNT] [-l LOG]
bin/logstash -i SHELL [--log.level fatal|error|warn|info|debug|trace]
bin/logstash -V [--log.level fatal|error|warn|info|debug|trace]
bin/logstash --help
[2020-11-16T21:59:20,755][ERROR][org.logstash.Logstash ] java.lang.IllegalStateException: Logstash stopped processing because of an error: (SystemExit) exit
bin/logstash --log.level debug -f config/logstash-sample.conf
[2020-11-16T22:11:31,227][DEBUG][filewatch.sincedbcollection][main][09ae4aa0701a92b926aee6c9c0abef34b22fe75695ed89371fb40e0ce5666067] writing sincedb (delta since last write = 15)
[2020-11-16T22:11:32,314][DEBUG][logstash.instrument.periodicpoller.cgroup] One or more required cgroup files or directories not found: /proc/self/cgroup, /sys/fs/cgroup/cpuacct, /sys/fs/cgroup/cpu
[2020-11-16T22:11:32,678][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ParNew"}
[2020-11-16T22:11:32,679][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ConcurrentMarkSweep"}
[2020-11-16T22:11:34,964][DEBUG][org.logstash.execution.PeriodicFlush][main] Pushing flush onto pipeline.
[2020-11-16T22:11:37,330][DEBUG][logstash.instrument.periodicpoller.cgroup] One or more required cgroup files or directories not found: /proc/self/cgroup, /sys/fs/cgroup/cpuacct, /sys/fs/cgroup/cpu
[2020-11-16T22:11:37,691][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ParNew"}
[2020-11-16T22:11:37,692][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ConcurrentMarkSweep"}
[2020-11-16T22:11:39,964][DEBUG][org.logstash.execution.PeriodicFlush][main] Pushing flush onto pipeline.
[2020-11-16T22:11:42,336][DEBUG][logstash.instrument.periodicpoller.cgroup] One or more required cgroup files or directories not found: /proc/self/cgroup, /sys/fs/cgroup/cpuacct, /sys/fs/cgroup/cpu
[2020-11-16T22:11:42,697][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ParNew"}
[2020-11-16T22:11:42,697][DEBUG][logstash.instrument.periodicpoller.jvm] collector name {:name=>"ConcurrentMarkSweep"}
[2020-11-16T22:11:44,960][DEBUG][org.logstash.execution.PeriodicFlush][main] Pushing flush onto pipeline.
Your file input is reading from the end of the file. Try modifying your input like this (i.e. read from the beginning):
input {
file{
type => "syslog"
path => ["D:/Spring Boot Project/demo-gradle/another-log.log"]
start_position => "beginning"
}
}
And also make sure to remove this file:
D:/ELK stack/logstash/data/plugins/inputs/file/.sincedb_f8a2243b9184e26704b40adf1d7ef6af
Thank You Val for your answer. In my case, windows has been used as an OS. So the backslash which is used to route the log path should be replaced with the forward slash.
logstash-sample.conf
input {
file{
path => [ "D:/Spring Boot Project/demo-gradle/another-log.log" ]
start_position => "beginning"
}
}
output {
stdout{
codec => rubydebug
}
elasticsearch {
hosts => ["http://localhost:9200"]
}
}

Problem with Elasticsearch Index Lifecycle Policy that doesn't rollover

In order to evaluate its potential to help on our daily operations, I have deployed Elastic Search and Kibana (7.7.1 with BASIC license) and created an index template for Ntopng (our monitoring platform).
Since indexes keep growing, I want to delete Ntopng indexes older than 20 days or so, therefore I have created a life cycle policy called ntopng where the time-stamped index should rollover after 1 day (for testing purposes) and then will be deleted after 2 days of the rollover:
Next I picked a time-stamped index created that day and applied the lifecycle policy to it:
Before that, I had to create an alias for that Index, so I did it manually:
POST /_aliases
{
"actions" : [
{ "add" : { "index" : "ntopng-2020.09.09", "alias" : "ntopng_Alias" } }
]
}
All looked good after that ( I guess) as no errors or alarms were displayed:
"indices" : {
"ntopng-2020.09.09" : {
"index" : "ntopng-2020.09.09",
"managed" : true,
"policy" : "ntopng",
"lifecycle_date_millis" : 1599609600433,
"age" : "20.14h",
"phase" : "hot",
"phase_time_millis" : 1599681721821,
"action" : "rollover",
"action_time_millis" : 1599680521920,
"step" : "check-rollover-ready",
"step_time_millis" : 1599681721821,
"is_auto_retryable_error" : true,
"failed_step_retry_count" : 1,
"phase_execution" : {
"policy" : "ntopng",
"phase_definition" : {
"min_age" : "0ms",
"actions" : {
"rollover" : {
"max_age" : "1d"
},
"set_priority" : {
"priority" : 100
}
}
},
"version" : 4,
"modified_date_in_millis" : 1599509572867
}
}
My expectation was that in the next day the policy would be automatically rolled over to the next index (ntopng-2020.10.10) so that the initial index would be eventually deleted the next two days.
Instead, I got the following errors:
GET ntopng-*/_ilm/explain
{
"indices" : {
"ntopng-2020.09.09" : {
"index" : "ntopng-2020.09.09",
"managed" : true,
"policy" : "ntopng",
"lifecycle_date_millis" : 1599609600433,
"age" : "1.94d",
"phase" : "hot",
"phase_time_millis" : 1599776521822,
"action" : "rollover",
"action_time_millis" : 1599680521920,
"step" : "ERROR",
"step_time_millis" : 1599777121822,
"failed_step" : "check-rollover-ready",
"is_auto_retryable_error" : true,
"failed_step_retry_count" : 80,
"step_info" : {
"type" : "illegal_argument_exception",
"reason" : """index name [ntopng-2020.09.09] does not match pattern '^.*-\d+$'""",
"stack_trace" : """java.lang.IllegalArgumentException: index name [ntopng-2020.09.09] does not match pattern '^.*-\d+$'
at org.elasticsearch.action.admin.indices.rollover.TransportRolloverAction.generateRolloverIndexName(TransportRolloverAction.java:241)
at org.elasticsearch.action.admin.indices.rollover.TransportRolloverAction.masterOperation(TransportRolloverAction.java:133)
at org.elasticsearch.action.admin.indices.rollover.TransportRolloverAction.masterOperation(TransportRolloverAction.java:73)
at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction.lambda$doStart$3(TransportMasterNodeAction.java:170)
at org.elasticsearch.action.ActionRunnable$2.doRun(ActionRunnable.java:73)
at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
at org.elasticsearch.common.util.concurrent.EsExecutors$DirectExecutorService.execute(EsExecutors.java:225)
at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction.doStart(TransportMasterNodeAction.java:170)
at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction.start(TransportMasterNodeAction.java:133)
at org.elasticsearch.action.support.master.TransportMasterNodeAction.doExecute(TransportMasterNodeAction.java:110)
at org.elasticsearch.action.support.master.TransportMasterNodeAction.doExecute(TransportMasterNodeAction.java:59)
at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:153)
at org.elasticsearch.xpack.security.action.filter.SecurityActionFilter.apply(SecurityActionFilter.java:123)
at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:151)
at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:129)
at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:64)
at org.elasticsearch.client.node.NodeClient.executeLocally(NodeClient.java:83)
at org.elasticsearch.client.node.NodeClient.doExecute(NodeClient.java:72)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:399)
at org.elasticsearch.xpack.core.ClientHelper.executeAsyncWithOrigin(ClientHelper.java:92)
at org.elasticsearch.xpack.core.ClientHelper.executeWithHeadersAsync(ClientHelper.java:155)
at org.elasticsearch.xpack.ilm.LifecyclePolicySecurityClient.doExecute(LifecyclePolicySecurityClient.java:51)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:399)
at org.elasticsearch.client.support.AbstractClient$IndicesAdmin.execute(AbstractClient.java:1234)
at org.elasticsearch.client.support.AbstractClient$IndicesAdmin.rolloverIndex(AbstractClient.java:1736)
at org.elasticsearch.xpack.core.ilm.WaitForRolloverReadyStep.evaluateCondition(WaitForRolloverReadyStep.java:127)
at org.elasticsearch.xpack.ilm.IndexLifecycleRunner.runPeriodicStep(IndexLifecycleRunner.java:173)
at org.elasticsearch.xpack.ilm.IndexLifecycleService.triggerPolicies(IndexLifecycleService.java:329)
at org.elasticsearch.xpack.ilm.IndexLifecycleService.triggered(IndexLifecycleService.java:267)
at org.elasticsearch.xpack.core.scheduler.SchedulerEngine.notifyListeners(SchedulerEngine.java:183)
at org.elasticsearch.xpack.core.scheduler.SchedulerEngine$ActiveSchedule.run(SchedulerEngine.java:211)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:832)
"""
},
"phase_execution" : {
"policy" : "ntopng",
"phase_definition" : {
"min_age" : "0ms",
"actions" : {
"rollover" : {
"max_age" : "1d"
},
"set_priority" : {
"priority" : 100
}
}
},
"version" : 4,
"modified_date_in_millis" : 1599509572867
}
}
"ntopng-2020.09.10" : {
"index" : "ntopng-2020.09.10",
"managed" : true,
"policy" : "ntopng",
"lifecycle_date_millis" : 1599696000991,
"age" : "22.57h",
"phase" : "hot",
"phase_time_millis" : 1599776521844,
"action" : "rollover",
"action_time_millis" : 1599696122033,
"step" : "ERROR",
"step_time_millis" : 1599777121839,
"failed_step" : "check-rollover-ready",
"is_auto_retryable_error" : true,
"failed_step_retry_count" : 67,
"step_info" : {
"type" : "illegal_argument_exception",
"reason" : "index.lifecycle.rollover_alias [ntopng_Alias] does not point to index [ntopng-2020.09.10]",
"stack_trace" : """java.lang.IllegalArgumentException: index.lifecycle.rollover_alias [ntopng_Alias] does not point to index [ntopng-2020.09.10]
at org.elasticsearch.xpack.core.ilm.WaitForRolloverReadyStep.evaluateCondition(WaitForRolloverReadyStep.java:104)
at org.elasticsearch.xpack.ilm.IndexLifecycleRunner.runPeriodicStep(IndexLifecycleRunner.java:173)
at org.elasticsearch.xpack.ilm.IndexLifecycleService.triggerPolicies(IndexLifecycleService.java:329)
at org.elasticsearch.xpack.ilm.IndexLifecycleService.triggered(IndexLifecycleService.java:267)
at org.elasticsearch.xpack.core.scheduler.SchedulerEngine.notifyListeners(SchedulerEngine.java:183)
at org.elasticsearch.xpack.core.scheduler.SchedulerEngine$ActiveSchedule.run(SchedulerEngine.java:211)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:832)
"""
},
"phase_execution" : {
"policy" : "ntopng",
"phase_definition" : {
"min_age" : "0ms",
"actions" : {
"rollover" : {
"max_age" : "1d"
},
"set_priority" : {
"priority" : 100
}
}
}
The first index error reads "index name [ntopng-2020.09.09] does not match pattern '^.*-\d+$"
while second one displays: ""index.lifecycle.rollover_alias [ntopng_Alias] does not point to index [ntopng-2020.09.10]"
Please note that I'm learning the basics on ES Index management, so I'd appreciate any clue on what the problem might be.
OK, I just found that the index name must end with a numeric pattern like 0001 and not 2020.09.09 So I may need to find an alternative way to make it work.
As per the kibana regex you can date and time pattern as well, instead of the 2020.01.01 use 2020-01-01
This should work as well. You can check the regex here : https://regex101.com/r/VclptX/1

ElasticSerach - Statistical facets on length of the list

I have the following sample mappipng:
{
"book" : {
"properties" : {
"author" : { "type" : "string" },
"title" : { "type" : "string" },
"reviews" : {
"properties" : {
"url" : { "type" : "string" },
"score" : { "type" : "integer" }
}
},
"chapters" : {
"include_in_root" : 1,
"type" : "nested",
"properties" : {
"name" : { "type" : "string" }
}
}
}
}
}
I would like to get a facet on number of reviews - i.e. length of the "reviews" array.
For instance, verbally spoken results I need are: "100 documents with 10 reviews, 20 documents with 5 reviews, ..."
I'm trying the following statistical facet:
{
"query" : {
"match_all" : {}
},
"facets" : {
"stat1" : {
"statistical" : {"script" : "doc['reviews.score'].values.size()"}
}
}
}
but it keeps failing with:
{
"error" : "SearchPhaseExecutionException[Failed to execute phase [query_fetch], total failure; shardFailures {[mDsNfjLhRIyPObaOcxQo2w][facettest][0]: QueryPhaseExecutionException[[facettest][0]: query[ConstantScore(NotDeleted(cache(org.elasticsearch.index.search.nested.NonNestedDocsFilter#a2a5984b)))],from[0],size[10]: Query Failed [Failed to execute main query]]; nested: PropertyAccessException[[Error: could not access: reviews; in class: org.elasticsearch.search.lookup.DocLookup]
[Near : {... doc[reviews.score].values.size() ....}]
^
[Line: 1, Column: 5]]; }]",
"status" : 500
}
How can I achieve my goal?
ElasticSearch version is 0.19.9.
Here is my sample data:
{
"author" : "Mark Twain",
"title" : "The Adventures of Tom Sawyer",
"reviews" : [
{
"url" : "amazon.com",
"score" : 10
},
{
"url" : "www.barnesandnoble.com",
"score" : 9
}
],
"chapters" : [
{ "name" : "Chapter 1" }, { "name" : "Chapter 2" }
]
}
{
"author" : "Jack London",
"title" : "The Call of the Wild",
"reviews" : [
{
"url" : "amazon.com",
"score" : 8
},
{
"url" : "www.barnesandnoble.com",
"score" : 9
},
{
"url" : "www.books.com",
"score" : 5
}
],
"chapters" : [
{ "name" : "Chapter 1" }, { "name" : "Chapter 2" }
]
}
It looks like you are using curl to execute your query and this curl statement looks like this:
curl localhost:9200/my-index/book -d '{....}'
The problem here is that because you are using apostrophes to wrap the body of the request, you need to escape all apostrophes that it contains. So, you script should become:
{"script" : "doc['\''reviews.score'\''].values.size()"}
or
{"script" : "doc[\"reviews.score"].values.size()"}
The second issue is that from your description it looks like your are looking for a histogram facet or a range facet but not for a statistical facet. So, I would suggest trying something like this:
curl "localhost:9200/test-idx/book/_search?search_type=count&pretty" -d '{
"query" : {
"match_all" : {}
},
"facets" : {
"histo1" : {
"histogram" : {
"key_script" : "doc[\"reviews.score\"].values.size()",
"value_script" : "doc[\"reviews.score\"].values.size()",
"interval" : 1
}
}
}
}'
The third problem is that the script in the facet will be called for every single record in the result list and if you have a lot of results it might take really long time. So, I would suggest indexing an additional field called number_of_reviews that should be populated with the number of reviews by your client. Then your query would simply become:
curl "localhost:9200/test-idx/book/_search?search_type=count&pretty" -d '{
"query" : {
"match_all" : {}
},
"facets" : {
"histo1" : {
"histogram" : {
"field" : "number_of_reviews"
"interval" : 1
}
}
}
}'

Resources