# Why don't Elastic Agent Integrations Leverage @timestamp Sorting?

**URL:** <https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071>\
**Category:** Beats\
**Tags:** elastic-agent\
**Created:** [September 13, 2021, 12:38pm UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071 "2021-09-13T12:38:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![BenB196](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benb196/32/83401_2.png) [@BenB196](https://discuss.elastic.co/u/BenB196)\
**Post date:** [September 13, 2021, 12:38pm UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071/1 "2021-09-13T12:38:38Z")

</div>

Hi All,

I was doing some research into some possible search performance tuning within my cluster, and I noticed that the Elastic Agent integrations don't leverage sorting the index on `@timestamp`. In release 7.6, Elastic made a big deal on the [performance advances](https://www.elastic.co/blog/elasticsearch-7-6-0-released#perf) they made when using sorting on date fields. While I understand that at the time this wasn't easily implementable, since beats exist, and since they all used the same index, and with the limitations of sorting (can't use nested fields), this would be pretty much impossible; with the implementation of Integrations and data streams, why hasn't `@timestamp` been applied at the individual data stream level?

While I don't have any real performance numbers to determine whether the trade-off of implementing sorting on `@timestamp` is worth it, I'm more just curious if this has even been considered for Integrations?

---

<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 15, 2021, 7:16am UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071/2 "2021-09-15T07:16:00Z")

</div>

Hi @BenB196 Thanks for bringing this up. We are indeed running quite a few benchmarks around exactly this problem and plan to follow up on the data streams to get all the benefits of it.

@jpountz I tried to find a related issue maybe you can help linking to a public on?

---

<div class="post-metadata">

**Author:** ![jpountz](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jpountz/32/45836_2.png) [@jpountz](https://discuss.elastic.co/u/jpountz)\
**Post date:** [September 15, 2021, 8:20am UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071/3 "2021-09-15T08:20:32Z")

</div>

I don't think there's a public issue about it but I can give some context.

The 7.6 performance improvements that you linked actually do not require indices to be sorted by `@timestamp`. This is a different optimization that leverages the index in order to skip over non-competitive documents. For instance if you're looking for the 10 most recent documents sorted by `@timestamp`, and you just saw 10 documents that all had a `@timestamp` that was on `2021-09-15` or later, then you can use the index to exclude all documents that have an older timestamp. This optimization only works when you don't have aggregations, so there is ongoing work on the Kibana team to update Discover to run separate requests to fetch the most recent logs and to compute the date\_histogram of matches (easy in theory, a bit less in practice, which is why it is taking some time), so that we could take advantage of this optimization.

As to whether we should sort data streams by `@timestamp` this would be a good question too. It would certainly give an even greater speedup over the aforementioned optimization. There is a trade-off there given that index sorting makes indexing a bit slower, and many of our users care a lot about their indexing rate. In my opinion this 7.6 optimization (which we iterated on since the 7.6 release), which doesn't require index sorting, is probably a good default since it should give good search performance in Discover in the future without requiring users to add index-time overhead.

---

<div class="post-metadata">

**Author:** ![BenB196](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/benb196/32/83401_2.png) [@BenB196](https://discuss.elastic.co/u/BenB196)\
**Post date:** [September 15, 2021, 5:06pm UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071/4 "2021-09-15T17:06:49Z")

</div>

Thanks @ruflin and @jpountz for the detailed explanation on the topic.

---

<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 13, 2021, 7:07pm UTC](https://discuss.elastic.co/t/why-dont-elastic-agent-integrations-leverage-timestamp-sorting/284071/5 "2021-10-13T19:07:36Z")

</div>

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