ai合成语音堪比真人，倒映的AI语音合成技术

ai合成语音堪比真人，倒映的AI语音合成技术近日，智东西走进他们的北京总部，通过与其创始团队展开深入交流，我们了解到更多这家公司的诞生与成长故事，也看到了不少他们对AI语音技术创新的探索和坚持。在北京建外SOHO的一间办公室里，这家团队规模不到20人的新兴企业，正酝酿着一场围绕语音合成领域的新一轮抢位赛。倒映有声的核心团队大多出身于百度、微软、阿里等公司，早期小爱同学、小度智能音箱、百度语音导航、百度呼叫中心等语音产品底层技术的构建，都少不了这群技术专家的身影。基于端到端神经网络和深度学习合成器，倒映有声自研了情绪和情感控制模块，在音色模拟、情感展现、定制化服务、多语种等方面都已达行业领先水平。其融资也在快速推进中。此前，这家创企已完成2019年5月300万元的天使轮融资、今年5月千万级人民币的Pre-A轮融资，并正在启动A轮融资，目标规模为2000-3000万元，以加快技术研发、加速垂直场景的产品落地。

不到半年，仅成立两年的TTS（语音合成）科技创企倒映有声又开启新一轮融资了。

如今，电子书、广播剧等以声音为载体的“耳朵经济”快速兴起，其中有些堪比专业播音员的声音，其实是由人工智能（AI）合成出来的。

相比真人播音员，AI语音合成技术不仅大大缩短配音时间，而且更加节约制作成本和人力成本。以提供语音合成系统及解决方案起家的倒映有声，即是在做这样的事。

过去一年，倒映有声上线的有声读物制作平台，其AI主播每日单机生产速度已超500万字，录制成本可节约超90%。今年3月，它与中央广播电视总台音频客户端“云听”APP达成合作，开展基于央广总台IP和融媒体领域的AI产品研发，这意味着其业务已成功打入“国家队”。

倒映有声的核心团队大多出身于百度、微软、阿里等公司，早期小爱同学、小度智能音箱、百度语音导航、百度呼叫中心等语音产品底层技术的构建，都少不了这群技术专家的身影。

基于端到端神经网络和深度学习合成器，倒映有声自研了情绪和情感控制模块，在音色模拟、情感展现、定制化服务、多语种等方面都已达行业领先水平。

其融资也在快速推进中。此前，这家创企已完成2019年5月300万元的天使轮融资、今年5月千万级人民币的Pre-A轮融资，并正在启动A轮融资，目标规模为2000-3000万元，以加快技术研发、加速垂直场景的产品落地。

在北京建外SOHO的一间办公室里，这家团队规模不到20人的新兴企业，正酝酿着一场围绕语音合成领域的新一轮抢位赛。

近日，智东西走进他们的北京总部，通过与其创始团队展开深入交流，我们了解到更多这家公司的诞生与成长故事，也看到了不少他们对AI语音技术创新的探索和坚持。

从左到右分别为倒映有声联合创始人兼CTO李骁、倒映有声创始人兼CEO肖朔、倒映有声联合创始人兼CMO何培成

一、助推百度小米智能音箱诞生，倒映有声的起航

2013年左右，硕士毕业于北京航空航天大学云计算专业的肖朔，加入了百度语音技术部工作。同期加入的，还有刚从英国帝国理工大学人工智能专业硕士毕业回国的李骁。这时，百度的人工智能（AI）业务才刚刚起步。

在百度期间，肖朔与李骁所在的团队开发了国内首款情感语言合成系统，并先后研发了小度智能音箱、百度呼叫中心等产品，给未来百度智能语音生态的构建和丰富打下了重要基础。

此外，二人还曾任职于猎豹移动投资的AI创企——猎户星空，在一年时间里与初创团队共同参与了小米首款小爱智能音箱的开发项目。

在这几年摸爬滚打的过程中，正是这两段从0到1构建技术方案的经历，让肖朔与李骁逐渐产生了创业的想法。恰好在猎户星空打拼的经历，也让他们接触了许多创意知识和经验，“消除了对创业的恐惧感。”

2019年，随着百度语音技术已步入成熟发展的正轨，其语音技术战略重点已不在语音合成，更多是聚焦在语音交互。与此同时，得益于硬件设施的完善、算力的增强，以及深度学习应用场景的进一步拓展，曾一直处于早期发展阶段的语音合成技术终于有了变革性突破。

因此，肖朔和李骁决定离开百度，开启创业生涯。2019年3月，倒映有声于杭州正式注册成立，由于跟随他们一同出来创业的还有不少原百度团队的伙伴，他们也选择将公司总部“落户”北京，并在成立两个月后拿下300万人民币的天使轮融资。

肖朔和李骁的创业之旅正式起航，倒映有声的挑战也才刚刚开始。

二、押注有声书和AI新闻播报，语音合成想象空间巨大

不过，AI语音的赛道如此广泛，倒映有声为何坚定地选择语音合成赛道？

在肖朔看来，语音识别是最早爆发的语音技术，科大讯飞、云知声等公司已深耕多年，做出了智能医疗、智能翻译笔、智能会议录入系统等成熟产品，给新玩家留下的市场机会并不多。

技术方面，李骁认为目前语音识别技术已进入了单纯比拼识别准确率的成熟阶段。相比之下，语音合成仍有许多待发掘的细分场景，包括广播剧、有声书、游戏配音，甚至亚文化中的虚拟偶像等，都是未来的落地方向，想象空间巨大。

例如，以往有声书、广播剧等长音频作品在制作过程中，需要人工对大量文字脚本进行前期画本、中期配音、后期剪辑等工作，整套流程要花费几个月时间，还涉及不少人工成本。但如果使用语音合成技术，能极大地压缩各个环节中的时间和财务成本，只需几天甚至几个小时，就能完成一个长音频作品的制作。

再比如影视和游戏配音中，为了保证用户的观影及游戏体验，制作团队需要花大量时间筛选适合角色的配音员，同时还需考虑配音员的休息时间、续集声音的连贯性等，这些也对制作周期带来了许多不确定性。若采用语音合成技术，只需输入脚本就能快速生成适合人物形象和作品需求的声音。

不过，由于用户对语音合成技术的体感要求非常高，如果技术无法达到媲美真人的效果水平，就很难有用户愿意付费，同时用户付费的意愿与技术效果的提高成正比。

“因此语音合成技术是整个语音交互技术链路上最后爆发的赛道，一旦爆发，市场空间会更大。”肖朔评价。

目前，倒映有声主要以有声书和AI新闻播报两大场景为切入点，为创作者、版权方和融媒体平台等客户提供高产能、低成本的音频制作服务。

有声书方面，倒映有声主要提供有声读物交易制作平台，用户通过该平台可实现从覆盖文稿画本到配音录制，再到音频剪辑的全流程云端制作，还可自主选择全自动/半自动制作，以及纯AI主播、AI人声 真人主播录制等。

例如在前期处理环节，平台可实现对文稿的筛选和清洗，如果是广播剧级别的内容，还能对内容进行深层次的改造，包括配音的角色划分、性格描述刻画、情绪风格等要素，以改编成适合收听的文本。

AI新闻播报方面，倒映有声与中央广播电视总台音频客户端“云听”APP合作打造AI新闻主播，提供音频内容服务的一站式解决方案。和国内其他AI新闻主播相比，倒映有声的播音效果情绪更加饱满、自然，在音色模拟、情感展现、多语种等方面都已达业内领先水平。

倒映有声语音合成技术在云听APP上的应用实例

三、背后的技术城池构建，语音合成的三大优势

不管是有声书还是AI新闻播报背后，都离不开倒映有声在语音合成领域的技术积累和创新。

李骁谈道，以前传统的语音合成技术主要有两种方式，分别为拼接法和参数法。例如最初的小米小爱同学就是采用拼接法，几乎使用真人的声音片段进行算法拼接组合，优势是音色和自然度等效果好，缺点在于操作复杂度极高，对数据量需求也非常大。

“当时我们让配音员录了将近半年时间，前后加起来上百个小时，才将小爱同学打磨到一个非常好的水平。”李骁说。

随着端到端深度学习逐步拓展到语音合成领域，语音合成技术得到了质的飞跃。

一方面，基于深度学习的语音合成技术，其内部计算模块和网络构建更为复杂，不管是参数量还是技术复杂度，都远远超过以往水平；另一方面，内部结构的复杂也使得模型搭建完成后，后续的使用会变得非常简单，无需再用大量数据去做底层支撑。

智能语音合成结构（图源：头豹研究院）

整体来看，倒映有声的语音合成技术主要拥有三方面核心优势。

一是拟真度，这是语音合成技术的核心。语音合成通常覆盖有声绘本、有声读物、新闻播报、呼叫中心等多个应用场景，不同场景下的技术表达方式与操作逻辑都有着较大区别，例如小孩儿、成年人、老年人等不同音色，或是模拟不同动物、怪兽的发音，都是一个较大的课题。

倒映有声则能大大减少语音合成和真人表达之间的差异性，拉近合成声与真人之间的距离，合成后的声音采样率达48kHz，更接近真人在录音棚中录制的声音，而市场上主流合成采样率为16kHz。

在多情感方面，倒映有声的语音合成技术还能将情感表达得更精准、细腻和丰富。同时，它还支持英文、中英文混合合成，跨语种定制成本低。

二是定制化能力。基于过去两年的数据积累，倒映有声在自己平台上已沉淀了上千位真人主播，其语音合成定制化能力已达到只需200句话（约30分钟时长），就能几乎100%还原一个人的声音，并且能达到商业化落地的水平。

甚至用户只需录10-15句话，倒映有声就能将声音以90%的相似度“克隆”下来，但“克隆”下来的主要是声线，句子数非常小，所以在情绪还原上还需其他算法技术进行弥补。

三是语音合成技术的结合性。除了语音合成这一单点技术外，倒映有声还很关注与之强相关的上下游技术点。例如在有声读物场景，倒映有声已落地了全自动画本能力，每句话该用哪个音库、该用什么情感风格，都与语音合成技术有着强相关的绑定关系。

四、有声书行业高速发展背后，倒映有声的下一步规划

从2019年3月成立至今，倒映有声将近花了一年多时间在做底层技术的打磨和积累，直到2020年5月开始正式商业化。2020年间，他们9月跑通有声书赛道，12月进入广电融媒体赛道……其中最大的变化在于联合创始人兼CMO何培成的加入。

“何校长补齐了我们的市场商务团队，让倒映有声从一家纯粹的技术输出型公司，转变成了产品服务公司。”肖朔提到，在这个转变中，公司针对几个垂直场景形成了完整的产品服务，在打开市场局面的同时进一步扩充了公司营收。

“去年公司主要聚焦在技术和产品阶段，营收基数较低。”何培成谈道，今年公司营收出现了明显爆发，预计将有大几百万的收入，同比增长700%。

今年，倒映有声的主要目标还是集中在技术和市场两个方面，一是夯实已切入的有声书和AI新闻播报市场，做出标杆客户，实现更大规模收入的同时提升市场占有率，这也是今年他们最核心的目标；二是希望基于自身的语音合成技术，延伸到更多商业场景。

至于技术方面，李骁认为目前语音合成的关键挑战是如何让情绪表达更加细腻，“这将是我们持续深挖的点，只有把它攻克了，我们才有可能让语音合成技术进入到更多场景中。”他说，如何加强语音合成在长音频中的自然和流畅感也是一个难点，因为目前语音合成仍聚焦在单句的合成上。

简单来说，现阶段语音合成技术的最大瓶颈已不在算力上，而是语音合成技术本身，如何才能用更好的数学模型来解释人们发音的生理构造和原理，也许是语音合成技术下一个最重要的突破口。

因此倒映有声的下一步技术研发方向，一方面将从深度出发，持续挖掘情感的细腻表达，更好地控制在长文本上连贯的渐强、渐弱自然表达。同时，更低成本的定制化也是重点之一。

另一方面则从广度出发，加强和语音合成强相关的上下游技术链路，包括自然语言处理（NLP）方面的自动角色划分、文本级情感预测等重点。李骁认为，再往下游走也有不少需要通过音频驱动的场景，例如语音驱动虚拟人物的面部表情或肢体表达。

“整体来看，语音合成在有声书和融媒体方向的落地都比较清晰了，真正挑战是开拓增量场景。”肖朔谈道，未来他们也将向东南亚地区，以及俄罗斯、日本、韩国等非英文母语国家提供服务，进一步拓展海外业务范围。

结语：语音合成技术爆发潜力巨大

智能语音作为当下发展如火如荼的技术，已成为各产业智能化过程中不可或缺的重要工具，尤其是语音交互和语音识别技术，已深入到人们生活、工作的方方面面。相比之下，语音合成技术确实还未来到全面爆发的节点。

但目前在语音合成赛道中，有声书行业的市场规模正保持着高速增长。据市场研究机构艾媒咨询数据，中国有声书行业规模已从2016年的23.7亿元增长至2019年的63.6亿元，连续三年增速超30%，预计2020年将达到95亿元左右。

倒映有声的成立，无疑为语音合成技术在更多领域的融合创新提供了一个值得借鉴的商业样本。这支创业团队让我们看到了语音合成技术更广阔的想象空间，从有声书到AI新闻播报，从游戏到影视剧，从机器人到虚拟主播……似乎一切有视听内容输出的场景，都有着不少潜在机会。

未来，随着语音合成技术逐步进入爆发阶段，我们也期待它能给各行各业带来更多创新性的突破和蜕变。

分享日志文件转运工具Filebeat

一、概述与简介

Filebeat是一个日志文件转运工具，在服务器上以轻量级代理的形式安装客户端后，Filebeat会监控日志目录或者指定的日志文件，追踪读取这些文件（追踪文件的变化，不停的读），并将来自成百上千台机器的数据发送到Elasticsearch、logstarsh、kibana或其他模块中存放（也支持Redis、Kafka等中间件输出）。

正如官方描述：“当您要面对成百上千、甚至成千上万的服务器、虚拟机和容器生成的日志时，请告别 SSH 吧。Filebeat 将为您提供一种轻量型方法，用于转发和汇总日志与文件，让简单的事情不再繁杂。”

即：Filebeat 是安装在服务器上的数据中转代理。它采集数据，并上报到Logstash或Elasticsearch等模块。【日志采集 输送展示】

注意：其实Filebeat是Beats家族中的一种类型。后续如果需要监控其他数据项的话，可以选择其他的Beat。（拓展数据源，Beats系列不仅仅只有日志选项）

Beats 有多种类型，可以根据实际应用需要选择合适的类型。

常用的类型有：

• Packetbeat：网络数据包分析器，提供有关您的应用程序服务器之间交换的事务的信息。
• Filebeat：从您的服务器发送日志文件。（本次日志监控选择此Beat）
• Metricbeat：是一个服务器监视代理程序，它定期从服务器上运行的操作系统和服务收集指标。（重点关注，OS指标监控，很轻量级，可用来收集主机运行的健康数据，后期Tiops可考虑集成）
• Winlogbeat：提供Windows事件日志。
• Auditbeat：收集Linux审计框架数据并监视文件的完整性。
• Heartbeat：通过主动探测监控服务的可用性。

二、FileBeat 的特性

之前说到Filebeat作为服务器上的数据中转代理。它采集数据，并上报到Logstash或Elasticsearch等，而且相比 Logstash，FileBeat 更加轻量化。

1. 汇总信息、采用“tail -f”原理 并支持搜索

启动 Filebeat 后，配置完成后，打开 Logs UI，直接在 Kibana 中观看对文件进行 tail 操作的过程。通过搜索栏按照服务、应用程序、主机、数据中心或者其他条件进行筛选，以跟踪您的全部汇总日志中的异常行为。

2. 性能稳健，不错过任何检测信号

在任何环境下，应用程序都有停机的可能性。 Filebeat 读取并转发日志行，如果中断，则会记住所有事件恢复联机状态时所在位置。

3. Filebeat 让事情简单化

Filebeat 内置有多种模块（auditd、Apache、NGINX、System、MySQL 等等），可针对常见格式的日志大大简化收集、解析和可视化过程，只需一条命令即可。之所以能实现这一点，是因为它将自动默认路径（因操作系统而异）与 Elasticsearch 采集节点管道的定义和 Kibana 仪表板组合在一起。不仅如此，数个 Filebeat 模块还包括预配置的 Machine Learning 任务。

4. FileBeat 不会让你的管道超负荷。

当将数据发送到 Logstash 或 Elasticsearch 时，Filebeat 使用背压敏感协议，以应对更多的数据量。如果 Logstash 正在忙于处理数据，则会告诉 Filebeat 减慢读取速度。一旦拥堵得到解决，Filebeat 就会恢复到原来的步伐并继续传输数据。

5.输送至 Elasticsearch 或 Logstash。在 Kibana 中实现可视化。

Filebeat 是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。无论您要使用 Logstash 转换或充实日志和文件，还是在 Elasticsearch 中随意处理一些数据分析，亦或在 Kibana 中构建和分享仪表板，Filebeat 都能轻松地将您的数据发送至最关键的地方。

三、FileBeat 的安装

(略)

四、FileBeat 的原理

1. FIlebeat 的4大组件

关于Filebeat的组成， 有4个非常重要的概念需要我们知道

• Prospector--探测--（收取保护费的黑社会大哥）
• Harvest--收取--（黑社会马仔小弟）
• libeat--汇集对外输送--（黑社会社长）
• registry--记录收取进度--（社团财务会计）

在一开始要提前在配置文件中写好日志所在的位置，Prospector就如黑社会大哥一样，如果要去收取保护费，它会负责探索哪里能收取到，在日志所在的位置探索。而Harvest就好比黑社会小弟一样，Prospector决定去哪里收取保护费后，就派小弟Harvest去收取。

每个Prospector 都有一个对应的Harvest，相当于每个大哥手下都有小弟，然后他们有一个共同的老大叫做Libeat，他是黑社会的社长，会汇总所有收集到的东西，然后把所有的东西（日志）传送给指定的地方去消费（酒吧、KTV等），这其中还有个非常重要的角色”registry“，它相当于一个会计，它会记录Harvest小弟 都收割了些啥，收割到哪里了，这样一但有问题了之后，harvest就会跑到会计哪里问：上次大哥指定的那几家的保护费，我收到哪里了? Registry 就会告诉Harvest 你收到哪里了，接下来继续收取就行了。这样就避免了保护费数据重复收集的问题！

2. FIlebeat 的工作流程

了解了Filebeat的四大组件后，我们再来看一下，他们是如何协调工作的。

2.1 首先就是inputs，在之前的Filebeat配置文件中，我们知道需要提前配置日志的收集位置。如下所示：

• 
  

- type: log # 读取数据源的类型为Log enabled: true paths: -/var/log/*.log -/var/log/tiops/**/*.log # 即tiops平台的所有日志位置 指定数据的输入路径为/tiops/**/*.log结尾的所有文件，注意/tiops/子目录下的日志不会被读取，孙子目录下的日志可以

2.2 接下来就是Prospector和其对应的Harvest。他们一起工作来尾随文件并将事件数据发送到你指定的输出。

Prospector负责管理harvesters并找到所有的读取源。目前有几种类型:log(日志文件) stdin(标准输入) Redis UDP和Docker 当配置日志类型时 prospector会查找驱动器上与所定义的全局路径匹配的所有文件，并为每个文件启动一个harvester。 每个prospector都在自己的Go例程中运行。（本次：- type: log）

harvester负责读取单个文件的内容，每个文件启动一个harvester。 harvester会逐行读取每个文件，并将内容发送到输出。harvester负责打开和关闭文件，这意味着在harvesters运行时文件要保持打开状态。如果在收获文件时删除或重命名文件，Filebeat将继续读取文件。这有副作用，在harvester关闭之前，磁盘上的空间被保留。默认情况下，Filebeat保持文件打开，直到达到close_inactive的设置（close_inactive默认为5分钟，即5分钟之内，没有最新的日志信息产生则关闭文件句柄）。

关闭harvester有以下情况：

• 如果在harvester还在读取文件时文件被删除，那么文件处理程序关闭，释放基础资源。
• 只有在scan_frequency过后，文件的采集才会重新开始。（scan_frequency参数默认为10秒，每隔10秒prospector检查目录中日志文件的变化情况）【扫描文件的频率】
• 如果在harvester关闭的情况下移动或移除文件，则不会继续收集文件。

注1：上面说在harvesters运行时文件要保持打开状态，那Filebeat怎么保持文件状态呢？

Filebeat保存每个文件的状态，并经常刷新状态到磁盘上的注册文件（registry）。保存在安装目录的data目录下 用于记住harvester读取的最后一个偏移量，并确保所有日志行被发送（到输出）。如果输出，比如Elasticsearch 或者 Logstash等，无法访问，那么Filebeat会跟踪已经发送的最后一行，并只要输出再次变得可用时继续读取文件。

当Filebeat运行时，会将每个文件的状态新保存在内存中。当Filebeat重新启动时，将使用注册文件中的数据重新构建状态，Filebeat将在最后一个已知位置继续每个harvester。对于每个输入，Filebeat保存它找到的每个文件的状态。因为文件可以重命名或移动，所以文件名和路径不足以标识文件。对于每个文件，Filebeat存储惟一标识符，以检测文件是否以前读取过。如果你的情况涉及每天创建大量的新文件，你可能会发现注册表文件变得太大了。

（为了减小注册表文件的大小，有两个配置选项可用：clean_remove和clean_inactive。对于你不再访问且被忽略的旧文件，建议您使用clean_inactive。如果想从磁盘上删除旧文件，那么使用clean_remove选项。）

注2：Filebeat如何确保至少投递一次（at-least-once）？

Filebeat保证事件将被投递到配置的输出中至少一次，并且不会丢失数据。Filebeat能够实现这种行为，因为它将每个事件的投递状态存储在注册表文件中。在定义的输出被阻塞且没有确认所有事件的情况下，Filebeat将继续尝试发送事件，直到输出确认收到事件为止。如果Filebeat在发送事件的过程中关闭了，则在关闭之前它不会等待输出确认所有事件。当Filebeat重新启动时，发送到输出（但在Filebeat关闭前未确认）的任何事件将再次发送。这确保每个事件至少被发送一次，但是你最终可能会将重复的事件发送到输出。你可以通过设置shutdown_timeout选项，将Filebeat配置为在关闭之前等待特定的时间。

（ Filebeat会将每个event的传递状态存储在注册表中 在确认已经收到事件之前 会一直尝试发送事件。）

与input结合起来就是，一个input负责管理harvesters，并找到所有要读取的源。

如果input类型是log，则input查找驱动器上与已定义的glob路径匹配的所有文件，并为每个文件启动一个harvester。此时每个input都在自己的Go例程中运行。

filebeat采取的是多个线程同时去读多个文件，每个文件读到数据会被封装为一个event，event经过一系列的processors处理，最终会放在一个队列，这个队列（pipeline）在发送到输出。

总结：当开启Filebeat程序的时候，它会启动一个或多个探测器（prospectors）去检测指定input的日志目录或文件，由于类型是log文件，则input查找驱动器上与已定义的golang glob的Paths路径匹配的所有文件，对于探测器找出的每一个日志文件，filebeat启动收割进程（harvester），此时每个input都在自己的Go例程中运行。每一个收割进程读取一个日志文件的新内容时，filebeat采取的是多个线程同时去读多个文件，每个文件读到数据会被封装为一个event，event经过一系列的processors处理，最终会放在一个队列，这个队列（pipeline）在发送到输出。

3. FIlebeat 的模块

• 
  

[root@192-168-108-22modules.d]# pwd /etc/filebeat/modules.d [root@192-168-108-22 modules.d]# ll #支持的模块类型total 84-rw-r--r-- 1 root root 475 Apr 6 06:11 apache.yml.disabled-rw-r--r-- 1 root root 280 Apr 6 06:11 auditd.yml.disabled-rw-r--r-- 1 root root 1369 Apr 6 06:11 elasticsearch.yml.disabled-rw-r--r-- 1 root root 376 Apr 6 06:11 haproxy.yml.disabled-rw-r--r-- 1 root root 651 Apr 6 06:11 icinga.yml.disabled-rw-r--r-- 1 root root 470 Apr 6 06:11 iis.yml.disabled-rw-r--r-- 1 root root 366 Apr 6 06:11 iptables.yml.disabled-rw-r--r-- 1 root root 499 Apr 6 06:11 kafka.yml.disabled-rw-r--r-- 1 root root 293 Apr 6 06:11 kibana.yml.disabled-rw-r--r-- 1 root root 672 Apr 6 06:11 logstash.yml.disabled-rw-r--r-- 1 root root 296 Apr 6 06:11 mongodb.yml.disabled-rw-r--r-- 1 root root 519 Apr 19 17:35 mysql.yml.disabled-rw-r--r-- 1 root root 672 Apr 6 06:11 nginx.yml.disabled-rw-r--r-- 1 root root 495 Apr 6 06:11 osquery.yml.disabled-rw-r--r-- 1 root root 305 Apr 6 06:11 postgresql.yml.disabled-rw-r--r-- 1 root root 566 Apr 6 06:11 redis.yml.disabled-rw-r--r-- 1 root root 266 Apr 6 06:11 santa.yml.disabled-rw-r--r-- 1 root root 299 Apr 6 06:11 suricata.yml.disabled-rw-r--r-- 1 root root 679 May 20 16:09 system.yml.disabled-rw-r--r-- 1 root root 302 Apr 6 06:11 traefik.yml.disabled-rw-r--r-- 1 root root 426 Apr 6 06:11 zeek.yml.disabled

Filebeat模块简化了公共日志格式的收集、解析和可视化。

一个典型的模块（例如，对于Nginx日志）是由一个或多个fileset组成的（以Nginx为例，access 和error）。

一个fileset包含以下内容：

• Filebeat 输入配置，其中包含要默认的查找或者日志文件路径。这些默认路径取决于操作系统。Filebeat配置还负责在需要的时候拼接多行事件。
• Elasticsearch Ingest Node 管道定义，用于解析日志行。
• 字段定义，用于为每个字段在Elasticsearch中配置正确类型。它们还包含每个字段的简短描述。
• 简单的Kibana dashboards，用于可视化日志文件。

Filebeat会根据你的环境自动调整这些配置，并将它们加载到相应的Elasticstack 组件中。

即Filebeat提供了一组预先构建的模块，你可以使用这些模块快速实现并部署一个日志监控解决方案，包括样例指示板和数据可视化。

这些模块支持常见的日志格式，如Nginx、Apache2和MySQL，可以通过一个简单的命令来运行。

启动：

启用你想运行的模块。例如：

• 
  

./filebeat modules enablesystem nginx mysql./filebeat modules disable systemmysqlfilebeat 已经yum安装完成。可以作为全局命令[root@192-168-108-22 ~]# filebeatmodules disable system mysqlDisabled systemDisabled mysql[root@192-168-108-22 ~]# filebeat modules listEnabled: Disabled:apacheauditdelasticsearchhaproxyicingaiisiptableskafkakibanalogstashmongodbmysqlnginxosquerypostgresqlredissantasuricatasystemtraefikzeek

启用模块完成后需要设置初始环境：./filebeat setup -e

然后运行Filebeat： ./filebeat -e

最后就可以在Kibana中查看你的数据。

关于模块包含很多种类型以及用法，这里就不一一描述，可以按需求去详细了解配置。

五、FileBeat 的配置项（摘自网络）

为了配置Filebeat，你可以编辑配置文件 filebeat.yml，位于/etc/filebeat目录下。

配置inputs

为了手动配置Filebeat（代替用模块），你可以在filebeat.yml中的filebeat.inputs区域下指定一个inputs列表。

列表时一个YMAL数组，并且你可以指定多个inputs，相同input类型也可以指定多个。例如：

• 
  

- type: log paths: # 从日志文件读取行，为了配置这种input，需要指定一个paths列表，列表中的每一项必须能够定位并抓取到日志行。 - /var/log/system.log - /var/log/wifi.log- type: log paths: - "/var/log/apache2/*" fields: apache: true

你还可以应用设置其它额外的配置项（比如，fields include_lines exclude_lines multiline等等）来从这些文件中读取行。你设置的这些配置对所有这种类型的input在获取日志行的时候都生效。

配置项

paths（重要）

例如：/var/log/*/*.log 将会抓取/var/log子目录目录下所有.log文件。它不会从/var/log本身目录下的日志文件。如果你应用recursive_glob设置的话，它将递归地抓取所有子目录下的所有.log文件。

• 
  

recursive_glob.enabled

允许将**扩展为递归glob模式。启用这个特性后，每个路径中最右边的**被扩展为固定数量的glob模式。例如：/foo/**扩展到/foo， /foo/*， /foo/**，等等。如果启用，它将单个**扩展为8级深度*模式。这个特性默认是启用的，设置recursive_glob.enabled为false可以禁用它。

encoding（重要）

读取的文件的编码，下面是一些W3C推荐的简单的编码：

• plain latin1 utf-8 utf-16be-bom utf-16be utf-16le big5 gb18030 gbk hz-gb-2312
• euc-kr euc-jp iso-2022-jp shift-jis 等等

plain编码是特殊的，因为它不校验或者转换任何输入。

exclude_lines（重要）

一组正则表达式，用于匹配你想要排除的行。Filebeat会删除（PS：我觉得用“丢弃”更合适）这组正则表达式匹配的行。默认情况下，没有行被删除。空行被忽略。

如果指定了multiline，那么在用exclude_lines过滤之前会将每个多行消息合并成一个单行。（PS：也就是说，多行合并成单行后再支持排除行的过滤）

下面的例子配置Filebeat删除以DBG开头的行：

• 
  

filebeat.inputs: - type: log ... exclude_lines: ['^DBG']

include_lines

一组正则表达式，用于匹配你想要包含的行。Filebeat只会导出那些匹配这组正则表达式的行。默认情况下，所有的行都会被导出。空行被忽略。

如果指定了multipline设置，每个多行消息先被合并成单行以后再执行include_lines过滤。

下面是一个例子，配置Filebeat导出以ERR或者WARN开头的行：

• 
  

- type: log ... include_lines: ['^ERR' '^WARN']（如果 include_lines 和 exclude_lines 都被定义了，那么Filebeat先执行 include_lines 后执行 exclude_lines，而与这两个选项被定义的顺序没有关系。include_lines 总是在 exclude_lines选项前面执行，即使在配置文件中 exclude_lines 出现在 include_lines的前面。）

下面的例子导出那些除了以DGB开头的所有包含sometext的行：

• 
  

- type: log ... include_lines: ['sometext'] exclude_lines: ['^DBG']

harvester_buffer_size（重要）

当抓取一个文件时每个harvester使用的buffer的字节数。默认是16384。

max_bytes

单个日志消息允许的最大字节数。超过max_bytes的字节将被丢弃且不会被发送。对于多行日志消息来说这个设置是很有用的，因为它们往往很大。默认是10MB（10485760）。

json

这些选项使得Filebeat将日志作为JSON消息来解析。例如：

• 
  

json.keys_under_root: true json.add_error_key: true jsonssage_key: log

为了启用JSON解析模式，你必须至少指定下列设置项中的一个：

• 
  

　　keys_under_root

默认情况下，解码后的JSON被放置在一个以"json"为key的输出文档中。如果你启用这个设置，那么这个key在文档中被复制为顶级。默认是false。

• 
  

　　overwrite_keys

如果keys_under_root被启用，那么在key冲突的情况下，解码后的JSON对象将覆盖Filebeat正常的字段

• 
  

　　add_error_key

如果启用，则当JSON反编排出现错误的时候Filebeat添加 "errorssage" 和"error.type: json"两个key，或者当没有使用message_key的时候。

• 
  

　　message_key

一个可选的配置，用于在应用行过滤和多行设置的时候指定一个JSON key。指定的这个key必须在JSON对象中是顶级的，而且其关联的值必须是一个字符串，否则没有过滤或者多行聚集发送。

• 
  

　　ignore_decoding_error

一个可选的配置，用于指定是否JSON解码错误应该被记录到日志中。如果设为true，错误将被记录。默认是false。

multiline（重要）

用于控制Filebeat如何扩多行处理日志消息，修改filebeat配置文件
/etc/filebeat/filebeat.yml 在原来基础上面添加多行合并配置

1

2

3

4

multiline:

pattern: '^\['

negate: true

match: after

• pattern：正则表达式，匹配日志格式
• negate：默认为false，暗示匹配pattern的行归并到上一行；true暗示不匹配pattern的行归并到上一行
• match：after暗示归并到上一行的末端，before暗示归并到上一行的行首

exclude_files

一组正则表达式，用于匹配你想要忽略的文件。默认没有文件被排除。

下面是一个例子，忽略.gz的文件

• 
  

- type: log ... exclude_files: ['\.gz$']

ignore_older

如果启用，那么Filebeat会忽略在指定的时间跨度之前被修改的文件。如果你想要保留日志文件一个较长的时间，那么配置ignore_older是很有用的。例如，如果你想要开始Filebeat，但是你只想发送最近一周最新的文件，这个情况下你可以配置这个选项。

你可以用时间字符串，比如2h（2小时），5m（5分钟）。默认是0，意思是禁用这个设置。

你必须设置ignore_older比close_inactive更大。

close_*

close_*配置项用于在一个确定的条件或者时间点之后关闭harvester。关闭harvester意味着关闭文件处理器。如果在harvester关闭以后文件被更新，那么在scan_frequency结束后改文件将再次被拾起。然而，当harvester关闭的时候如果文件被删除或者被移动，那么Filebeat将不会被再次拾起，并且这个harvester还没有读取的数据将会丢失。

close_inactive（重要）

当启用此选项时，如果文件在指定的持续时间内未被获取，则Filebeat将关闭文件句柄。当harvester读取最后一行日志时，指定周期的计数器就开始工作了。它不基于文件的修改时间。如果关闭的文件再次更改，则会启动一个新的harvester，并且在scan_frequency结束后，将获得最新的更改。

推荐给close_inactive设置一个比你的日志文件更新的频率更大一点儿的值。例如，如果你的日志文件每隔几秒就会更新，你可以设置close_inactive为1m。如果日志文件的更新速率不固定，那么可以用多个配置。

将close_inactive设置为更低的值意味着文件句柄可以更早关闭。然而，这样做的副作用是，如果harvester关闭了，新的日志行不会实时发送。

关闭文件的时间戳不依赖于文件的修改时间。代替的，Filebeat用一个内部时间戳来反映最后一次读取文件的时间。例如，如果close_inactive被设置为5分钟，那么在harvester读取文件的最后一行以后，这个5分钟的倒计时就开始了。

你可以用时间字符串，比如2h（2小时），5m（5分钟）。默认是5m。

close_renamed

当启用此选项时，Filebeat会在重命名文件时关闭文件处理器。默认情况下，harvester保持打开状态并继续读取文件，因为文件处理器不依赖于文件名。如果启用了close_rename选项，并且重命名或者移动的文件不再匹配文件模式的话，那么文件将不会再次被选中。Filebeat将无法完成文件的读取。

close_removed

当启用此选项时，Filebeat会在删除文件时关闭harvester。通常，一个文件只有在它在由close_inactive指定的期间内不活跃的情况下才会被删除。但是，如果一个文件被提前删除，并且你不启用close_removed，则Filebeat将保持文件打开，以确保harvester已经完成。如果由于文件过早地从磁盘中删除而导致文件不能完全读取，请禁用此选项。

close_timeout

当启用此选项是，Filebeat会给每个harvester一个预定义的生命时间。无论读到文件的什么位置，只要close_timeout周期到了以后就会停止读取。当你想要在文件上只花费预定义的时间时，这个选项对旧的日志文件很有用。尽管在close_timeout时间以后文件就关闭了，但如果文件仍然在更新，则Filebeat将根据已定义的scan_frequency再次启动一个新的harvester。这个harvester的close_timeout将再次启动，为超时倒计时。

scan_frequency（重要）

Filebeat多久检查一次指定路径下的新文件（PS：检查的频率）。例如，如果你指定的路径是 /var/log/* ，那么会以指定的scan_frequency频率去扫描目录下的文件（PS：周期性扫描）。指定1秒钟扫描一次目录，这还不是很频繁。不建议设置为小于1秒。

如果你需要近实时的发送日志行的话，不要设置scan_frequency为一个很低的值，而应该调整close_inactive以至于文件处理器保持打开状态，并不断地轮询你的文件。

默认是10秒。

scan.sort

如果你指定了一个非空的值，那么你可以决定用scan.order的升序或者降序。可能的值是 modtime 和 filename。为了按文件修改时间排序，用modtime，否则用 filename。默认此选项是禁用的。

scan.order

可能的值是 asc 或者 desc。默认是asc。

更多配置请查看
elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html

（

这里再重点说一下 ignore_older close_inactive scan_frequency 这三个配置项

• ignore_older：它是设置一个时间范围（跨度），不在这个跨度范围之内的文件更新都不管
• scan_frequency：它设置的是扫描文件的频率，看看文件是否更新
• close_inactive：它设置的是文件如果多久没更新的话就关闭文件句柄，它是有一个倒计时，如果在倒计时期间，文件没有任何变化，则当倒计时结束的时候关闭文件句柄。不建议设置为小于1秒。

如果文件句柄关了以后，文件又被更新，那么在下一个扫描周期结束的时候变化发现这个改变，于是会再次打开这个文件读取日志行，前面我们也提到过，每个文件上一次读到什么位置（偏移量）都记录在registry文件中。）

配置output

配置Elasticsearch output

当你指定Elasticsearch作为output时，Filebeat通过Elasticsearch提供的HTTP API向其发送数据。例如：

• 
  

output.elasticsearch: hosts: ["localhost:9200"]index: "filebeat-%{[beat.version]}-%{ yyyy.MM.dd}"ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]ssl.certificate: "/etc/pki/client/cert.pem" ssl.key:"/etc/pki/client/cert.key"

为了启用SSL，只需要在hosts下的所有URL添加https即可

• 
  

output.elasticsearch: hosts: ["localhost:9200"]username: "filebeat_internal" password: "YOUR_PASSWORD"

如果Elasticsearch节点是用IP:PORT的形式定义的，那么添加protocol:https。

• 
  

output.elasticsearch: hosts: ["localhost"] protocol:"https" username: "{beatname_lc}_internal" password:"{pwd}"

配置项

• 
  

enabled

启用或禁用该输出。默认true。

• 
  

hosts

Elasticsearch节点列表。事件以循环顺序发送到这些节点。如果一个节点变得不可访问，那么自动发送到下一个节点。每个节点可以是URL形式，也可以是IP:PORT形式。如果端口没有指定，用9200。

• 
  

output.elasticsearch: hosts: ["10.45.3.2:9220" "10.45.3.1:9230"] protocol: https path: /elasticsearch

username

用于认证的用户名

password

用户认证的密码

protocol

可选值是：http 或者 https。默认是http。

path

HTTP API调用前的HTTP路径前缀。这对于Elasticsearch监听HTTP反向代理的情况很有用。

headers

将自定义HTTP头添加到Elasticsearch输出的每个请求。

index

索引名字。（PS：意思是要发到哪个索引中去）。默认是"filebeat-%{[beat.version]}-%{ yyyy.MM.dd}"（例如，"filebeat-6.3.2-2017.04.26"）。如果你想改变这个设置，你需要配置 setup.template.name 和 setup.template.pattern 选项。如果你用内置的Kibanadashboards，你也需要设置setup.dashboards.index选项。

indices

索引选择器规则数组，支持条件、基于格式字符串的字段访问和名称映射。如果索引缺失或没有匹配规则，将使用index字段。例如：

• 
  

output.elasticsearch: hosts: ["localhost:9200"] index:"logs-%{[beat.version]}-%{ yyyy.MM.dd}" indices: - index:"critical-%{[beat.version]}-%{ yyyy.MM.dd}" when.contains: message:"CRITICAL" - index:"error-%{[beat.version]}-%{ yyyy.MM.dd}" when.contains: message:"ERR"timeout

请求超时时间。默认90秒。

配置Logstash output

• 
  

output.logstash: hosts: ["127.0.0.1:5044"]

上面是配置Filebeat输出到Logstash，那么Logstash本身也有配置，例如：

• 
  

input { beats { port => 5044 } }output { elasticsearch { hosts => ["localhost:9200"] index =>"%{[@metadata][beat]}-%{[@metadata][version]}-%{ YYYY.MM.dd}" } }

配置Kafka output

• 
  

output.kafka:# initial brokers for reading cluster metadatahosts: ["kafka1:9092" "kafka2:9092" "kafka3:9092"]# message topic selection partitioningtopic: '%{[fields.log_topic]}'partition.round_robin:reachable_only: falserequired_acks: 1compression: gzipmax_message_bytes: 1000000

负载均衡

为了启用负载均衡，当你配置输出的时候你需要指定 loadbalance:true

• 
  

output.logstash: hosts:["localhost:5044" "localhost:5045"] loadbalance: true 六、FileBeat 的常见问题

1. Too many open file handler？（太多打开的文件句柄）

Filebeat保持文件处理器打开，以防它到达文件的末尾，以便它可以实时读取新的日志行。如果Filebeat正在收集大量文件，那么打开文件的数量可能成为一个问题。在大多数环境中，主动更新的文件数量很少。应该相应地设置close_inactive配置选项，以关闭不再活动的文件。

2. Filebeat没有从一个文件收集行

为了解决这个问题：

• 确保路径配置正确
• 检查这个文件是不是比指定的ignore_older值更旧
• 确保Filebeat能够发送时间到配置的输出。以debug模式运行Filebeat来检查是否可以成功发送事件：
• ./filebeat -c config.yml -e -d "*"

3. Filebeat占用了太多CPU资源

Filebeat可能配置扫描文件太过频繁。检查filebeat.yml中的scan_frequency设置。

说明：本文为Filebeat学习笔记，部分资料来自于网上。

分享如何查看一个网站使用什么技术框架

如何快捷的查看一个网站使用什么技术/技术栈/前端框架/后端框架

打开

wappalyzer/

输入你要查看的地址，回车

在输入框中输入您要查看的网站地址回车即可，这样所有的技术都会出现