Lessons Learned: Winlogbeat & Forwarded Events – no event description

Scenario: Shipping Azure Cloud Logs to an Elasticsearch Cluster

The Azure Log Service [AZLog ] audits events across your Azure Cloud infrastructure, and sends these to a central log collector. It leverage the Windows Event Forwarding subsystem to do this, meaning that the collector server will be able to view the AZLog alerts via the Event Viewer > Forwarded Events

This means that probably the most efficient way of getting the AZLog events from the central collector to Elasticsearch would be to use WinLogBeat. Configuration is simple enough, simply using a WinLogBeat configuration file like so would do the job [1]:

 - name: ForwardedEvents
   ignore_older: 72h

However, once we did this we ran into a strange issue… The events in elasticsearch were missing the “message” field. Some documentation and issues pointed to the fact that using the “Events” format rather than the default “Rendered Text” could cause such issues [2][3]. The problem is that you sometime don’t have direct control over the windows event infrastructure – it’s handled by someone else. We got around this by setting “event_logs.forwarded” to false. The winlogbeat documentation states [4]:

event_logs.forwarded: A boolean flag to indicate that the log contains only events collected from remote hosts using the Windows Event Collector. The value defaults to true for the ForwardedEvents log and false for any other log. This option is only available on operating systems supporting the Windows Event Log API (Microsoft Windows Vista and newer). This settings allows Winlogbeat to optimize reads for forwarded events that are already rendered. When the value is true Winlogbeat does not attempt to render the event using message files from the host computer. The Windows Event Collector subscription should be configured to use the “RenderedText” format (this is the default) to ensure that the events are distributed with messages and descriptions

Note that it default to true for ForwardedEvents. Turning this to false in the AZLog context brought back our all-important message field…


[1] http://syspanda.com/index.php/2017/03/01/sending-windows-event-forwarder-server-wef-logs-to-elasticsearch/

[2] https://github.com/elastic/beats/issues/1031


[4] https://www.elastic.co/guide/en/beats/winlogbeat/master/configuration-winlogbeat-options.html


Elasticsearch REST API: JEST upsert

I’ve already written about tips and tricks when using the Elasticsearch Java API. The Elasticsearch REST API has been going from strength to strength, and it seems that going forward the Elasticsearch team will focus more on the REST API than the native JAVA client. At the time of writing however, the official java REST library doesn’t seem to have support for the abstraction of the bulk API, so I followed some advice and looked into the JEST library.

The only snag with the Jest library is that when it comes to bulk operations, the documentation only gives examples of scripted updates. The Elasticsearch update API also allows for updates using partial documents. Jest supports this functionality, but I couldn’t find good documentation for this. Here-under is an example for anyone looking for this:

The important points:

  • You can still use the official java elasticsearch client’s “XContentFactory.jsonBuilder” library to more easily build your JSON objects.
  • The trick is in line 26 above:


This creates a nested object with “doc” as the inner JSON object, as outlined by the elasticsearch documentation:

    "doc" : {
        "name" : "new_name"

The first “startObject()” creates the outer curly brackets, while the second startObject(“doc”) creates the inner “doc” object.

  • We add content to the JSON object in lines 27-29
  • Just like we had to use two startObject() calls, we need to close the object with two endObject() calls as shown in line 31

The rest of the snippet deals with the actual bulk update. We pass the object we just created into an Update Builder, which gives us a “Bulkable Object” that we can pass on to the jest bulk processor. The snippet is taken from a larger program where it resides in a loop – which explains the if/else clause in lines 37-48; it’s important to “flush” the bulk service every so often. The native java client would to this automatically – so far in Jest you need to account for this yourself