Winlogbeat events not showing in AWS Elasticsearch

I am just starting out with ELK and setting it up on AWS and using AWS ElasticSearch Service.
I have configured Filebeat to send files from my AWS Windows instance to an AWS Ubuntu instance running Logstash on it. This then sends them into an index in AWS ES.
Now I am trying to do the same thing, but for Windows Event logs using winlogbeat. I want to send the events to the same logstash and then have it forward them into ES.

On the logstash instance I run in debug mode and I can see the winlogbeat events coming in - and no errors reported. When I go to Kibana on AWS I do not see any events have been loaded into any indexes.

Logstash input is:
input {
beats {
port => 5044
output is:
output {
amazon_es {
hosts => ""
region => "us-east-1"
port => "443"
index => "test2"
aws_access_key_id => "AKIxxxx"
aws_secret_access_key => "gfcxxxx"
flush_size => 5

In the debug I can see lots of events like this:
[DEBUG] 2018-08-15 18:49:18.311 [Ruby-0-Thread-7@[main]>worker0: :1] pipeline - output received {"event"=>{"event_data"=>{"param1"=>"%%860", "param4"=>"1.1.14305.0", "param5"=>"", "param2"=>""}, "beat"=>{"version"=>"6.3.2", "name"=>"winlogbeat", "hostname"=>"DEV-CNK-01"}, "opcode"=>"Info", "host"=>{"name"=>"winlogbeat"}, "type"=>"wineventlog", "record_number"=>"105272", "event_id"=>1150, "@timestamp"=>2017-10-30T12:07:50.000Z, "log_name"=>"System", "message"=>"Endpoint Protection client is up and running in a healthy state.\n \tPlatform version:\n \tEngine version: 1.1.14305.0\n \tSignature version:", "fields"=>{"env"=>"staging"}, "tags"=>["service-X", "web-tier", "beats_input_codec_plain_applied"], "computer_name"=>"DEV-CNK-01.ev.internal", "source_name"=>"Microsoft Antimalware", "level"=>"Information", "keywords"=>["Classic"], "@version"=>"1"}}

Not sure what to check now?

How about you try with regular ES output rather than using amazon es like below

elasticsearch {
       index = indexname;
       hosts => ["esurl:port"]
           ssl => true

Thanks, but it is sending the filebeat input successfully to the AWS ES, just can't get the winlogbeat to also go there.

I did try changing the output as you suggested, but either with or without the port appended to the URL it failed to make the connection. I think it is because you need to use signed requests which is what the amazon_es output lets you set up.

Here was an error:
[WARN ] 2018-08-16 15:21:42.463 [Ruby-0-Thread-4: :1] elasticsearch - Attempted to resurrect connection to dead ES instance, but got an error. {:url=>"", :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>"Elasticsearch Unreachable: [][Manticore::ConnectTimeout] connect timed out"}

I modified the actual URL above for security reasons :slight_smile:

I will give AWS Support a ping and see if they know anything.

Even though you are using the AWS ES output you should still follow the same procedures we recommend (assuming the amazon_es supports the same options).

You might be experiencing some kind of field conflict caused by not having the index template installed or because both Filebeat and Winlogbeat are writing to the same index. You could check your ES logs.

Ahah success!
Not quite sure at this point what change I did that made it work, but I did use the manage_template => false and the index tag shown in the example. Maybe there was a field conflict or something from the 2 indexes clashing before.
Now I get have indexes like:
Now I just need to start figuring out how to parse the log messages :slight_smile:
Thanks for the responses.

For Filebeat data, yep :smile:.

If you are referring to Winlogbeat data, then why? Depending on the application, most of the data is already provided in a structured format under event_data.*. Usually you just need to apply some normalizations to establish some consistency between field names.

Yes, the winlogbeat logs look great - all nicely parsed like that!!!
The filebeat logs are going to be fun....! :scream:

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