-
Notifications
You must be signed in to change notification settings - Fork 571
Introduction to NSLogger
Developping complex applications is hard. Your software goes through numerous execution paths, and it can sometimes be confusing to precisely understand how your software runs. This is particularly true of multi-threaded software, networking in general and applications with complex data models.
One way to better understand your code’s behavior at runtime is to log as much information as possible about what internally happens in your software, when the important changes happen, when unpredicted situations arise, and so on. Crawling through a mountain of log lines (the haystack) can make it difficult to find the precise bit of information (the needle) you’re looking for.
This is one of the motivations behind the development of NSLogger. The goal is to make it easy to explore specific aspects of an application’s runtime behavior, while keeping constant access to as much context information as possible. To this end, a suggested approach is to instrument your application with as much logging as needed, and leave all the log constantly turned on during debugging.
Traditionally, developers enable partial logging in their applications when they need to get specific information. The NSLogger approach is to leave all log turned all, all of the time, and to provide the developer with a data mining tool that makes it straightforward to locate what you’re looking for. The viewer is designed to be able to swallow large amounts of log data; the client code was written in a way that doesn’t slow down your application while it transfers your logs to the viewer.
NSLogger can of course log text messages (which are not limited in length), but also binary data and even images. Logging binary data in one simple API call is a very helpful option that can be a time saver in many situations (for example network programming). Logging images is less crucial but will have its use too, when you need to make inspect graphics downloaded from the network or created by your application.
To make your information easier to search, NSLogger lets you categorize it through the use of tags, and levels. A tag is meant to specify the general domain in your application the log gives information about (for example “graphics”, “networking”, “database”, etc). Levels can be used to log more general information at lower levels, and much more data at higher levels.
NSLogger lets you create filters you’ll use to quickly switch between different views of your data. You can multiple filters to aggregate them and view just the relevant information your need. To give you a sense of time lapse in your application, the time elapsed between each log message and the previous one (the displayed one, if your display is currently being filtered) is shown by NSLogger.
Each logged session can be saved for later inspection. You can also send log sessions to coworkers if needed, which can be very useful in teamwork situations.
Every time your application starts, or creates and starts a new `Logger` instance, the viewer opens a new window and displays the information sent through this logger. There are benefits to this approach. You could, for example (NSLogger has been created with these scenarios in mind):
- Use the default logger for debugging, and through the use of macros and conditional compilation, turn debug logging off for release builds
- Instrument your code to use a logger you instantiate on demand, in a release build. Combined with the upcoming ability to connect to the viewer remotely over the internet, this lets you distribute builds to testers or even customers, that have the capacity to connect directly to your viewer when running. One of the potential uses is live troubleshooting of issues in software running at remote locations.