日志平台的一点思考

日志平台的对开发、运维人员的帮助是非常大的，它可以方便开发、运维人员快速定位问题，从这个角度，日志平台是个搜索平台；同时还可以做有效的数据分析，比如分析 pv, uv，httpstatus，用户行为，资源消耗，网络攻击、trace等等，应用场景非常丰富，这时候它又是个数据分析平台，在马上到来的5G时代，物联网的真正兴起，日志平台会发挥更大的价值。

日志其实是比较宽泛的概念，应用打印的server log,Linux文件系统的syslog，/var/messages 等等都是日志，日志本质上其实是一种时序数据，类似于监控领域的metrics，只不过metrics一般是比较结构化的，每个字段数据长度都比较小，通常是时间+tag+value ，而日志也带有时间，但是单条日志可能会比较长（有时候不止一行） ，同时大多数都是非结构化的文本数据，它们共同的特点是数据产生后不会被更新。

简单说日志平台既要存储又要计算

功能上，日志平台应该具备以下几个基本的功能点

1、日志的采集

2、日志数据的存储

3、日志数据的快速检索和分析

日志要搜索，就要集中存储，就要采集日志，以前日志采集分2种，一种是agent的方式，一种是agentless的方式，前者是在要采集的服务器上部署一个agent，agent将日志不断的发送给日志server端，agentless的方式是通过类似ssh远程登录服务器去抓日志。

agentless的方式不需要部署agent，一般是定时的方式去拉日志过来，这种方式时效性很差，不能实时监听文件系统获取最新的日志数据，基本上业内很少有人采用了，以前阿里巴巴的TLog似乎是采用这种方式。

现在大部分是采用部署agent的方式获取日志，比较有名的是flume,logstash,filebeat等等，flume和logstash在使用的时候，不方便控制占用的cpu和内存资源，在微服务化架构的环境中，采集日志对agent的性能要求越来越高，同时资源消耗要尽可能的低，filebeat相对比较轻量，功能也非常强大，使用人越来越多。

agent的方式本质上是调用server的api接口将数据发送给日志的server，因此另一种使用方式就是app直接调用日志server的api，比如将这个功能做成log4j的插件，或者写入其它的常用的日志组件中，这样日志采集的成本最低，但是当日志服务不可用的时候，日志数据恢复成了稍微麻烦的事情。

通常在一个成规模的企业内部，使用agent的方式采集日志，管理agent也是一个问题，比如阿里巴巴目前声称SLS的agent部署超过200万个节点，不要说200万个节点，就是200个节点，我们总不能挨个登陆去修改agent的配置文件吧，因此采集任务的自动下发，生效，更改非常重要，同时还要能够自动管理agent的状态，升级agent等等。

以前阿里巴巴的TT也有agent采集，部署规模也较大，在实现方面，有些场景下agent会请求服务端的clientAPI，这种设计在双11降级恢复的时候，会给clientAPI带来非常大的压力，因此，在设计应用于大规模的agent部署场景的时候，应该考虑这种问题。

写的目的是为了读，要更好的读，就要设计更合理的存储方案。既要满足检索，又要做数据统计和分析，似乎解决方案只有倒排索引了？开源社区一提到日志的存储，一般都会选择elasticsearch，一些创业公司也会基于或者借鉴es来做存储的方案，这个东西的确开箱即用，一个命令拉起来，日志灌进去，搜索效果似乎也不错，kibana也能分析，但是当我们实际部署应用起来，就会发现用es存日志是一个成本非常昂贵的方案。

在一家稍有规模的公司，日志数据10w/s每秒的写入是非常容易出现的，实时索引，然后刷到文件系统缓存才可见，es这种实现方式，本身就不适合迎接这种高tps的写入，同时它读写不分离，一般情况下，Lucene的设计在日志场景下需要经过特殊的优化，比如将那些常驻内存的数据进行lru处理，将不常用的索引关闭，在merge的时候对避免重复IO，segment关系映射内存优化等等，越深入了解，越发现这种方案真的太奢华了，业内用es做日志存储的基本上都是土豪，动辄几百上千的服务器堆砌 + 精细化运维，性价比极低，真是暴殄天物，日志规模较大的，财力一般的公司就不要考虑这种败家的方案了。

日志的存储实际上需要实时求是，根据日志的特点，灵活的设计存储方案。

日志搜索也是一种典型的交互式查询的场景, 当然是越快越好，比较理想的情况是1-3秒返回结果，但是时间跨度非常大的场景，十几秒用户也能接受，超大规模查询最慢不超过30秒等等，检索方面，除了输入关键字，还希望能够支持功能强大的分析、过滤、统计。这种特点，其实给存储留下了非常大的设计空间，也是不小的挑战。

存储首先应该是分布式的，可以方便水平扩展的，同时根据日志的特点，做少量的必要的索引。比如日志一般是按照时间范围搜索和分析的，那么时间显然是最重要的索引，同时日志来自哪些机器，属于哪个应用，什么机房，应该会有一些标签，那做一些基于标签的索引就足够了，那么现有的一些存储系统能不能直接利用呢？

前面说了日志是一种时序数据，那么opentsdb能不能做日志的存储呢？opentsdb本身依赖hdfs，hbase，从部署角度讲，太复杂，同时它一行就存储一小时的数据，每一行是一个metric，这种方式，你日志怎么存，显然不合理。

kafka这种东西呢，它也给每条消息加了时间戳信息，支持按照时间戳seek，kafka的架构设计其实给了我很多日志存储设计的启发，但是它的索引仅有时间是不够的，也许你会想能不能在topic名字上做点文章，我想也是不可以，因为我们要索引的东西还是蛮多的，kafka在topic数量非常大的情况下，性能会下降的比较明显。

日志统计和分析方面阿里巴巴的SLS是通过标准SQL来做的，但是我更喜欢类似shell命令行的风格和方式，sql思维需要一些时间转变，用户并不一定都会喜欢sql，但是不管怎么样，要分析、统计日志，需要在日志存储系统上面搭建一套DSL分析引擎，能够加入常用的算子，同时还能分布式执行这些运算，同时快速的返回结果，曾经想过用MLSQL加载日志的数据然后用sql分析完将结果取回，这其实也是一条很好的思路，虽然MLSQL不需要每次都提交spark作业的过程，但是搬运数据还是会牺牲掉一部分时效性，好处是计算和存储是分离的，同时我还希望日志平台能够实时的监听一些我感兴趣的日志事件，然后在自定义的dashboard中展示，支持报警等等。

最近1-2年一直在研究探索更具性价比的日志管理平台，后续会将一些心得体会、解决方案记录下来跟大家分享。

Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

Wazuh是一个安全检测、可视化和安全合规开源项目。它最初是OSSEC HIDS的一个分支，后来与Elastic Stack和OpenSCAP集成在一起，发展成为一个更全面的解决方案。下面是这些工具的简要描述以及它们的作用:

11OSSEC HIDS

OSSEC HIDS是一种基于主机的入侵检测系统(HIDS)，用于安全检测、可见性和遵从性监控。它基于一个多平台代理，将系统数据(如：日志消息、文件散列和检测到的异常)转发给一个中央管理器，并在其中对其进行进一步分析和处理，从而产生安全警报。代理将事件数据通过安全且经过身份验证的通道传递给中央管理器，以便进行分析。

此外，OSSEC HIDS提供了一个集中的syslog服务器和一个无代理的配置监视系统，该系统提供了对防火墙、交换机、路由器、接入点、网络设备等无代理设备上的事件和更改的安全洞察。

12OpenSCAP

OpenSCAP是一种OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)解释器，用于检查系统配置和检测脆弱应用程序。

这是一种众所周知的工具，用于检查安全合规性和使用工业标准安全基线对企业环境的加固。

13Elastic Stack

Elastic Stack是一个软件套件(Filebeat、Logstash、Elasticsearch、Kibana)，用于收集、解析、索引、存储、搜索和显示日志数据。它提供了一个web前端，该前端提供事件的高级仪表板视图，支持深入到事件数据存储的高级分析和数据挖掘。

二、组件

Wazuh的主要组件是运行在每个受监控主机上的代理，以及分析从代理和syslog等无代理源接收到的数据的服务器。此外，服务器将事件数据转发到一个Elasticsearch集群，在这里对信息进行索引和存储。

21Wazuh agent

Wazuh代理运行在Windows、Linux、Solaris、BSD和Mac操作系统上。它用于收集不同类型的系统和应用程序数据，这些数据通过加密和经过身份验证的通道转发给Wazuh服务器。为了建立这个安全通道，使用了一个包含唯一预共享密钥的注册过程。

代理可以用来监视物理服务器、虚拟机和云实例(例如Amazon AWS、Azure或谷歌云)。预编译的代理安装包可用于Linux、HP-UX、AIX、Solaris、Windows和Darwin (Mac OS X)。

在基于Unix的操作系统上，代理运行多个进程，这些进程通过本地Unix域套接字相互通信。其中一个进程负责向Wazuh服务器发送通信和数据。在Windows系统上，只有一个代理进程使用互斥对象运行多个任务。

不同的代理任务或过程以不同的方式监视系统(例如，监视文件完整性、读取系统日志消息和扫描系统配置)。

下图表示在代理级别上发生的内部任务和流程:

所有代理进程都有不同的目的和设置。以下是他们的简要说明:

Rootcheck:这个过程执行多个与检测rootkit、恶意软件和系统异常相关的任务。它还对系统配置文件运行某些基本的安全检查。

日志收集器 Log Collector :此代理组件用于读取操作系统和应用程序日志消息，包括平面日志文件、标准Windows事件日志甚至Windows事件通道。还可以将其配置为定期运行并捕获特定命令的输出。

Syscheck:这个过程执行文件完整性监视(FIM)，也可以监视Windows系统上的注册表项。它能够检测文件的内容、所有权和其他属性的变化，以及记录文件的创建和删除。虽然它在默认情况下执行定期的FIM扫描，但它也可以配置为与操作系统内核通信，以便实时检测文件更改并生成文本文件的详细更改报告(diffs)。

OpenSCAP:该模块使用已发布的OVAL(开放漏洞评估语言)和XCCDF(可扩展配置检查表描述格式)基线安全概要。通过定期扫描系统，它可以找到不符合众所周知的标准的脆弱的应用程序或配置，例如在CIS(互联网安全中心)基准测试中定义的那些。

代理守护进程 Agent Daemon :这个进程接收所有其他代理组件生成或收集的数据。它通过经过身份验证的通道将数据压缩、加密并交付给服务器。这个进程运行在一个独立的“chroot”(更改根)环境中，这意味着它对被监视系统的访问是有限的。这提高了代理的整体安全性，因为它是连接到网络的唯一进程。

22Wazuh server

服务器组件负责分析从代理接收的数据，并在事件匹配规则时触发警报(例如检测到入侵、文件更改、配置不符合策略、可能的rootkit等)。

服务器通常运行在独立的物理机器、虚拟机或云实例上，并运行代理组件，其目的是监视服务器本身。以下是主要服务器组件列表:

注册服务 Registration service :通过提供和分发每个代理特有的预共享身份验证密钥来注册新代理。此流程作为网络服务运行，支持通过TLS/SSL和/或通过固定密码进行身份验证。

远程守护进程服务 Remote daemon service :这是从代理接收数据的服务。它使用预共享密钥来验证每个代理的身份，并加密代理和管理器之间的通信。

分析守护进程 Analysis daemon :这是执行数据分析的进程。它利用解码器识别正在处理的信息类型(如Windows事件、SSHD日志、web服务器日志等)，然后从日志消息(如源ip、事件id、用户等)中提取相关数据元素。接下来，通过使用规则，它可以识别解码后的日志记录中的特定模式，这些模式可能触发警报，甚至可能调用自动对策(主动响应)，比如防火墙上的IP禁令。

RESTful API RESTful API :这提供了一个接口来管理和监视代理的配置和部署状态。它也被一个Kibana应用程序Wazuh web界面所使用。

23Elastic Stack

Elastic Stack是一个流行的用于日志管理的开源项目的统一套件，包括Elasticsearch、Logstash、Kibana、Filebeat等。与Wazuh解决方案特别相关的项目有:

Elasticsearch :一个高度可伸缩，全文搜索和分析引擎。弹性搜索被分配，意味着数据(索引)被分成shard，并且每个shard可以具有零个或更多个副本。

Logstash:收集和解析要保存到存储系统中的日志的工具(例如，Elasticsearch)。收集到的事件还可以使用输入、过滤和输出插件进行丰富和转换。

Kibana:一个灵活和直观的web界面，用于挖掘、分析和可视化数据。它运行在一个Elasticsearch集群上索引的内容之上。

Filebeat:一种轻量级转发器，用于在网络中传送日志，通常用于Logstash或Elasticsearch。

Wazuh与Elastic Stack集成，提供已解码的日志消息提要，这些日志消息将由Elasticsearch索引，以及用于警报和日志数据分析的实时web控制台。此外，Wazuh用户界面(运行在Kibana之上)可用于管理和监视您的Wazuh基础设施。

Elasticsearch索引是具有某些相似特征(如某些公共字段和共享数据保留需求)的文档集合。Wazuh每天使用多达三种不同的索引来存储不同的事件类型:

Wazuh -alerts:每当事件触发规则时，Wazuh服务器生成警报的索引。

wazuh-events:从代理接收的所有事件(归档数据)的索引，无论它们是否触发规则。

wazuh-monitoring:索引与代理状态相关的数据。web接口使用它表示单个代理处于或已经处于“活动”、“断开”或“从未连接”的情况。

索引是由文档组成的。对于上面的索引，文档是单个警报、归档事件或状态事件。

将Elasticsearch索引分成一个或多个shard，并且每个shard可以选择性地具有一个或多个副本。每一主和副本shard是单个的Lucene索引。因此，一个Elasticsearch索引是由许多Lucene索引组成的。当搜索在Elasticsearch索引上运行时，将并行地对所有shard执行搜索，并合并结果。将Elasticsearch索引分成多个shard和复制品用于多节点的弹性搜索集群，目的是缩小搜索和获得高可用性。单节点Elasticsearch集群通常每个索引只有一个shard，没有副本。

三、体系结构

Wazuh架构基于运行在受监视主机上的代理，这些主机将日志数据转发到中央服务器。此外，还支持无代理设备(如防火墙、交换机、路由器、接入点等)，并可以通过syslog和/或其配置更改的定期探针主动提交日志数据，以便稍后将数据转发到中央服务器。中央服务器对输入的信息进行解码和分析，并将结果传递给一个Elasticsearch集群进行索引和存储。

一个Elasticsearch集群是一个或多个节点(服务器)的集合，这些节点(服务器)相互通信，对索引执行读写操作。小型Wazuh部署(<50个代理)可以由单节点集群轻松处理。当存在大量受监控系统、预期会有大量数据和/或需要高可用性时，建议使用多节点集群。

当Wazuh服务器和Elasticsearch集群在不同的主机上时，Filebeat可使用TLS加密将Wazuh警报和/或存档事件安全地转发到Elasticsearch服务器。

下图说明了Wazuh服务器和Elasticsearch集群在不同主机上运行时组件是如何分布的。注意，对于多节点集群，将有多个Elastic堆栈服务器，Filebeat可以将数据转发到这些服务器:

在较小的Wazuh部署中，使用单节点Elasticsearch实例的Wazuh和Elastic堆栈都可以部署在单个服务器上。在这个场景中，Logstash可以直接从本地文件系统读取Wazuh警报和/或归档事件，并将它们提供给本地Elasticsearch实例。

四、通信与数据流

41代理-服务器通信

Wazuh代理使用OSSEC消息协议通过端口1514 (UDP或TCP)将收集到的事件发送到Wazuh服务器。然后，Wazuh服务器解码并使用分析引擎对接收到的事件进行规则检查。触发规则的事件会被添加警告数据，如规则id和规则名称。根据规则是否触发，可以将事件存储到以下一个或两个文件:

文件/var/ossec/logs/archives/archivesjson包含所有事件，不管它们是否触发了规则。

文件/var/ossec/logs/alerts/alertsjson只包含触发规则的事件。

Wazuh消息协议使用的是192位Blowfish加密，完全实现了16轮，或者AES加密，每块128位，密钥256位。

42Wazuh-Elastic通信

在大型部署中，Wazuh服务器使用Filebeat使用TLS加密将警报和事件数据发送到弹性堆栈服务器上的loghide (5000/TCP)。对于单主机架构，Logstash可以直接从本地文件系统读取事件/警报，而无需使用Filebeat。

Logstash对输入的数据进行格式化，并可选择在将数据发送到Elasticsearch(端口9200/TCP)之前丰富GeoIP信息。一旦数据被索引到Elasticsearch，就会使用Kibana(端口5601/TCP)来挖掘和可视化信息。

Wazuh APP运行在Kibana内部，不断查询RESTful API (Wazuh管理器上的端口55000/TCP)，以便显示服务器和代理的配置和状态相关信息，并在需要时重新启动代理。此通信使用TLS加密，并使用用户名和密码进行身份验证。

五、所需端口

对于安装Wazuh和Elastic堆栈，必须有几个网络端口可用并打开，以便不同组件之间能够正确通信。

六、档案数据存储

除了发送到Elasticsearch之外，警报和非警报事件都存储在Wazuh服务器上的文件中。这些文件可以是JSON格式( JSON)和/或纯文本格式(日志-没有解码字段，但更紧凑)。这些文件每天使用MD5和SHA1校验和进行压缩和签名。目录和文件名结构如下:

建议根据Wazuh Manager服务器的存储容量对归档文件进行轮换和备份。通过使用cron作业，您可以很容易地安排只在管理器上保留一个特定的存档文件时间窗口(例如，去年或过去三个月)。

另一方面，您可以选择完全不存储归档文件，而仅仅依赖于Elasticsearch来存储归档文件，特别是在运行定期的Elasticsearch快照备份和/或具有碎片副本的多节点Elasticsearch集群以获得高可用性时。您甚至可以使用cron作业将快照索引移动到最终的数据存储服务器，并使用MD5和SHA1算法对其进行签名。

1、相信经常进行编程的朋友都知道，当程序出错的时候可以查看服务器日志来了解解决错误。那么，以Win2008为例，讲述怎么查看服务器日志。

2、方法/步骤：

（1）进Win2008服务器，点击开始，找到控制面板。

（2）点击进入控制面板，找到管理工具。

（3）找到管理工具，点击事件查看器。

（4）进入事件查看器，展开Windows日志，点击系统，右侧会显示出信息。

（5）查看事件查看器的右方，我们会看到属性选项，红框中已经圈出。

（6）点击属性后，我们会看到服务器日志的路径。

（7）打开C：\Windows\System32\winevt，再打开Logs文件夹，就会看到服务器日志。

Linux操作系统主要有以下三大应用领域：

1 Linux作为企业级服务器的应用

Linux系统可以为企业架构WWW服务器、数据库服务器、负载均衡服务器、邮件服务器、DNS服务器、代理服务器、路由器等，不但使企业降低了运营成本，同时还获得了Linux系统带来的高稳定性和高可靠性，且无须考虑商业软件的版权问题。

2 嵌入式Linux系统应用领域

由于Linux系统开放源代码，功能强大、可靠、稳定性强、灵活而且具有极大的伸缩性，再加上它广泛支持大量的微处理体系结构、硬件设备、图形支持和通信协议，因此，在嵌入式应用的领域里，从因特网设备（路由器、交换机、防火墙，负载均衡器）到专用的控制系统（自动售货机，手机，PDA，各种家用电器），LINUX操作系统都有很广阔的应用市场。特别是经过这几年的发展，它已经成功地跻身于主流嵌入式开发平台。

3 个人桌面Linux应用领域

所谓个人桌面系统，其实就是我们在办公室使用的个人计算机系统，例如：Windows xp、windows 7、Mac等。Linux系统在这方面的支持也已经非常好了，完全可以满足日常的办公及家长需求。