Since the 1807 update Azure Stack supports the configuration of a syslog server. In our company we have a syslog service based on ElasticSearch. My initial thoughts back then (oktober 2018) were “Yes, now I can collect everything and filter out what I need!”. Well, turns out to be a little bit different.

A special thanks to @PatrickLownds for giving his input on this subject.

Configuration

The configuration is well documented and easy to follow. So, I will not spend time explaining this. See the Microsoft docs here.

Note: The syslog data will be sent from the Public VIP (external) range.

And then…

Once syslog was configured I checked if the data was coming in. “I’ll take a look later…” I thought. Of course, reality kicked in and didn’t had time to do something with it. The first time I had to look at it again was after the installation of the 1808 update. I noticed the syslog server did not received any new data. Checking the settings via the PEP I noticed the syslog configuration was gone. Configured it again, everything OK.

1809 update, syslog config gone. 1811 update, syslog config gone. 1901 update is planned… I have a feeling what the outcome is.

EDIT 20190408: I received message from Microsoft this will be fixed in one of the upcoming released

The data

I recently tried to look at the data. I’m new with Kibana but it seems to work intuitive. From our stamp we receive around a million messages per hour. While others receive 5 million messages per hour. It all depends on the workload on the Azure Stack of course.

When looking at some individual messages it’s clear… It logs everything from every host, infra VM, task, etc. I concluded that it would be a too time-consuming job for me to filter out the information that is useful in order to benefit from it.

Note: Syslog is not implemented in the Resource Providers (like App Services, SQL/MySQL, …).

So why use syslog?

The reason we are using syslog for now is somehow obvious: compliance. Some organizations we are working with require having 120 days or more retention time on log data. The log rotation in Azure Stack differs from component to component so anything we can log from Azure Stack out of the box is welcome. Over time we will probably take another look at syslog, maybe with other tooling as well.

But if you have the time, tools and skills to go through the logging you’ll probably find a lot of interesting things. It can give you an insight in how Azure Stack works and you even can find potential bugs like @PatrickLownds did.

I hope to see something about Azure Stack connected to Azure Sentinel soon. Maybe @kristopherj or @markscholman will do this perhaps?

If you have any feedback/additions/questions about this post, please let me know!