In my previous post, I’ve shown how to configure Logstash to parse logs from files. This is pretty useful however if your application is deployed on multiple servers, you usually log to some kind of central log storage - in my case to queue, RabbitMQ to be more specific. In this post, I will show how to configure Logstash so it reads the logs from that queue.

In my previous post I’ve shown how to configure Logstash so that, it would be able to parse the logs in custom format. Configuration presented in that post had one significant drawback - it wasn’t able to parse multiline log entries. This is a rather common scenario, especially when you log exceptions with a stack trace. Log entry, in that case may look as follows

In one of my previous post I’ve shown how to improve logging in an application by tracking the flow of incoming requests. Now it is time to show the basics of Elastic stack to make searching across multiple log files/sources a piece of cake. Elastic stack (previously called ELK stack) is set of three tools which allows you to parse (Logstash), query (Elasticsearch) and visualize (Kibana) logs with ease.

A couple of days ago I was trying to use Redis as session storage for one of my ASP .NET websites. Even though it seemed to be a rather straightforward task (Scott Hanselman wrote about that a while ago), I ended up with some weird exception while running the app: ERR unknown command 'EVAL'

I think everyone is familiar with this nice exception window we see once exception is thrown.

As a back-end developer I am quite often contacted by front-end devs to take a look why certain UI calls to the server results in wrong data being returned by API. Usually I am provided with request payload so it is quite straightforward to reply it with Postman or Fiddler and see what is going on the backend. However for time to time, replying single request is not enough to reproduce the problem. In that case it is easier to just recreate the scenario on the UI and debug the API during that process. Unfortunately this approach requires backend devs to have UI up and running on their local machines and that is not always possible (e.g. you might not get access to UI repository). Fortunately with Fiddler it is quite easy to intercept outgoing front-end calls to the API and redirect them to your locally deployed version (so you can easily debug the API).

Couple of weeks ago I mentioned that in my current project we use Cake as a build mechanism. Recently we wanted to add simple functionality to our build script, which would allow us to modify one of the App.config’s properties. According to the documentation it should be a straightforward tasks, as all the heavy lifting can be done via XmlPeek and XmlPoke aliases.

If you are doing any kind of rest api development you probably have heard of Postman. Long story short, it is a Chrome extension which allows you to send http requests in a very easy and intuitive way. Apart from that (and many other features), it also allows you to intercept browser request. As this feature is very easy to overlook, here is a simple guide how to use it.