历史
在几年前，我们使用了一个根据msyslog修改过来的版本，它也是一个插件化的架构。但是，和很多syslog的实现者一样，它也是基于BSD的syslog的单线程架构实现的，所以它继承了所有syslog的缺点。我们很快就发现我们需要一个更好的日志解决方案。接着，我们就开始寻找其他解决方案，有很多像rsyslog、syslog-ng这样的方案是可以拿来代替msyslog的，但是大多数方案还是单线程的，并且不是原生支持Windows系统的。于是我们就开始开发NxLog，Nxlog从2009年开始开发，当时是一个闭源项目，知道2011年我们才放出了开源的CE版本
概念
大多数日志处理程序都有很类似的概念，Input是用于从数据源读取数据的，然后就会对日志进行出来，最早会通过Output送到其他的地方。当一个事件在应用程序或者设备上触发了，一个相关的日志消息也会被触发。这种日志我们通常称之为event log。这些日志信息通常都有不同的格式，也会有不同的协议。但是有一点他们是相同的，所有的Event log都包含了一些重要的信息，例如时间、IP、用户等。这样看的话，事件也可以变成一个Key-Value的数据结构，我们通常称之为字段。例如原始日志
<30>Nov 21 11:40:27 log4ensics sshd[26459]:
Accepted publickey for log4ensics from 192.168.1.1 port 41193 ssh2
变成键值对之后
AuthMethod publickey
SourceIPAddress 192.168.1.1
AccountName log4ensics
SyslogFacility DAEMON
SyslogSeverity INFO
Severity INFO
EventTime 2009-11-21 11:40:27.0
Hostname log4ensics
ProcessID 26459
SourceName sshd
Message Accepted publickey for log4ensics from 192.168.1.1 port 41193 ssh2
在nxlog里面有个特殊的字段，叫做$raw_event，这个字段会被UDP、TCP、File等处理模块所使用，他们读入数据之后，会对这个字段进行填充。
架构
由于整体的架构是可插拔式的，NXLog的架构可以读取任何类型的输入，并且转换成各种类型的日志并且输出。不同的输入、转换、输出是可以同时使用的
NXLog Core主要负责读取配置文件，监控文件、Socket还有内部事件的变化。它是一个基于事件的架构，所有的模块都可以给core调度。nxlog是个多线程的应用程序，主函数负责监控文件和Socket。有一个线程专门负责处理内部事件，它在下一个事件进来之前都一直保持休眠状态。
Nxlog实现了一个线程池的模型，这让nxlog core可以集中控制所有的事件，也能让事件具备优先级，用于处理Socket和文件的模块是用非阻塞式IO进行编写的，能够保证线程永远都是非阻塞的。处理Socket和文件的模块，使用非阻塞的方式来确保工作线程不会阻塞。属于同一模块的每一个事件都是按顺序执行的，而不是同时执行的。这确保了消息的顺序被保留，并有一个很大的好处，不必处理模块中的并发问题。
当输入模块接受到了数据，它将会创建一个由原始日志和额外的字段组成的结构体，然后它将会被放到下一个处理模块的队列中。下一个模块可以是处理数据模块或者是一个输出模块。当然，输入或者输出模块也可以嵌入一些NXlog语言的处理代码。不同的是这些处理模块会在另外一个线程中运行，考虑到日志处理模块也可能会被调用，这样的做法可以更好的发挥多核CPU的性能
