Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
A big part of providing that information is proper logging. It is incredibly difficult to maintain software without the ability to understand its state before, during, and after problems occur. When well done, logging gives us insight for resolving problems and optimizing functionality.
What Does a Log Entry Mean for Your Organization
One of the big challenges with logs is avoiding noise. It is important to consider issues like severity when planning your logging strategy. If you use a service like Logentries, this may not be as true because of the enhanced tools at your disposal. We will discuss that point in more depth shortly. Identifying several levels of severity, message types, or a combination of the two will help with the noise problem.
The difference between those two scenarios illustrates the need for message severity. The application should be aware enough of the severity of the issue to mark it correctly before surfacing it. In our above example, a single asynchronous call might not need to be called out, or only called out as a warning. Once multiple requests in a row have failed, then it can be handled more seriously as an error. A simple message type error structure could be:
The same structure with severity levels:
It is more important for the developers and support team to have a structure to use, than the specifics of what it is. Make sure both groups spend time together working out a structure for your organization.
In production, logging to the client can be a useful tool for immediately supporting customers. If you have access to the user’s machine, then standardized output to the console can help identify the problem a user is having. Output to the console seen in the context of a user’s operations is extremely useful for support.
A well-placed error message in the console might make all the difference between a frustrated user and a happy well-supported user. A support person will have a much better idea of how to resolve the problem if they have the context and application state at the time available. If your organization is too big, then bringing this information into the UI in a way the user can share it with support can serve the same helpful end.
An easy mechanism for toggling the amount of information presented in the console is the URL. Making your application check for a string, such as “debug=1” in the URL is a simple toggle mechanism. For example, if the application’s regular URL is:
- The console on one client machine is isolated. There is no way to take the information in the console and use it to identify larger issues.
- Console logs can’t be aggregated with other users’ information to determine large-scale problems.
- Information stored in the console is lost as soon as the page refreshes.
- Asking users to relay information may not be the most efficient path.
Sending Logs Entries to the Server
A server can store the log information from all clients in one location. All the log information stored together in one place serves lots of purposes:
- Better user support – A client’s error and state sent to the server with a log entry can be used to help debug customer problems remotely.
- Proactive user support – A user, or several users, can be contacted directly by support. If the system sees several errors over a short period of time, it can notify support to contact the user(s).
- Aggregation – With all log events in one place, information can be pooled together to create metrics.
- Problem Research – Events in a clearly defined severity structure (as detailed above) can help to identify trends that could lead to problems.
- Optimization – Log entries can be aggregated to recognize pain points to target for improvement.
Creating a server in Node.js, or some other server-side framework, is one potential route for logging to a server. A log server can be as simple as having an endpoint on the server that writes out to a text file. It can also be as complex as a fully relational database back end with a custom UI. There might be open source logging packages with a solid framework in place that you can use. With or without an open source framework, creating and maintaining a logging server requires a good amount of effort and time.
Alternatively, there are third party solutions, like Logentries, that can significantly simplify the logging part of your application. A third party is going to have a solid database structure, and will be able to make entries available within milliseconds. There will also be a powerful UI to help reveal log information and to aid in investigation and alerting. Third party solutions will also maintain client side and server side libraries to ease logging integration. Cloud logging simplifies logging in the same way cloud computing simplifies server management.
Sending log events out to a server is crucial for any long-term application maintenance. Despite the importance of logging to a server, the console should not be abandoned. The best solution is to make both available. Consider sending events to the server by default, while still providing a way to output to the console on demand.
Cloud logging simplifies logging in the same way cloud computing simplifies server management.
Published at DZone with permission of David Posin , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.