Winlogbeat 7.13.0 expected int but got type string in equals condition

VamPikmin · May 27, 2021, 11:05pm

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

{
  "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

eafrost.cissp · May 31, 2021, 3:09am

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.

|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.

     - 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.

VamPikmin · May 31, 2021, 7:12am

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:

 - equals.winlog.event_id: 4634

to

- 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.

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)

{
  "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
              }
            }
          }
        }
      }
    }
  }
}

eafrost.cissp · June 4, 2021, 2:54pm

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".

- equals.winlog.event_id: "4634"

I reformatted my range condition from:

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

to

       - 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.

VamPikmin · June 6, 2021, 10:07pm

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

- 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])"

eafrost.cissp · June 15, 2021, 5:17pm

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 and it was done to be consistent with the expected ECS type 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:

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.

system · July 13, 2021, 7:18pm

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

Topic		Replies	Views
Send event logs to pipeline based on event_id Beats winlogbeat	6	401	November 4, 2020
Can No Longer Use Range Condition to Drop Events By Event ID? Beats winlogbeat	1	701	August 5, 2021
Winlogbeat data is not parsing properly Beats winlogbeat	9	1363	June 7, 2020
Event id processor fails to start service Beats winlogbeat	3	573	April 29, 2019
Winlogbeat 7.0 not dropping events Beats winlogbeat	2	875	May 13, 2019

Winlogbeat 7.13.0 expected int but got type string in equals condition

range

Related topics

`range`