数字时代，无论金融还是互联网，各行各业都维护着自己IT系统，而保障这一套系统平稳、高效运行向来都是一件令人头疼的事。
-
对于运维工程师而言，通常要管理很多虚拟机或物理机，小则数十，多则上千。这么多机器，任何一台出现问题，如果都要一个个排查，定位是哪一台出现问题，出现了什么问题，那么在手忙脚乱中大半天就过去了。而因为没有实时处理修复，客户的业务很可能被中断，将会造成巨大的经济和名声损失。
对于开发人员而言，程序每次出现问题，都要查看机器上的日志定位问题，看是代码逻辑问题，还是调用API失败。因为请求接收是随机的，所以都是依次登录到每一台机器去查看。而如果机器数量上了规模，日志产生又是TB/天，这是何等的工作量啊！
对于运营同学而言，日常会查看最近的流量如何，如双12活动用户点击量和成交量。这些都是市场推广的具体反馈。然而大部分运营都不太懂编程，更别说亲手写一段复杂的程序将众多的日志收集起来进行数据挖掘了。
在这种情况下，运营工作起来，毫无市场信息，两眼一黑，不知道路在何方。上述的现状会导致大家工作低效，常常都疲于解决告警，而无法完成新特性开发，产品竞争力逐渐流失；并且产品推广缺乏有效的反馈机制，工作开展起来也各种掣肘。
为什么会这样？
造成以上现状的的根因，主要有3点：缺乏实时监控系统；日志过于分散；数据分析门槛高。
- 缺乏实时监控系统：在面临成百上千的节点时，运维工程师需要一个端到端的解决方案，将各个节点的运行状态进行汇总，并以图形化的方式实时监控。
- 日志过于分散：日志存在多个服务器或文件中，分析问题时必须登录到不同服务器查看多个日志文件才能定位问题。当服务器数量一上规模，效率就低得足以让人难受了。
- 数据分析门槛高：尽管如今市场上各类大数据教程满天飞，但能编程还能掌握这门高深的数据分析技术的运营人员毕竟是少数。
怎么解决这个问题？
为急剧减少疲于奔命的时间，IT部门需要一套成熟的端到端日志平台解决方案，将运维、研发、运营从繁琐的工作中释放出来。
-
这个日志平台需要将分散在各个服务的日志集中收集起来进行管理
-
运维能够根据采集来的数据，在这个日志平台的可视化界面进行实时监控。一有什么风吹草动，立即就能感知
-
研发能够根据采集来的日志，在这个日志平台进行统一的关键词搜索和定位问题
-
运营能够仅仅通过鼠标点击，无须编程，进行数据分析和图形化展示
而在业内，早已经有了一套十分流行的日志解决方案：ELK（Elasticsearch, Logstash, Kibana），其中：
- Logstash负责采集、转换和过滤日志。它支持几乎任何类型的日志，包括系统日志、错误日志和自定义应用程序日志。
- Elasticsearch是实时全文搜索和分析引擎，提供搜集、分析、存储数据三大功能。
-
Kibana是一个基于Web的图形界面，用于搜索、分析和可视化存储在 Elasticsearch指标中的日志数据。
真实案例
某互联网直播平台为保障极佳的用户观看体验，需要在第一时间处理紧急事故，如直播卡顿，或视频无法播放。对于直播场景而言，随着观看人数的剧增，网络的流量和服务器的负荷都会随之猛增，因此出现问题并不是一件少见的事。一旦因为技术原因导致用户长时间无法观看直播，那么用户的流失将会是致命的。
为解决这类问题，该直播平台将应用程序的日志实时采集并进行分析。一旦出现状况，工程师团队都能立即得到告警，并搜索日志中的错误信息，马上进行问题定位和修复。
具体方案如下：
- 在该解决方案架构中，轻量型采集工具Filebeat被部署在各个应用服务器中，收集应用程序的日志，并输出到Kafka消息队列中进行缓存。
- 接着Logstash读取Kafka中的数据并进行解析，将非结构信息转换成结构化信息写入Elasticsearch集群中。
- 最后再通过Kibana图形化工具，将存在Elasticsearch的数据进行相关监控和搜索分析的工作。
通过这套日志解决方案，日志查看时间从分钟级缩短到了秒级，并且该日志平台向所有开发人员提供了统一的日志查看入口，极大地提高了处理告警事件和开发的效率，运维人力减少到原来一半。
作者：华为开发者社区
来源：知乎