跳至主要内容

Design a Logging System?

Design a Logging System?
Long long ago, when there is not any mature logging system, Tom is facing the problem of logging. The native logging system form Java SDK has some issues of class loading, in which it may cause memory leaks1.

Requirement

He discussed this problem with leader and they decided to write their own logging system with the following requirements:
  • The logging system can be used by different package, class at the same time and we can easily differentiate them;
  • The logging system can output to different location, for example, console, file or even network;
  • The logging system can output formatted log content: plain text, JSON, XML etc;
  • The logging system can have different levels to control the behavior in different environments: in development env, we can log more, but in production env, we maybe log only exception;

Design

Tom now begin to analyze the requirements of logging system using OO related patterns and try to make some basic abstraction from them.
The first concept is the class which used to log by different packages and classes. Considering its functionality, tom would like to call it Logger. In order to differentiate them, we can give Logger a unique name. But how to ensure the uniqueness of this name? The UUID is the first idea come up to his mind.
"UUID seems will not be duplicate in a application with not so much logger, but the readability is so bad. What about the class name? Great idea!" A inspiration is caught by Tom.
Logger logger = new Logger("com.foo");
The next requirement is the output destination: console, file etc. This is relative easy, an abstract class with multiple subclass can solve the problem. Considering we always append the log entry to this destination, we can call them Appender.
“We do similar things about the format requirement. We can have a Layout interface class and XMLLayout, HTMLLayout, PatternLayout implementations.” Tom thought.
public String getHeader();
public String getFooter();
public String doLayout(LogEntry e);
"Oh, It seems that we didn’t define a class represent logging entry. So we call it LoggingEvent".
The final requirement is to control the logging level.
"This is easy. We can define a enum[^enmu] which has five priorities: TRACE, DEBUG, INFO, WARN, ERROR and add set a level in logger to control. We can even add some utility method like trace, debug to avoid explicit level check by user.
public void trace(String msg);
public void debug(String msg);

Relationship

Now, Tom think he need to make the relationship between those classes more clear. He analyzed as following:
Logger -- Destination: 1 vs n
Destination -- Layout: 1 vs 1

Logger -- Layout: 1 vs n
Logger -- Level: 1 vs 1
So the class relationship can be organized like this:

Design Principle

When tom bring the design to leader, leader is very satisfied. He said, “Great job! One more question, do you get some design principle from this tasks?”
“Em, I don’t know.”
“The abstraction should be isolated, or in other words, the design should be orthogonal.”
“Isolated? Orthogonal?”
"Yes, have you noticed that the requirement of Logger, Appender and Layout is in different dimension? Changing the requirement of one of them will not affect others. If we need another output target like email, we can simple add a SMTPAppender and no other abstraction will be affected.
“Once we make our abstractions isolated from each other, they can change in their own dimension and not affect others.” The leader concluded.

Postscript

The logging system referred in this blog is SLF4J and Logback, and the tom is Ceki Gülcü who developed SLF4J, Log4j and Logback. We just talked about some basic design decisions of logging systems, and there exists many other things that we don’t cover:
  • Logger hierarchy and inheritance: level & resource & appender
  • Target level & Filter
  • Layout & Encoder
For those related topic, you may refer to this SLF4J introduction and this.

Ref

Written with StackEdit.

  1. For detail explanation of problems caused by Level, refer to this blog. In short, the Level class will store the reference to its object, who refer to a AppClassLoader, causing almost whole application fail to un-deploy. ↩︎

评论

此博客中的热门博文

Spring Boot: Customize Environment

Spring Boot: Customize Environment Environment variable is a very commonly used feature in daily programming: used in init script used in startup configuration used by logging etc In Spring Boot, all environment variables are a part of properties in Spring context and managed by Environment abstraction. Because Spring Boot can handle the parse of configuration files, when we want to implement a project which uses yml file as a separate config file, we choose the Spring Boot. The following is the problems we met when we implementing the parse of yml file and it is recorded for future reader. Bind to Class Property values can be injected directly into your beans using the @Value annotation, accessed via Spring’s Environment abstraction or bound to structured objects via @ConfigurationProperties. As the document says, there exists three ways to access properties in *.properties or *.yml : @Value : access single value Environment : can access multi

Elasticsearch: Join and SubQuery

Elasticsearch: Join and SubQuery Tony was bothered by the recent change of search engine requirement: they want the functionality of SQL-like join in Elasticsearch! “They are crazy! How can they think like that. Didn’t they understand that Elasticsearch is kind-of NoSQL 1 in which every index should be independent and self-contained? In this way, every index can work independently and scale as they like without considering other indexes, so the performance can boost. Following this design principle, Elasticsearch has little related supports.” Tony thought, after listening their requirements. Leader notice tony’s unwillingness and said, “Maybe it is hard to do, but the requirement is reasonable. We need to search person by his friends, didn’t we? What’s more, the harder to implement, the more you can learn from it, right?” Tony thought leader’s word does make sense so he set out to do the related implementations Application-Side Join “The first implementation

Learn Spring Expression Language

When reading the source code of some Spring based projects, we can see some code like following: @Value( "${env}" ) private int value ; and like following: @Autowired public void configure (MovieFinder movieFinder, @ Value ("#{ systemProperties[ 'user.region' ] } ") String defaultLocale) { this.movieFinder = movieFinder; this.defaultLocale = defaultLocale; } In this way, we can inject values from different sources very conveniently, and this is the features of Spring EL. What is Spring EL? How to use this handy feature to assist our developments? Today, we are going to learn some basics of Spring EL. Features The full name of Spring EL is Spring Expression Language, which exists in form of Java string and evaluated by Spring. It supports many syntax, from simple property access to complex safe navigation – method invocation when object is not null. And the following is the feature list from Spring EL document :