# Aggregate filter の timeout\_timestamp\_field設定時の動作について

**URL:** <https://discuss.elastic.co/t/aggregate-filter-timeout-timestamp-field/336283>\
**Category:** Logstash\
**Created:** [June 17, 2023, 4:39pm UTC](https://discuss.elastic.co/t/aggregate-filter-timeout-timestamp-field/336283 "2023-06-17T16:39:51Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Badger](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/badger/32/25190_2.png) [@Badger](https://discuss.elastic.co/u/Badger)\
**Post date:** [June 20, 2023, 9:48pm UTC](https://discuss.elastic.co/t/aggregate-filter-timeout-timestamp-field/336283/4 "2023-06-20T21:48:19Z")

</div>

> [@e-se](#):
>
> 3行目でタイムアウト判定される一方で、2行目でタイムアウト判定されない理由がどうしてもわかりません。

The second line goes through the second aggregate filter, and that does not have any timeout options set, so it does not do timeout processing. You can only have timeout options on one aggregate filter. If you try to add them to the second aggregate you will get an error.

We could change things to use a single aggregate

```
    aggregate {
        task_id => "%{taskid}"
        timeout_timestamp_field => "event_time"
        timeout_task_id_field => "taskid"
        code => '
            map["sql_duration"] ||= 0
            d = event.get("duration")
            if d
                map["sql_duration"] += d
            end
        '
        timeout => 20
        push_map_as_event_on_timeout => true
    }

```

This will trigger the timeout on the second line, but timeout processing occurs _before_ the code block executes, so the event that is created at that time will have duration set to 0. Another event created by a later timeout will have the correct value in it.

---

_[View the full topic](https://discuss.elastic.co/t/aggregate-filter-timeout-timestamp-field/336283)._