Access epoch from date field in groovy script in elastic search - elasticsearch

My orignal question is here
https://discuss.elastic.co/t/access-the-epoch-of-the-date-type-doc-in-groovy-script/53129
I need to access the stored millis(as in index) of the date in groovy script. Is this possible
Orignal Question
As per my understanding and from here [understanding how elasticsearch stores dates internally (understanding how elasticsearch stores dates internally) elastic search stores the date internally as epoch format. Now consider I need to access this epoch in groovy script and out doc date format is date_optional_time. Now when I try to access it in groovy script it gives me the formatted date(as on the time of input). Is there a way to access the epoch time here.
I have come up with three thoughts
1) Convert the doc value to date and get millis in script,
2) Create a new field with copy_to that stores the date as epoch format
3)//or if possible directly access the epoch. but how?
Can some body guide me on this.I need epoch because I need to update some other field on basis of the epoch
e.g
Consider a mapping like this
{
"createdDate": {
"type": "date",
"store": true,
"format": "dateOptionalTime"
}
"modifiedDate": {
"type": "date",
"store": true,
"format": "dateOptionalTime"
}
"daysINBetween" : {
"type" : "long"
}
,
}
Now I need to run a script that stores (createdDate.millis - modifiedDate.millis) / (24 * 60 * 60 * 1000). I don't want to create a new object of date each time, that's why I am trying to access epoch in script

Related

I need a logic for date conversion using jsonata

My json is like this
{
"Payload" :{
"Date": "",
"Date value" : "2018-12-20T00:00:00.000Z"
}
I need a logic for both if it Iso format are above date format
I write this logic for epoch time
Using toMillis but it is working only for iso
Please help me to resolve this problem

Making timestamps out of Kafka Connect Single Message Transformer

I am moving data from Kafka to Elasticsearch and using Kafka connects SMT and more specificly TimeStampConverter . I fiddled around some with it and couldnt get it to output a Timestamp format.
When I used types "Date", "Time" or "Timestamp" as the values for transforms.TimestampConverter.target.type I couldnt get data into Elasticsearch. It was only until I set the value "string" there that it outputs the values into elasticsearch as date data type. This unfortunately means that I can only get the value by accuracy of a day.
Here is the transformer configs:
"transforms": "TimestampConverter",
"transforms.TimestampConverter.type": "org.apache.kafka.connect.transforms.TimestampConverter$Value",
"transforms.TimestampConverter.field": "UPDATED",
"transforms.TimestampConverter.format": "yyyy-MM-dd",
"transforms.TimestampConverter.target.type": "string"
Any known ways how to achieve this with more accurate timestamp? I tried all kinds of configurations alterin the target.typeand format fields
The UPDATED value is epoch bigint

Reindex Elasticsearch converting unixtime to date

I have an Elasticsearch index which uses the #timestamp field to store the date in a date field.
There are many records which are missing the #timestamp field, but have a timestamp field containing a unix timestamp. (Generated from PHP, so seconds, not milliseconds)
Note, the timestamp field is of date type, but numeric data seems to be stored there.
How can I use Painless script in a reindex and set #timestamp where it is missing, IF there is a numeric timestamp field with a unix timestamp?
Here's an example record that I would want to transform.
{
"_index": "my_log",
"_type": "doc",
"_id": "AWjEkbynNsX24NVXXmna",
"_score": 1,
"_source": {
"name": null,
"pid": "148651",
"timestamp": 1549486104
}
},
Did you have a look at the ingest module of Elasticsearch??
https://www.elastic.co/guide/en/elasticsearch/reference/current/date-processor.html
Parses dates from fields, and then uses the date or timestamp as the
timestamp for the document. By default, the date processor adds the
parsed date as a new field called #timestamp. You can specify a
different field by setting the target_field configuration parameter.
Multiple date formats are supported as part of the same date processor
definition. They will be used sequentially to attempt parsing the date
field, in the same order they were defined as part of the processor
definition.
It does exactly what you want :) In your reindex statement you can direct documents through this ingest processor.
If you need more help let me know, then I can jump behind a computer and help out :D

Retrieve string date and long date from query result

I have a date field defined in index as
"_reportDate": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
and I have a query to query from _source field which gives _reportDate field in string of 2015-12-05 01:05:00.
I can't seems to find a way to get date in different date format during query retrieval apart from using script field (which is not preferable). From what I understand a date field will be parse to long value to be indexed in elastic search, can we retrieve the long value as well during elasticsearch query?
You need to store the field and at search time ask for this stored field.
If it does not work you can always apply the script at index time with ingest feature and a script processor.

Logstash inserting dates as strings instead of dateOptionalTime

I have an Elasticsearch index with the following mapping:
"pickup_datetime": {
"type": "date",
"format": "dateOptionalTime"
}
Here is an example of a date contained in the file that is being read in
"pickup_datetime": "2013-01-07 06:08:51"
I am using Logstash to read and insert data into ES with the following lines to attempt to convert the date string into the date type.
date {
match => [ "pickup_datetime", "yyyy-MM-dd HH:mm:ss" ]
target => "pickup_datetime"
}
But the match never seems to occur.
What am I doing wrong?
It turns out the date filter was before the csv filter, where the columns get named, hence the date filter was not finding the pickup_datetime column since it had not yet been named.
It might be a good idea to clearly mention the sequentiality of the filters in the documentation to avoid others having similar problems in the future.

Resources