本专题由熊昌伟（畅捷通信息技术股份有限公司运维总监）主要介绍日志切分运用以及打标过程中的实践方法论。
精彩视频回放，请点击这里。
以下为精彩视频内容整理：
一、畅捷通信息技术股份有限公司的介绍
畅捷通作为用友旗下成员企业，前身是成立于2005年的用友小型管理软件事业本部。畅捷通公司于2010年3月成立，并于2014年6月在香港联交所主板挂牌上市（股票代号：1588）。截止2018年年底，软件业务企业数已经超过了147万，云服务的付费企业数也达到了11万多，核心产品包括好会计、好生意畅捷贷、T+等。
二、背景
创建日志所面临的一些问题，和困惑：
1.海量信息：微服务、容器化的盛行，日志的增量都是成几何爆炸式增长。
2.抽丝剥茧：如何看懂这些日志，如何从这杂乱的日志中找出、发现问题呢？
日志的问题包括：
1.并发量大：几万个点同时并发发送数据，每天产生的各种日志与消息达到TB级。
2.类型杂： 访问类、系统类、应用类、通知、消息类等等，种类繁多、格式千奇百怪。
3.来源多：网络、服务器、手机、web、Docker等，并且要求实时性高。
4.应用深入：各块对收集来的数据都有着自己个性化的需求，监控报警、问题诊断、分析挖掘、报表等，消费模式也多种多样。
三、日志中心设计架构
整体模型
上图所示为日志中心的整体模型，必须具备以下能力：
1.博爱：广泛的兼容。无论哪种日志消息发送过来，都能准确无误的记录和存储。包括服务器的硬件、业务访问日志、第三方产品的运行日志等。
2.标准化：无论哪家产品产生出何种内容样式都要统一，才能为达标和深度挖掘提供便利。
3.扩展性：简便的与第三方的系统和平台进行对接。
整体设计
简单来说就是将整个系统抽象成接收中心、整型中心、分析中心以及调度中心四部分。
四、如何让日志说话
接收中心设计
要想让日志说话，首先需要将上图中的内容集中在一起，上图是对日志消息收集的模型。目前，不光对Zabbix、阿里云云监控、更新系统进行收集，也会对SMNP协议、UDP协议进行收集，同时还对邮件、钉钉、短信消息进行收集。由于报警和通知只能由短信和邮件通知，为了完善系统，会对邮件和短信有所支持。比如阿里云的报警和通知只能由短信和邮件推送出来，是由于没有API接口。同时，通过客户端系统的统一和分发，会把当前的消息按照实际场景的应用发到对应负责的开发和运维的人员手中。
接收数据源类型
文件：通过阿里云的日志服务收集。
消息：通过自定义插件收集。比如邮件和短信是通过这种模式进行收集的。使用函数计算对于收集过来的数据进行关联和整合，再向后端传送。
数据库：通过自定义插件（监控Binlog日志）收集。
钉钉消息：通过自定义机器人收集。
邮件：通过自定义插件收集。
短信：通过自定义插件（监控上行消息）收集。
触发事件（应用更新、zabbix报警、工单等）：通过自定义插件收集。
自定义插件接收
让日志说话
访问日志的解读
如上图所示为标准的访问日志分析图，包括pv、uv、相应时间、状态码的分布、来源ip分布、后台应用ip等。
上图是比较常用的解读日志的场景。
让日志说话的第一步是使用日志做性能监督，从上图可以看到应用的相应时间。为什么这么做，因为有太多的系统每次上线时都会有性能和压力测试，可是经过几轮日常的更新之后，可能会变化，这时需要将所有网络中的访问日志做汇总，按文件的大小进行排序，查看是否有漏网的文件，都要先提交到线上。通过监督的模式，就可以及时的发现这样的问题，可以给用户带来使用体验上的优化，同时也能节约公司大量的流量成本。此外，响应时间也是随着日常更新的迭代，包括用户产生的垃圾数据和错误数据，这时可以通过后台的自监督去发现这些问题，并将这些问题收集过来，转给相应的开发进行相应的处理。而不是被动的等着客户打来反馈电话，从而加快问题的处理速度。
利用Apdex应用性能指数，测量用户体验
访问日志里的响应时间做应用性能的指标时，将满意样本数T值取1，容忍样本数取4，公式如上图所示。图中包含当前网站的分值、昨天的分值以及变化率。用来监督上线的产品在昨天和今天的变化，出现问题时及时反馈给研发部门，能够及时的处理，保证用户的体验。
LDAP日志
上图是通过加工LDAP日志得出的，可以直观的看到各服务器的登录状态、登录次数。同时可以进行高危操作事件的审计和关注。通过关注，可以提前发现潜在的风险点，同时也能对一个高频重复的操作进行提炼和自动化。
将日志和消息进行简单的二次加工后使之更加易读，也可以对日志进行后期的二次加工。上图为对日志进行关联达标的简单模型。首先将日志发送到HSDES系统里做关联对应，然后打上各种标签。
以上图为例，是一个标准的DNS日志的基础分析图表。可以看出域名在内网中，解析次数比较多，记录类型的调用，每个IP地址发了多少请求。若服务器的IP地址与应用对应时，就可以得到下图。
通过对日志内容的关联整理，就可以非常清晰的绘制出一张外网应用于内网的简单关系调用图。因从日志中可以看到是哪台机器发起了对哪些域名的解析请求，而这些机器中安装了什么应用，HSDES系统都是有相应的对应的，经过数据的对应就可以画出整个网络的调用拓扑，并且还可以通过查询时间，发现最近的应用调用是否存在新的变化。例如，原来A应用于B应用是没有依赖的，但是经过查询可知A应用和B应用有DS的域名解析，得知它们之间存在调用关系。
应用日志简单打标
根据上图所示，出现了很多的未知错误。不容易分析。
看到了上图的日志，感觉就很清晰，体现了日志会“说话”的状态。例如，在8点40分是发现了无法调用，通过查看上图，得知appkey没有访问权限突然上升，这时就会想到应用突然调不通是否是由于appkey过期导致，通过询问接口对应的人员查看appkey是否出现问题，增加了处理问题的速度。不需要担心研发人员要去跨产品查找问题。
日志标记的错误投递到数据库中，由研发人员通过上图的外部页面对错误的日志进行标记，当标记完成后，通过日志服务的ETL功能直接将这些对应的字段替换为标记字段进行展示。用错误代码表示日志标记的错误，后续处理可以非常方便、快捷并且直观。
五、如何让日志主动说话
想要实现让日志主动说话，需要结合分析中心和调度中心这两个部分。
分析中心
分析中心就是要将想法进行模型固化。固化是指变成自动化的脚本，让机器自主的执行和处理。
调度中心
调度中心是指接受了机器自动处理的指令后，完成需要的动作和步骤。例如，收到故障通知后，能够发出报警，同时将揭露的问题作为一个记录。视为标准的闭环迭代过程。
流水线
上图为流水线示意图，将原始日志进行语意切分和序列化后，对应到场景分析中。在策略组里找到相应的执行策略，再发到外部服务中，用外部服务去调用ansible或者消息转发等操作。按照1,2,3,4,步操作。
让日志主动说话得利于如上图所示的指挥中心。
通过上图中的选项选出所需要的执行。
可以通过邮寄、短信、电话或者创建一个揭露问题把整个问题管理起来，对应问题所存在的IP地址进行精准的送达。
上图为DNS解析错误故障自愈的配置。
上图中“1,3,7天发生此条报警次数为1,1,1”可以看出此条报警发生的频率。报出此信息时需要重点关注。比如报警次数很大，是指哪台服务器进行调试。上图所示为产品更新的通知场景。每天所有产品的上线加起来都会有几十次，并且这些操作都不是通过运营人员进行操作的，都是通过各个部门的研发人员使用所提供的发布系统自主的发布上线，这时就需要有个机制用来保障，当A部门应用上线时所调用的B部门要知道这条消息，就需要通过消息中心做上图所示的记录。
当发现某台服务器报警时，通过这台服务器的IP地址去查询IP地址所承载的应用是否有更新，当服务器有更新时，就通过上图消息通知。
此外，还可以做一些磁盘中心的故障回收，当收到上图左侧的消息后，调用一些自愈的脚本，比如尝试清除日志文件、发现并删除3天前压缩文件2个、发现并清除大于500M文件2个、磁盘报警已清除。当然也有不成功的时候，比如右侧信息。除了磁盘空间还可以做一些主机时间和内存泄露的故障等。
六、阿里云日志服务实践
SLS实践
通过直接使用阿里云服务的同环比函数，可以快速的得出所有网站当前的值，并且具有实时性。如上图所示。
此外，通过比较网站的同环比为200量的变化、非200量的变化以及响应时间的变化，通过比较这些信息发现潜在的问题。也可以当怀疑某个网站不正常时，判断是否为不正常。通过输入网站的域名，可以快速、精准的定位到当前200个错误是怎样的，非200个错误是怎样的。
赋值在阿里的服务日志里也是非常容易实现的，只需要将上图中查询语句的红框里的内容做变量匹配，后面的报表就会自动的发生变化。
有了同环比后，报警的发送会变得准确，与原来的阈值相比有所提高，原来阈值的访问率到达1000时才报警，但是每天高峰时都是3000，每天低峰时只有100。
例如上图中近5分钟数据增长的同环比超过了150%，查看是否有问题。150%是可以根据自己的业务进行调整的。还有各域名超过200的访问值的变化，显示最近10分钟数据增长的同环比超过300%被认为是有问题的。应用类的报警改成上图方式后，可以及时反映当前应用的状态。
异常检测
在海量指标中快速定位异常将用到阿里的一个函数为：ts_predicate_arma
例如，维护的网站有几百个，有的网站有几千个接口，当发生故障时，只是由于某个核心接口的异常导致，这时要发现这个故障，就可以使用日志服务异常检测中的ts_predicate_arma函数。
通过异常检测方法认为有问题的地方显示出来，可以使用上图中的输入快速的筛选。
根因分析
首先对各块汇集过来的数据进行标记，然后在与应用的配置信息进行关联和整合，最后通过时序可以发现一些简单的故障根因。
比如存在一个报警cia，首先要关注cia所调用的第三方服务是否正常。上图显示没有问题，继续往下查找，绿色框显示是没有问题的，直到应用服务器D为红色框，则为出现问题，并且发现此内存小于50兆，CPU负载较高，从而发现问题的根因。对所有日志进行认真的切分和达标是很重要的一部分，使应用的一些故障模型可以非常准确的提炼出来，从而可以实现故障预测。
扫描下方二维码，加入开发与运维钉钉交流群，查看更多精彩内容。
