# Winlogbeat 7.13.0 expected int but got type string in equals condition

**URL:** <https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273>\
**Category:** Beats\
**Tags:** winlogbeat\
**Created:** [May 27, 2021, 11:05pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273 "2021-05-27T23:05:31Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![VamPikmin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vampikmin/32/22367_2.png) [@VamPikmin](https://discuss.elastic.co/u/VamPikmin)\
**Post date:** [May 27, 2021, 11:05pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/1 "2021-05-27T23:05:31Z")

</div>

I've upgraded to the latest version and winlogbeat is not sending data anymore

The changes in 7.13.0  
Change event.code and winlog.event\_id from int to keyword.

I'm seeing a lot of these  
WARN [conditions] conditions/equals.go:37 expected int but got type string in equals condition

```
2021-05-28T08:59:23.109+1000 INFO instance/beat.go:665 Home path: [C:\Program Files\Winlogbeat] Config path: [C:\Program Files\Winlogbeat] Data path: [C:\Program Files\Winlogbeat\data] Logs path: [C:\Program Files\Winlogbeat\logs]
2021-05-28T08:59:23.109+1000 DEBUG [beat] instance/beat.go:723 Beat metadata path: C:\Program Files\Winlogbeat\data\meta.json
2021-05-28T08:59:23.113+1000 INFO instance/beat.go:673 Beat ID: 6e3f6db3-8cb0-4044-a283-e9e4de7b8c7f
2021-05-28T08:59:23.117+1000 DEBUG [add_cloud_metadata] add_cloud_metadata/providers.go:128 add_cloud_metadata: starting to fetch metadata, timeout=3s
2021-05-28T08:59:23.118+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.118+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.118+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.119+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.120+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.126+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.127+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0]
2021-05-28T08:59:23.127+1000 DEBUG [conditions] conditions/conditions.go:98 New condition equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or e
quals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.e
vent_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0]
or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winl
og.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49c0] or equals: map[winlog.event_id:0x17e49
c0] or equals: map[winlog.event_id:0x17e49

```

Let me know if more info is needed

In index patterns winlogbeat-\*  
winlog.event\_id and event.code are long not string

```auto
{
  "winlogbeat-7.12.1-2021.05.27" : {
    "mappings" : {
      "winlog.event_id" : {
        "full_name" : "winlog.event_id",
        "mapping" : {
          "event_id" : {
            "type" : "long"
          }
        }
      }
    }
  }
}

```

Ingesting from winlogbeat \> logstash \> elasticsearch

Thanks for your your help

---

<div class="post-metadata">

**Author:** ![eafrost.cissp](https://avatars.discourse-cdn.com/v4/letter/e/cab0a1/32.png) [@eafrost.cissp](https://discuss.elastic.co/u/eafrost.cissp)\
**Post date:** [May 31, 2021, 3:09am UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/2 "2021-05-31T03:09:32Z")

</div>

I have the exact same problem. I think it is a bug in Winlogbeat 7.13.0. My log for Winlogbeat v7.12.1 does not have these warnings. After upgrading Elasticsearch and Winlogbeat to v7.13.0, and running the exact same elasticsearch and winlogbeat .yml files, Winlogbeat 7.13.0 started generating the same warnings.

These are the warnings I receive.

```auto
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/equals.go:37|expected int but got type string in equals condition.|
|---|---|---|---|---|
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/equals.go:37|expected int but got type string in equals condition.|
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/equals.go:37|expected int but got type string in equals condition.|
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/equals.go:37|expected int but got type string in equals condition.|
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/equals.go:37|expected int but got type string in equals condition.|
|2021-05-30T22:24:39.180-0400|WARN|[conditions]|conditions/range.go:140|unexpected type string in range condition.|

```

This is a representative sample of the code in my Winlogbeat.yml file that is generating them.

```auto
     - drop_event.when.not.or:
       - range.winlog.event_id: { gte: 1100, lte: 4609 }
       - equals.winlog.event_id: 4616
       - range.winlog.event_id: { gte: 4624, lte: 4625 }
       - equals.winlog.event_id: 4634
       - equals.winlog.event_id: 4647`

```

This was on my test system. I'm going to hold off on doing the 7.13.0 updated until this is resolved.

---

<div class="post-metadata">

**Author:** ![VamPikmin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vampikmin/32/22367_2.png) [@VamPikmin](https://discuss.elastic.co/u/VamPikmin)\
**Post date:** [May 31, 2021, 7:12am UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/3 "2021-05-31T07:12:39Z")

</div>

Sorry I've been meaning to post.

I've spent all weekend reindexing (GBs of data..) so I could do more tests after I delete the winlogbeat-\*  
(From what I gather that's the only way since you can't just change the field type on existing indices)

For starters you will have to change this for sure:

```auto
 - equals.winlog.event_id: 4634

```

to

```auto
- contains.winlog.event_id: "4634"

```

Since "winlog.event\_id" is now a string

- The `contains` condition checks if a value is part of a field. The field can be a string or an array of strings. The condition accepts only a string value.

> **[Define processors | Winlogbeat Reference \[7.13\] | Elastic](https://www.elastic.co/guide/en/beats/winlogbeat/current/defining-processors.html)**

I still have another cluster to upgrade, will make the change in the winlogbeat config first and see whether that's sufficient. I have a feeling it's not as after reindexing the field type is correct (text)

```auto
{
  "winlogbeat-7.13.0-2021.05.29" : {
    "mappings" : {
      "event.code" : {
        "full_name" : "event.code",
        "mapping" : {
          "code" : {
            "type" : "text",
            "fields" : {
              "keyword" : {
                "type" : "keyword",
                "ignore_above" : 256
              }
            }
          }
        }
      },
      "winlog.event_id" : {
        "full_name" : "winlog.event_id",
        "mapping" : {
          "event_id" : {
            "type" : "text",
            "fields" : {
              "keyword" : {
                "type" : "keyword",
                "ignore_above" : 256
              }
            }
          }
        }
      }
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![eafrost.cissp](https://avatars.discourse-cdn.com/v4/letter/e/cab0a1/32.png) [@eafrost.cissp](https://discuss.elastic.co/u/eafrost.cissp)\
**Post date:** [June 4, 2021, 2:54pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/4 "2021-06-04T14:54:52Z")

</div>

I am still struggling to get my range conditions formatted properly to not give the warning "unexpected type string in range condition." Winlogbeat goes ahead and publishes the event, since the message is only a warning but it still bugs me to have all those warnings being generated. I was able to eliminate the warnings for my "equals" condition by just putting the event id number in quotes and didn't have to change from "equals" to "contains".

```auto
- equals.winlog.event_id: "4634"

```

I reformatted my range condition from:

```auto
- range.winlog.event_id: { gte: 1100, lte: 4609 }

```

to

```auto
       - range:
           winlog.event_id.gte: "1100"
           winlog.event_id.lte: "4609"

```

but I still receive the warnings from winlogbeat. Any suggestions on how to get rid of the warnings for the "range" condition.

---

<div class="post-metadata">

**Author:** ![VamPikmin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vampikmin/32/22367_2.png) [@VamPikmin](https://discuss.elastic.co/u/VamPikmin)\
**Post date:** [June 6, 2021, 10:07pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/5 "2021-06-06T22:07:09Z")

</div>

I was wrong about the equals, it accepts both integer and string values, however that's not the case with range

##### `range`

The `range` condition checks if the field is in a certain range of values. The condition supports `lt` , `lte` , `gt` and `gte` . The condition accepts only integer or float values.

I've never done this before but maybe a regexp might work

```auto
- regexp:
    winlog.event_id:"(110[0-9]|11[1-9][0-9]|1[2-9][0-9]{2}|[23][0-9]{3}|4[0-5][0-9]{2}|460[0-9])"

```

---

<div class="post-metadata">

**Author:** ![eafrost.cissp](https://avatars.discourse-cdn.com/v4/letter/e/cab0a1/32.png) [@eafrost.cissp](https://discuss.elastic.co/u/eafrost.cissp)\
**Post date:** [June 15, 2021, 5:17pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/6 "2021-06-15T17:17:58Z")

</div>

I'm going to beat this dead horse one more time, recognizing that I'm way out of my depth. I would love to hear a response from someone associated with Elastic. Looking at the elastic/ beats GitHub repository, it is clear that the change of event.code and winlog.event\_id from integer to keyword was intentional [https://github.com/elastic/beats/pull/25203/files](https://github.com/elastic/beats/pull/25203/files) and it was done to be consistent with the expected ECS type [https://github.com/elastic/beats/pull/25203](https://github.com/elastic/beats/pull/25203). However the winlogbeat documentation still gives examples of creating processors to filter events using the equals condition and treating the winlog.event\_id as an integer. For example:

> ![Winlogbeat drop events](https://us1.discourse-cdn.com/elastic/original/3X/c/0/c00abc5fae4e139f152161914565ef3a67556255.jpeg)

If you don't put the event\_id in quotes, winlogbeat generates a warning that it found a string when it was expecting an integer. For a greater than or less than condition, I have not found any syntax to eliminate the warnings. Does this mean that the warnings are just an accepted consequence of the type change and is to just be ignored since it is only a warning? I just hate seeing the warnings.

---

<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:** [July 13, 2021, 7:18pm UTC](https://discuss.elastic.co/t/winlogbeat-7-13-0-expected-int-but-got-type-string-in-equals-condition/274273/7 "2021-07-13T19:18:46Z")

</div>

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