# Libbeat does not allow updates when publishing to Elasticsearch?

**URL:** <https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031>\
**Category:** Beats\
**Tags:** beats-development\
**Created:** [September 11, 2018, 12:23am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031 "2018-09-11T00:23:17Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![stoth](https://avatars.discourse-cdn.com/v4/letter/s/a698b9/32.png) [@stoth](https://discuss.elastic.co/u/stoth)\
**Post date:** [September 11, 2018, 12:23am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/1 "2018-09-11T00:23:18Z")

</div>

_NOTE: After doing additional research and managing to find the code preventing updates, I've revised this post to be more accurate and succinct._

**ISSUE** : When using the `beat.Client` to publish [bulk] `beat.Event`s to the Elasticsearch output, the client does not allow updates by way of including the document id in the `Meta` map.

Sample code:

```
	client.Publish(beat.Event{
		Fields: common.MapStr{
			"field1":	"abc",
		},
		Timestamp: time.Now(),
		Meta: common.MapStr{
			"id": "123",
		},
	})

```

The first time the document is published, it is successfully created. The second time the document is published (with updated values), an error is generated indicating "version conflict, document already exists".

I've tracked it down to this code in the `libbeat/outputs/elasticsearch/client.go`

From [version 6.4 of github.com/elastic/beats/libbeat/outputs/elasticsearch/client.go](https://github.com/elastic/beats/blob/6.4/libbeat/outputs/elasticsearch/client.go#L417)

```
417 if id != "" {
418 return bulkCreateAction{meta}, nil
419 }
420 return bulkIndexAction{meta}, nil

```

If an id is provided, the client always sends a 'create' action. If I comment out lines 417-419, I'm able to do document updates by including the document id in the `Meta` map and letting the bulk API decide whether to create the document or update it in the 'index' action as it does using the rest calls below.

```
POST _bulk
{ "index" : { "_index" : "my-test-index", "_type" : "doc", "_id" : "123" } }
{ "field1": "abc" }

{
  "took": 1650,
  "errors": false,
  "items": [
    {
      "index": {
        "_index": "my-test-index",
        "_type": "doc",
        "_id": "123",
        "_version": 1,
        "result": "created",
        "_shards": {
          "total": 2,
          "successful": 2,
          "failed": 0
        },
        "_seq_no": 0,
        "_primary_term": 1,
        "status": 201
      }
    }
  ]
}

POST _bulk
{ "index" : { "_index" : "my-test-index", "_type" : "doc", "_id" : "123" } }
{ "field1": "xyz" }

{
  "took": 76,
  "errors": false,
  "items": [
    {
      "index": {
        "_index": "my-test-index",
        "_type": "doc",
        "_id": "123",
        "_version": 2,
        "result": "updated",
        "_shards": {
          "total": 2,
          "successful": 2,
          "failed": 0
        },
        "_seq_no": 1,
        "_primary_term": 1,
        "status": 200
      }
    }
  ]
}

```

**My question is, is this a bug or a feature?**

Is it a feature, meaning was there some rationale behind the client preventing [bulk] updates such as the order in which updates to the same document would be applied could not be guaranteed [to be the same as the order in which they were published]? Or is it a bug, possibly due to old code that made sense based on the supported features of previous versions?

I'd like to be able to take advantage of the Bulk API's ability to do upserts via the 'index' action using the beat.Client, but would like to understand if it was prevented for a still-valid reason prior to submitting an Issue against elastic/beats.

Thanks.

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [September 25, 2018, 6:47am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/2 "2018-09-25T06:47:28Z")

</div>

So far Beats is focused on time series which means each event is only written once and then not updated anymore. So it could be said it's by design or the reason we never hit this issue.

Can you share a bit more on the Beat you are writing and why you need to overwrite documents?

---

<div class="post-metadata">

**Author:** ![stoth](https://avatars.discourse-cdn.com/v4/letter/s/a698b9/32.png) [@stoth](https://discuss.elastic.co/u/stoth)\
**Post date:** [September 27, 2018, 8:15pm UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/3 "2018-09-27T20:15:01Z")

</div>

Thank you for your response.

Basically I have two use cases which require the data. The first, which has a higher priority need to access the data, only ever needs the latest event values. The second, which is more in line with typical time series use cases, queries across time ranges and all events are needed.

Indices can have anywhere from several hundred thousand events to roughly a hundred million per day. However, the largest index only has a couple thousand distinct events, but will have fifty to a hundred million events for the day.

Querying the indices as part of the first use case needs to be very efficient (sub second). Using time sorted indices, some of the queries, all of which typically have 1 nested aggregation (2 levels, one to aggregate by the uniqueness criteria, and the other to get the latest hit with the few fields needed), were taking 9-10 seconds or more at times. Moving to a dual index model, one index having all events for the day, and the other using updates to only keep the latest version of the event, the same queries execute against the "latest event" index in several milliseconds.

I'm aware I could do something similar in Logstash, taking a single record and publishing it to the 2 different indices. However, that also requires introducing another moving part in to the architecture, including another hop between the beat and Elasticsearch, as well as another component of the system requiring resources. Simply allowing the updates from libbeat eliminates the need to introduce Logstash to the architecture (granted, I may still need Logstash if there's no guarantee of indexing order of the bulk events).

---

<div class="post-metadata">

**Author:** ![ruflin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ruflin/32/3116_2.png) [@ruflin](https://discuss.elastic.co/u/ruflin)\
**Post date:** [October 1, 2018, 7:10am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/4 "2018-10-01T07:10:49Z")

</div>

Basically what you would need from libbeat is that in case you define the id on your end that we overwrite and document with a new version instead of returning an error. Could you open a feature request for this on Github? I'm pretty sure there is more to it on our end but having a Github issue will also bring visibility to it for other engineers.

---

<div class="post-metadata">

**Author:** ![stoth](https://avatars.discourse-cdn.com/v4/letter/s/a698b9/32.png) [@stoth](https://discuss.elastic.co/u/stoth)\
**Post date:** [October 2, 2018, 4:09am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/5 "2018-10-02T04:09:03Z")

</div>

Thank you. I have submitted a feature request per your suggestion.

[https://github.com/elastic/beats/issues/8534](https://github.com/elastic/beats/issues/8534)

Regards.

-Steve

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 30, 2018, 4:09am UTC](https://discuss.elastic.co/t/libbeat-does-not-allow-updates-when-publishing-to-elasticsearch/148031/6 "2018-10-30T04:09:06Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
