The SonarQube scanner is a simple way to start gathering data on your project. However, the scanner doesn’t know much about project structures and conventions for programming languages. Those things are all included in the build integration, which will be the topic of a later post.
With SonarQube in place and the first project run through the scanner, we are now ready for the interesting part: Analysing our project.
As soon as your SonarQube installation is working, you are ready for the next step. To analyse code with SonarQube is simple, but again you need to know where you have to start.
The installation of SonarQube is well documented and easy to follow. However, SQL Server Express brings its own challenges. There are some configuration changes you must make or SonarQube will not work. This installation walkthrough will address those issues and help you to overcome them.
The test runner inside Visual Studio is great while developing code. In this phase I only care if tests fail and when everything works, I don’t want to be bothered. However, if I need to create a report for someone that just wants to know the high-level view, then this tool is not good enough: Too much details and no visualisation.
For all the examples I showed you so far I wrote the configuration for Serilog directly in the code. That worked very well and only took a few lines of calls to the fluent API. This approach is great for a demo or a simple little application that doesn't need to change.
In a more realistic setting your production is separated from your test environment. Not only are the servers different, but you need a different configuration as well. But changing the configuration in this case means recompile your application. A better way is the topic of today’s post.
One thing that you notice instantly when you ever try to figure out what goes on in a SharePoint instance is the unbelievable amount of log messages that are written. Even when no user is on your site, SharePoint itself has so many things going on that a constant stream of messages is created.
Logstash doesn’t have to be that complicated. Last week’s example with log files from IIS looked so scary because the fields can vary from one IIS to the other. But when you want to use logstash to parse a well-known file format then all can be much simpler. Today I will show you the configuration to parse log files from the Apache web server.
The IIS log files collect all the actions that occur on the web server. As explained last week you can use Log Parser to filter the events. However, when you use Kibana for all your applications then you would prefer to have the IIS log events there as well. Today I will explain how you can use logstash to read the log files from IIS and store the events in Elasticsearch.
Every request made to a web application running on IIS is logged. Not only will the page that was requested be registered, but a lot of additional information like the user agent, the client IP address and if the request resulted in an error.