How you handle logs mainly depends on the application's client. To manage logs well, you need to know the details associated with each possible application client.
Web (dev tools)
The most useful tool for working with logs in web applications is the developer console. This tool is built into all browsers. Let's explore working with the console using the example of the Google Chrome browser. You can access the developer console by pressing the F12 key on Windows or Linux, Option + ⌘ + I on MacOS. To work with logs, you'll use the Console and Network tabs.
In the Console tab, the web application's logs are recorded.
Logs are divided and grouped into the following levels:
User messages: Non-technical information for end-users.
Errors: Indicates critical issues that need immediate attention.
Warnings: Highlights potential issues that may lead to undesired application behavior.
Info: Provides details about the application's execution flow or events.
Verbose: Captures extensive information for in-depth debugging and analysis.
If you need to find a specific message in the logs, you can use the filter functionality, which searches for the entered string across all recorded logs.
You can click on the entries in the Console tab, and depending on the type of entry, clicking may lead to navigating to the Sources tab, indicating the source code that triggered the log, or to the Network tab if the log resulted from processing a network request.
The Network tab provides a detailed overview of all network activities, including HTTP requests and responses. This includes resources loaded by the page, such as images, scripts, stylesheets, and more. Each network entry comes with important information like request and response headers, status codes, and timings. Failed network requests, such as those returning error status codes (e.g., 404 Not Found), are highlighted in red. This acts as an instant visual indicator of problems. The Network tab allows for effective filtering and sorting of network requests based on various criteria. This is very useful when you focus on specific types of requests or need to narrow down logs related to particular resources.
Filter by text is a useful tool; search can be done by using text included or excluded, regular expressions, domains, etc. You can also filter network events by their type: fetch/xhr (HTTP request), JS (executed JavaScript), Img, and other types. The Network tab features a waterfall visualization that shows the timeline of network requests. This visual representation helps you understand the sequence and dependencies of various requests. You can export log data from the Network tab for more analysis or to share with team members. This helps with collaboration and deeper investigation.
In the attached image, the filtering part is highlighted in red, the logs timeline is shown in green, and the main part with all events is highlighted in blue.
Clicking on each network event provides detailed information. This could include request headers, payload, response, initiator, and timings.
Desktop
Logs for desktop applications are usually stored in a specific folder made by developers. The location and file format in this folder depend on the app itself. So, logs are kept in the file system.
You can also view logs by running the app through an Integrated Development Environment (IDE) and looking at the logs in the IDE's terminal while the app is running. This technique varies a lot based on the programming language and the IDE you choose.
Furthermore, for desktop apps, you can use tools that come with the operating system to track logs. For Windows, this tool is the Event Viewer. To open the Event Viewer, press `Windows + R` to open the Run dialog, type eventvwr.msc, and hit Enter. Or, press the Windows button, type 'Event Viewer' in the search bar, and start the program you find. The "Application" log in Event Viewer records info from various apps on your system. It's a good place to check for logs for the app you're testing.
Each log entry gives details like the event source, event ID, level (Information, Warning, Error), and a description. Use the Event Viewer's filter options to find logs that matter for specific apps or events. You can filter by date, event level, or event source to get to the crucial info for testing. A very handy feature is creating custom filters where you can set exactly the level of logging and the event time you need for your app.
Mobile
Working with logs on mobile clients greatly differs depending on the operating system. For example, to collect logs on Android, you may use an emulator or a USB cable to connect the device to a computer or laptop.
To collect logs with an emulator, you need Android Studio. Launch the emulator there. After that, in the View menu, choose Tool Windows and turn on Logcat. You'll see all logs from the emulated device in the Android Studio terminal.
Your second choice is connecting the device to the computer. First, turn on developer mode on the device. Find this option in the settings, usually in “Software information” under “About phone”. Tap the build number many times until you see “You are now a developer!”.
Then, on the computer you will use to get the logs, install SDK Platform Tools. With a USB cable, link the device to the computer. After installing, go to the folder with SDK Platform Tools via the terminal. There, start the Android Debug Bridge app using the command adb start-server. To check if the device is linked, type adb devices in the terminal. It will show the connected device.
Next, erase old logs with the command adb logcat -c. Now you can start getting logs. Type adb logcat -v time > log.txt in the terminal and use the device. As you do this, logs will be saved to the file log.txt in the SDK Platform Tools folder. To end the log capture, hit CTRL+C in the terminal.
To get logs with the emulator, use a Mac with Xcode installed. Start Xcode, then choose Open Developer Tools → Simulator. In the simulator, select Debug → Open System Log for logs in the console.
You can also use Xcode to capture logs from an actual device. Connect the device to your Mac with a USB. In Xcode, pick Windows → Devices and Simulators. Then click on Open Console for the device. You’ll receive logs as they happen.
For Windows users, capturing logs with the iMazing app is possible. Open iMazing and hook up your iOS device to the PC. Click on Show Device Console. You'll get the logs live and can save them.
Conclusion
To work with logs efficiently, you need to know which client the user is using to interact with the application, the device and operating system they are using, and based on this information, select the method for collecting and analyzing logs.