Swift log filtering: Directing message destinations using filters

In this lesson

In this lesson, I will discuss the concept of log filters which are used to direct specific types of messages to specific destinations.


Tap on time to skip ahead


Hello everyone! In this lesson, I want to talk about log filters. I’m here in the AppDelegate of my application and in the applicationDidFinishLaunchingWithOptions function, I call self.initializeApplication(). We take a look at that. The first thing it does is initialized the logger. If we look at that. You’ll see that I am adding two destinations. At least two. The console and some file logger destinations. And to illustrate filtering, I’m going to use, the file logger destinations to show how this works.


If we look at my code here, the first thing I’m doing is I’m creating a folder and we were going to ignore that for now. But I’m creating a handful of different file destinations because I’m going to apply different filters to each one. The first and most simplest way most logging frameworks specify filters is that you specify a minimum logging level. Anything that’s below that, that gets logged will be discarded. So here, the first file is called the lolChampionBrowser.log. And the second one is called the lolChampionBrowser-SQL.log. The third one is lolChampionBrowser-HTTP.log. And the last one is lolChampionBrowser-HTTP-WarningsErrors.log. I’m going to apply filtering to each one of these destinations so that I can log only to that destination the messages that I want. If we look at the first destination, the only filter being applied is a logging level filter. So it’s pretty much going to contain everything. The second destination has a logging level filter as well but I have two additional filters; one I’m filtering the message to ensure that it starts with the string “Executing” and then a second filter will filter out to make sure that the statement being logged contains an “INSERT” or an “UPDATE” or “DELETE”. The third destination simply logs all HTTP traffic. Both outbound and inbound. And the last destination, I’m applying a separate filter, two filters here; one making sure that the logging level is at least warning. So that would be warnings or errors or anything more critical than that. And I’m also filtering for “HTTP”. So, we’re going to take a look at the end result of all these filters and how they result in multiple files and what they contain.


After I’ve run my application, I’ve opened Finder to the logs folder and you can see that I have 4 log files matching the destinations that I created. I have the plain browser log, SQL, HTTP and HTTP warnings and errors and we’re going to take a look at each one to see how the filtering affected the contents of each of these logs.


Let me start with the lolChampionBrowser.log. If you remember, the only filter applied to that was the .Debug or the log level filter. So you can see that this is quite large. There’s all kinds of content in here. And everything that’s logged in the application, it’s very noisy so it’s kind of hard to parse through this log and see what’s going on.


The second file is the SQL log. If you remember, I applied a filter so that the only thing in here is SQL statements. So if I look at this, you’ll notice that there’s not quite as much log content in here. And the only thing that’s in here are SQL statements and I use the filter to filter by “Executing” and it must contain a “DELETE” or “INSERT” or an “UPDATE”. So you can see using a filter, I was able to create a log file that contains only specific types of messages. This is all the SQL in my application and I might want to use this to analyze the types of statements that I’m executing to to make sure that everything is as efficient as possible.


The third log that I created was the HTTP log and I applied a filter to this to contain all of the HTTP traffic, both outbound and inbound. You can see here, it’s kind of hard to read but the only thing that this log contains is HTTP traffic. Here’s an outbound request. And here’s a response that shows all the JSON content. And then down here when I scroll a little further, there’s a whole bunch of other HTTP-related log messages. Using a filter again, I was able to isolate all of the HTTP-related messages into its own log.


And the last thing I want to show you is how I was able to apply another filter and create a 4th log file that contains only HTTP warnings and errors and you can see there’s not much here. But, it contains only the HTTP warnings and errors that occurred. And this allows me to isolate potential problems that I can research and find out why. For example, I’m getting a 404 with these specific URL’s. And this is an easy way to just use filtering to cut down the noise and see only the things that I want in specific targets.