从运维的价值来看,我们了解到运维是一个复杂、系统的工程。对运维工程师来说,日常需要处理非常多的工作,如何帮助运维工程师做好日常的运维工作,至关重要。但是现在运维工程师在日常运维里遇到很多问题,最主要的原因是现在的 IT 环境越来越复杂。因为信息化建设不是一蹴而就的,公司会在不同的阶段建设不同的业务系统、不同的应用支撑、采购不同的硬件设备。但是由于采购周期的互相递进、堆叠,其实会造成内部有众多不同型号的网络设备、海量不同型号的服务器、各种各样的虚拟化方案、不同的操作系统、多样化的应用软件和数据库。
其实现在很多数据库是由应用软件的开发商来决定的,有些开发商更熟悉 MySQL,他可能用 MySQL 作为应用支撑的数据库,有一些开发商原来一直都在用 Oracle,他可能就会用 Oracle 来做应用支撑。各种不同的业务软件、不同的业务系统都会有不同的业务架构和底层的不同平台,每个平台又会带来不同的监控系统、自己内部相关的一些工具,这会导致一个企业整体的 IT 部门环境变得很复杂,从而带来很多问题:
比如说企业有一个 OA 系统,大家平时去 OA 系统查询企业的组织架构人员、日常的一些电子流的流转,包括一些业务申请审批,都会产生大量的日志。我们去分析这些日志可以看到服务平均的响应时长是多少,或者大家平均多久会去使用这个平台一次,我们就能够全面的对这个应用质量进行管理和追踪。一旦我们发现大家都在吐槽我的 OA 打开的很慢,我的整个数据查询反馈结果很慢。到底问题是什么?我们通过应用质量管理的模块去查询到对应的故障点然后对这个应用质量进行优化,为最终的用户去提供更优质的体验。不仅在互联网企业会用到应用质量管理,我们在日常的很多传统企业也会有这样一个需求。
举个简单的例子,传统的防火墙 IPS 等等很多安全数据都存在各自的日志系统里,现在去做安全日志关联分析的企业还很少,像这样的数据很多时候是被大大的浪费掉了。如果你管理数十上百台服务器,你还在使用依次登录每台机器的传统方法查阅日志。这样感觉很繁琐和效率低下。当务之急我们需要使用集中化的日志管理,将所有服务器上的日志收集汇总。在大数据时代,日志数量巨大,种类多样化,企业数据就如同一座亟待开发的金矿,但是随着日志的统一集中,日志的统计和检索的难度也会加大,传统上一般我们使用 grep、awk 和wc 等 Linux 命令来实现日志的检索和统计,但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。
日志管理的技术选择
针对日志管理,现在有非常多的技术选择,最传统简单的就是使用 grep/sed/awk 等脚本工具,无需额外工具支持,而且很多运维工程师都有独立写脚本的能力,但效率低下,容易出错。后来也可以把数据采集到 MySQL 里,进行统一数据汇聚和一些简单的计算,虽然使用方便,但是由于 MySQL 本身性能问题,对于数据量的支撑不会很大,所以能力有限。有些企业会采用 NoSQL 数据库来支持大数据量的存储,但它不支持交叉查询与全文检索,去查具体的某一条日志信息的时候,使用负担就会变得很大。
收集、解析之后还有数据转换,为什么还会有转换的工作呢?是因为针对日志中的某些字段,我们希望它的可读性更好一些。比如内网的某个用户访问了某一个业务系统,日志系统一定会记录访问的源 IP 地址,但是当我后续想要对这条日志进行分析的时候,我其实并不关心这个 IP 地址是多少,我关心的其实是这个 IP 地址对应的账号或者是具体的哪个人,所以我们这个时候就需要一个转换的过程,把 IP 地址转换为对应的实体。而通过这样一些转换规则运维人员可以对于后续数据的分析和对数据的统计做到更精准,而且使用过程更易用。
顾名思义就是通过一个条件去同时搜索多个日志仓库,这个场景就比如说防火墙、IPS、杀毒软件、访问日志可能是存在不同地方,统一采集到日志管理平台上以后一般也是放在不同的日志仓库中,当有一个安全事件发生的时候,安全事件会包含来自哪个 IP 地址的攻击,或是来自哪个用户名的攻击,那我需要通过这个 IP 地址或是用户名能够检索到所有安全设备的日志,然后把相关内容统一的展现出来,那么这个时候就有一个联合搜索的场景。这个时候需要有这样一个功能,能够搜索所有能看到的在这个日志仓库里的内容。
划词分析
大家在日常使用日志分析功能的时候,并不是所有任务都是固化的,有时候需要根据业务要求灵活变动。比如今天我需要分析一个设备或是某一个用户的日常访问行为,那我会搜索这个用户的用户名,日志管理平台会把符合条件对应的所有内容列出来。但当你仔细去看时,搜索出来的内容会非常多,可能是成百甚至上千条相关的日志,若是传感器类的日志可能会更多。仅仅通过一个搜索条件,往往无法满足你对于日志分析的需求的。这个时候,你可以选择在搜索框里增加一个 and 搜索条件去对日志进行更深层次的结果的筛选。