8 月 27 日晚上八点，七牛云高级解决方案架构师程雪松在 IT 大咖说进行了题为《挖掘传统行业日志大数据的无限价值》的直播，对传统行业运维常见困境和统一日志管理的必要性进行了深入解析，并通过 Pandora 的一些真实用户案例和大家详细阐述了如何挖掘传统行业日志大数据的无限价值。
本文是对直播内容的整理，共分为上下两篇，上篇主要介绍传统行业运维常见困境和统一日志管理的必要性，以及日志分析几个典型场景。
首先我们谈一谈什么是运维。

很多人对运维有自己的理解，他们认为运维是一件特别简单的事情。当我们企业购买了一些信息化的产品，硬件、软件等，我们需要有一个团队让它正常的运转。但是在运转的过程当中，不可避免的会出现各种问题，这就需要有一个专门的团队来做保障。如果你只是把运维简单的理解为一个平台，我觉得这种认识可能比较肤浅。到底什么是运维呢？网上有很多理解 ，关于运维工作的划分，包括网站的运维、系统的运维、网络的运维、数据库的运维、IT 的运维，运维开发、运维安全。从这些分工来看，运维其实是一个复杂、系统的一个工程。
· 运维要知道准确的系统瓶颈点，进而知道系统准确的容量；在系统出现瓶颈前，知道如何快速提供容量。
· 知道系统的风险点，可以协调风险点上下相关关联模块，做出冗余策略；相比集中解决单点模块稳定性，更合理。
· 长期从事相关工作，积累较多的架构设计经验，可以指导新架构设计和审核。
· 从公司不同业务角度看，运维可以从中抽象相同的模块，进行统一管理，去形成企业内部的能力平台、基础设施平台，包括我们可以共用的一些微服务，那么形成这样有效的平台和自动化的管理方法。
从运维的价值来看，我们了解到运维是一个复杂、系统的工程。对运维工程师来说，日常需要处理非常多的工作，如何帮助运维工程师做好日常的运维工作，至关重要。但是现在运维工程师在日常运维里遇到很多问题，最主要的原因是现在的 IT 环境越来越复杂。因为信息化建设不是一蹴而就的，公司会在不同的阶段建设不同的业务系统、不同的应用支撑、采购不同的硬件设备。但是由于采购周期的互相递进、堆叠，其实会造成内部有众多不同型号的网络设备、海量不同型号的服务器、各种各样的虚拟化方案、不同的操作系统、多样化的应用软件和数据库。
其实现在很多数据库是由应用软件的开发商来决定的，有些开发商更熟悉 MySQL，他可能用 MySQL 作为应用支撑的数据库，有一些开发商原来一直都在用 Oracle，他可能就会用 Oracle 来做应用支撑。各种不同的业务软件、不同的业务系统都会有不同的业务架构和底层的不同平台，每个平台又会带来不同的监控系统、自己内部相关的一些工具，这会导致一个企业整体的 IT 部门环境变得很复杂，从而带来很多问题：
· 监控软件纷繁复杂众多监控软件，无法统一管理；
· 监控告警杂乱无章监控方式存在各种不足，在问题发生时无法及时感知；
· 排错时间长系统复杂，排查问题流程漫长，在发生问题后无法快速准确的定位问题原因；
· 全局性弱无法对全局情况有一个全面的掌控，从而无法有效预测问题的发生；
· 安全挑战大无法高效发现安全性问题，比如×××侵入和违规操作；
· 管理员管理难度大面对众多异构的监控软件，管理员需要承担极大的心智负担；
现在大量的运维团队都是通过日志来进行运维管理。原因是什么呢？
日志系统将我们系统运行的每一个状况信息都使用文字或者日志的方式记录下来。这些信息我们可以理解为设备或是普通人在虚拟世界的行为的记录和投影。这些信息有助我们观察系统运行过程中的正常状态和系统运行错误时快速定位错误位置的途径等。
日志的类型很多，主要包括系统日志、应用程序日志和安全日志还包括很多数据库的日志，等等。每条日志都记载着时间戳、相关设备名称、使用者及操作行为等相关的描述，系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，及时分析相关问题、追查错误根源纠正错误。
下面我们举了几个相关的例子，大家在日常工作中也会遇到一些这样的监控或是安全的日志。

日常对日志的分析主要是应对以下几个场景：
第一个是机房集中化监控，特别是现在很多机房的建设都会存在大量的不同品牌的服务器、网络设备，特别是大型的企业，他们往往不愿采购单一品牌的服务器，为了避免出现一些厂商依赖的风险，所以会出现机房里存在不同品牌甚至异构的一些设备，运维人员需要对机房有一个管控平台。将交换机、服务器等相关的一些硬件设备，包括你可能涉及到的一些软件上的日志，以及保安系统的日志、业务的日志、用户访问行为的日志等等。将这些日志统一的收集整理起来，形成一个机房的日常的运行状态的一个监控。
上图的示例图是我们在一个案例里面给客户做的展示大屏，他可以反映整个机房的运行状况，运维人员能够很直观的通过大屏知道机房整体的日常运行状态。下面是我们设计的架构图，我们通过交换机、服务器上采集到相关的硬件、软件的一些监控指标，然后读取到我们的日志管理系统里，对日志进行统一的存储、分析、监控、告警，最终形成这样一个大屏的展示。这个是现在很多运维同学在日志使用中最经典的场景。

第二个是应用质量管理，也就是 APM。因为所有的业务系统在运行过程当中也会产生一些业务系统的日志，我们通过采集业务系统日志，能够快速的去分析整个应用针对最终用户的服务质量是怎么样的。
比如说企业有一个 OA 系统，大家平时去 OA 系统查询企业的组织架构人员、日常的一些电子流的流转，包括一些业务申请审批，都会产生大量的日志。我们去分析这些日志可以看到服务平均的响应时长是多少，或者大家平均多久会去使用这个平台一次，我们就能够全面的对这个应用质量进行管理和追踪。一旦我们发现大家都在吐槽我的 OA 打开的很慢，我的整个数据查询反馈结果很慢。到底问题是什么？我们通过应用质量管理的模块去查询到对应的故障点然后对这个应用质量进行优化，为最终的用户去提供更优质的体验。不仅在互联网企业会用到应用质量管理，我们在日常的很多传统企业也会有这样一个需求。

第三个叫做统一日志管理平台，这个其实是把场景 1 和场景 2 做了一个更深层次的延伸。大家最开始可能只是针对机房设备做一个监控，后来希望能够针对更上层的业务系统、应用系统进行监控。那现在我们希望能够把企业里面只要能产生日志地方的日志都收集起来。包括开发团队在开发过程中产生的日志，包括业务运行过程中产生的日志，包括机房运维的日志，等等。把这些日志统一的收集在一起，形成统一的日志仓库，这跟我们传统理解的数据仓库类似。
数据仓库是把所有的业务数据、结构化的数据存在一起，来做后续的数据分析。统一的日志管理平台是把所有企业产生的日志收集在一起，然后你来做实时或离线的数据分析，然后把分析出来的结果通过接口输出的方式或是通过消息队列的方式去支撑具体的业务应用。相关人员可以对这些日志进行检索与分析，从而更快的定位问题，并且持续挖掘数据价值。现在很多企业在逐步发展，不仅建设企业内部统一的数据管理平台，也在建设内部统一的日志管理平台。

第四个结合了现在国家在大力推动的工业 4.0 或是中国制造 2025，其实是希望能够以物联网的手段更好的支撑制造业的发展。现在很多制造业企业会在自己的生产线上去增设很多物联网的探头或是传感器，收集整个生产线在运转过程中产生的各种收据。比如说车间的温度、湿度，包括机器的转速、压力、流量等等。然后把这些数据以数据流的方式采集回我的数据平台，实时的对数据进行汇聚和分析，例如进行数据的上卷统计或者实时数据的监控，一旦出现温湿度的异常，转速的异常，压力的异常，流量的异常，系统需要及时报警，车间管理人员能够及时解决出现的问题。
除此之外，也需要及时的监控一段时间内我的整个生产线上生产的运行情况，甚至和我的品控、质量管理等等结合在一起，能够去找出生产线上的温湿度指标和实际的生产质量之间的一些因果关系。这是很多企业现在在做的物联网方面的一些尝试。这四个我认为是现在传统行业、新兴行业遇到的一些日志运维方面的场景和问题。
所以我们很明显感觉到统一日志管理对于传统行业来讲是一个非常重要的事情，不仅能够解决传统行业运维上面的问题，甚至能够去提升一些企业业务层面的能力，包括能够支撑未来很多业务方面的决策和发展。过去，日志被分散的储存在各台服务器上，没有集中管理，难以做关联分析，甚至被删除。
举个简单的例子，传统的防火墙 IPS 等等很多安全数据都存在各自的日志系统里，现在去做安全日志关联分析的企业还很少，像这样的数据很多时候是被大大的浪费掉了。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样感觉很繁琐和效率低下。当务之急我们需要使用集中化的日志管理，将所有服务器上的日志收集汇总。在大数据时代，日志数量巨大，种类多样化，企业数据就如同一座亟待开发的金矿，但是随着日志的统一集中，日志的统计和检索的难度也会加大，传统上一般我们使用 grep、awk 和wc 等 Linux 命令来实现日志的检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。
针对日志管理，现在有非常多的技术选择，最传统简单的就是使用 grep/sed/awk 等脚本工具，无需额外工具支持，而且很多运维工程师都有独立写脚本的能力，但效率低下，容易出错。后来也可以把数据采集到 MySQL 里，进行统一数据汇聚和一些简单的计算，虽然使用方便，但是由于 MySQL 本身性能问题，对于数据量的支撑不会很大，所以能力有限。有些企业会采用 NoSQL 数据库来支持大数据量的存储，但它不支持交叉查询与全文检索，去查具体的某一条日志信息的时候，使用负担就会变得很大。
后来出现了很多大数据方面的技术，比如说 Hadoop/Spark/Storm，他们都能很方便的以离线的方式、实时的方式、或者数据流的方式把数据采集进来，但是使用比较繁杂，对于我们的运维团队、IT 部门来说要求会比较高，而且不支持全文检索。所以现在使用 Hadoop/Spark 来做日志管理的公司也不多。现在绝大多数做日志管理的都会使用 ELK，你可以很方便的在网上下载安装来使用，但是 ELK 产品化及体验层面优化做得远远不足，在一些小批量的数据想试用功能的时候，是没有问题的。但如果想把整个机房或是整个企业所有的日志采用 ELK 来做一个统一日志仓库或者企业日志中心的话，他的稳定性和易用性都会受到很大挑战。特别是如果你的数据量达到百TB 级数据的时候，使用 ELK 就会遇到很多的问题。
那么我们到底如何去选择日志管理系统来支撑我们内部的运维或者支撑我们日志分析呢？我认为可能需要通过八个角度去思考日志管理平台建设的要点，也就是说数据的采集、清洗、存储、搜索、监控告警、分析、报表、开放这八个环节。

数据采集看起来是一个很简单的概念。但是细分下来，还可以再分为四个功能点：数据的收集、解析、转换、发送。

数据采集需要日志管理平台支持各种各样的数据源，这是作为一个优秀的数据采集平台必须具备的功能。包括关系型数据库比如说 MySQL、Oracle，甚至可能像 SQL server 等。以及非关系型数据库、消息队列、 ES 这样的搜索平台，还包括 Hadoop 的服务，将这些数据源的数据准确无误的采集进来是一个数据管理平台在数据采集这块必须支持的功能。另外最好还有针对硬件指标的采集，比如说服务器的 CPU, 服务器的内存使用率，存储的使用率，还包括网络设备的网络流量。这些指标可能不会以日志的形式呈现出来，但是你需要有一个相关的采集工具，能够部署在服务器上，或是部署在网络设备上去采集这些底层硬件的监控指标。这也是数据采集平台在采集这块功能需要去体现的一些能力。
很多的日志其实都是以文本的形式来做数据记录的，如果想做深层次的日志分析、统计、计算的时候，就需要对日志的内容进行提取和切片。例如说安全设备的一条日志需要拆分成具体的时间、日志来源设备、安全事件名，具体描述等若干个字段。日志管理平台需要考虑的第一个功能就是支持非常丰富的预定义的解析规则，不管以什么日志格式进来，都可以很方便的把这些数据解析成相关的字段。
第二个针对个性化的日志格式，能够支持自定义日志解析规则，原因是日志一定是每一个应用开发商在做系统开发的过程当中自己定义的，包含日志相关的格式、内容、规则。所以这个就会造成百花齐放，各个公司日志都不一样的情况发生。那么不同系统的不同日志我们都只用同一套的解析规则去解析的话，一定会出现水土不服的情况。所以如果用户能够非常方便的自定义的对这些日志的解析规则，比如说关于一条样本的日志，能够以划词的方式把切分成若干个字段，系统自动生成相关的解析的规则，这样的话对运维日常的使用来说，就会非常方便易用。
收集、解析之后还有数据转换，为什么还会有转换的工作呢？是因为针对日志中的某些字段，我们希望它的可读性更好一些。比如内网的某个用户访问了某一个业务系统，日志系统一定会记录访问的源 IP 地址，但是当我后续想要对这条日志进行分析的时候，我其实并不关心这个 IP 地址是多少，我关心的其实是这个 IP 地址对应的账号或者是具体的哪个人，所以我们这个时候就需要一个转换的过程，把 IP 地址转换为对应的实体。而通过这样一些转换规则运维人员可以对于后续数据的分析和对数据的统计做到更精准，而且使用过程更易用。
所以说收集、解析、转化都是一个非常重要的工作，这些环节缺一不可。最后处理完的数据，我们需要发送到一个存储里面去进行持久化的存储或者进行后续的分析。那么收集、解析、转化、发送就是数据采集这个功能点里面细分的四个小的需要思考的方面。

数据采集完成之后，可能还需要对数据进行一些深层次加工处理。对于一些简单的数据可以不处理直接拿来做分析或是搜索。那针对一些复杂的业务场景，例如有大量的数据采集进来后，需要每五分钟或是每十分钟去对数据进行一个简单的计算统计，或者针对一些实时性要求比较高的业务应用，需要数据实时的采集进来之后，跟已有的业务模型或安全模型进行匹配，去实现业务服务或者安全态势监控，在这些场景下，单纯通过数据采集平台是无法满足需求的。这时候需要的是一个强大的数据处理的平台，最好可能是类似于 Hadoop、Spark 这样的大数据计算引擎，能够针对不同种类的数据源进行实时的或者离线的计算，并且支持任务的定时执行、循环执行等周期性调度，最终能够把计算分析的结果，导出到对象存储、日志分析，或者导出到业务数据库去直接支撑后续的实际生产业务。
数据采集处理过后就可以进入数据分析的阶段，在这个环节里面，我们需要对收集到的日志进行全方位的快速分析并对结果进行展示，那么首先需要对日志进行统一存储，这个存储至少需要支持 TB 级，甚至 PB 级的数据量，并且能够支持对这些数据进行快速搜索，形成相关的图表以及支撑相关的监控、告警或者分析预测，日志管理平台同时也需要提供相关的 API 接口，能够去对接第三方的监控平台、监控工具或者直接去支撑类似精准营销，用户画像这样的业务系统，以上都是数据分析在这个过程中需要支撑的功能。我日常跟很多用户在沟通的过程当中，我也会发现他们或多或少都会遇到一些日志分析业务的痛点，我总结了四点如下：

自动字段分析
在日志采集阶段已经完成了日志解析，把一条标准的文本型日志解析成了若干个字段，那么能不能对这些字段做一些自动的统计和分析，运维人员不需要自己再去通过写脚本的方式，编辑任务的方式去做数据的计算。比如说系统能够自动的告诉你网络中平均流量是多少，你的流量的峰值和最低值是多少，如果有一些错误的日志，我们统计出来，你的 TOP10 的错误是哪些错误，他来自于哪一个用户或是哪一台设备，针对这样的一些字段分析能大大的降低用户在使用这个平台过程当中去做的一些计算或是任务配置方面的一些工作或难度。
联合搜索
顾名思义就是通过一个条件去同时搜索多个日志仓库，这个场景就比如说防火墙、IPS、杀毒软件、访问日志可能是存在不同地方，统一采集到日志管理平台上以后一般也是放在不同的日志仓库中，当有一个安全事件发生的时候，安全事件会包含来自哪个 IP 地址的×××，或是来自哪个用户名的×××，那我需要通过这个 IP 地址或是用户名能够检索到所有安全设备的日志，然后把相关内容统一的展现出来，那么这个时候就有一个联合搜索的场景。这个时候需要有这样一个功能，能够搜索所有能看到的在这个日志仓库里的内容。
划词分析
大家在日常使用日志分析功能的时候，并不是所有任务都是固化的，有时候需要根据业务要求灵活变动。比如今天我需要分析一个设备或是某一个用户的日常访问行为，那我会搜索这个用户的用户名，日志管理平台会把符合条件对应的所有内容列出来。但当你仔细去看时，搜索出来的内容会非常多，可能是成百甚至上千条相关的日志，若是传感器类的日志可能会更多。仅仅通过一个搜索条件，往往无法满足你对于日志分析的需求的。这个时候，你可以选择在搜索框里增加一个 and 搜索条件去对日志进行更深层次的结果的筛选。
但能不能有一种更简单的方式？例如既然已经找出了跟这个用户名相关的所有日志，那么是不是能够搜索结果中的某条日志里再划一段词出来，自动的填充到我的搜索框里面，去对数据的搜索结果进行二次过滤，或者我可以在搜索结果里面排除掉划出来的这些词所对应的日志内容，如果这个功能可以实现的话是可以大大提高平台的易用性，去解决日常很多令人崩溃的事情。这是划词分析的一个痛点。
实时搜索
系统中产生的所有日志都会以数据流的方式不停的采集到日志平台上，对日志进行搜索的时候希望新进来的日志也能实时的展现出来。这样当我去对一个业务进行变更，或对故障进行恢复的时候，我能看到最新进来的日志情况，可以很方便地看到业务是否恢复正常。这有点像我们日常使用的 tail -f 数据实时滚动的场景。这也是很多用户在对数据分析的过程当中会遇到的一个痛点。如果有一个产品能够去解决用户的这些痛点，降低平台的使用负担，这能够大大降低大家日常运维的压力，提升整个工作效率。

牛人说
「牛人说」专栏致力于技术人思想的发现，其中包括技术实践、技术干货、技术见解、成长心得，还有一切值得被发现的内容。我们希望集合最优秀的技术人，挖掘独到、犀利、具有时代感的声音。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
