一篇文章讲透线上应用监控

“线上服务停了，要重启一下”？久经职场作研发的程序员，视线会逐渐转移到线上应用的运行状态。设想一下，若是你在半夜两点正在酣眠好梦时，微信群里忽然炸开锅：“服务停了，先重启。。。”，对于有起床气的你而言，好梦终结，是否能忍？

今天主要分三大块：应用状态监控、基于应用日志的监控、升华部分（老司机，带你飞），稍微聊一下应用监控相关的知识。

声明：

1. 今天的内容至关的烧脑，请提早喝足六个核桃！
2. 但我相信坚持阅读到最后，你确定不枉此行！复制代码

一. 应用服务状态监控

生产上应用服务的运行通常要求 7 x 24，稳定运行率达到 99.99%。其中除了保证应用自己的健壮性外，固然还须要依赖一些守护程序作监控。否则一旦服务出现假死了怎么办？

首先咱们能想到的，即是经过寥寥几行 linux 命令，组成一个小而精悍的 shell 文件，偶尔再配上 crontab 定时任务，来完成应用服务的进程守护。不扯别的，打开经常使用的monitor.sh 脚本一探究竟（以 tomcat 为例）。

麻雀虽小五脏俱全，让咱们解剖一下麻雀。

如何判断应用处于假死？

经过配置健康检查 url，专门用于心跳检测，当每次访问时正常返回 200 状态码，就认为应用还能够正常提供服务。若是返回的不是 200 状态码，则判断应用的进程 ID 是否存在，存在则说明处于假死状态。

如何实现假死应用重启？

经过

ps -ef|grep "tomcat" |grep -w 'tomcat' | grep -v "grep" |awk '{print $2}'复制代码

获取对应的进程 ID，若是进程 ID 存在，则进行kill，而后调用启动命令进行完成服务重启。

上面的方式是在shell 脚本中，实现每 60 秒检查一次应用服务状态。另外我也常常会用 Linux 系统提供的 crontab，配置定时来调用监控脚本，完成应用监控，仍是以上面的 monitor.sh 脚本为例，稍做改动注释掉循环语句。

完成了脚本的编写，接下来就是搭配 crontab 调度任务（第一次据说 crontab 这个词的，请自行寻找谷歌、百度，恶补一下知识）

*/1 * * * * /app/script/monitor.sh > /dev/null 2>&1 复制代码

若是你准备采用上述方案试用时，有两个注意事项：

注意一：请注意修改对应的目录，包括 tomcat 目录、脚本目录、心跳检测url；

注意二：请注意针对shell 脚本赋上可执行权限。

小脚本解决大问题，因此别拿豆包不当干粮，概有四两拨千斤之势。

其实依据过往的经历，静下来想想，面对其它非 tomcat 服务监控时，又未尝不是这种方案呢。

到此最基本、最简单也最实用的应用服务状态监控方案就说完了。你 get 到了没？

二. 基于应用日志的监控

接触过金融项目的都知道，日志是解决系统 Bug 的最后一盏阿拉丁神灯。

在微服务发展如火如荼的今天，服务粒度越拆越细、模块分工愈来愈明确，随之而来的就是根据日志排查问题就趋于繁琐。

那么是否是能够把微服务的日志进行归集到一块儿呢？业界已经有不少成型的方案。那接下来就聊聊如何进行日志归集呢？归集的日志如何进行存储呢？存储的日志该如何展现呢？如何实现告警呢？

如何进行日志归集？

业界常见的日志归集方案，莫非就分为两种：一种是直采方式；另外一种是 agent 方式。

所谓的直采方式，就是在应用程序中将日志，直接上传到存储层或者服务端，例如 Log4j 的 appender 。

所谓的 agent 方式，至关于在应用机器上部署一个 agent 服务，专门用于采集日志，而后推送到存储层或者服务端，应用自己只负责产生日志。

直采方式适用于：在面对没有额外的资源，能够独立部署采集日志的 agent 时，例如负载均衡设备，那就不得不考虑直采方式。

agent 方式适用于：只要应用将日志以文件的形式输出到磁盘上，agent 就能够将日志采集到，而且对应用自己松耦合。与直采方式相比：可扩展性、可维护性，agent采集方式更胜一筹。

业界常见的日志归集工具备哪些呢？

一大堆轮子呼之欲出。

Elastic旗下的 Logstash、Elastic 旗下的 Filebeat、Apache 麾下的Flume、Linux 系统提供的 Syslog/Rsyslog/Syslog-ng、Facebook 名下的 Scribe 等等等。

估计坚持阅读到此的你会一脸的懵逼（笑哭），不过不要紧，就当今天扩展一下知识面吧。

今天我主要提提我用过的两款：Elastic 旗下的 Filebeat、Apache 麾下的 Flume。

Filebeat 是用 Go 语言开发，是一个二进制文件，部署无依赖，占用资源极少，轻量 3M 多，开箱即用，亲测使用特别方便。并且业界名声也不小，是 ELK 架构升级后的产物，请问你是否据说过 ELK 呢（笑哭）？

Flume 是用 Java 语言开发，我用 Flume 主要是集成到项目框架中提供日志归集的能力，主要针对 Flume 去除了一些冗余，扩展了部分功能，进行了二次扩展开发（后续有时间专门写一篇 Flume 二次开发的那些事儿，请期待）。

归集的日志如何进行存储呢？

又一堆轮子呼之欲出。

ElasticSearch、Mongodb、HDFS、时序数据库 influxdb、opentsdb、rrd等等。

因为工做场景的须要，经过关键词进行定位查询，而 elasticsearch 作查询是最合适不过的了。由于每一个轮子，有每一个轮子的使用场景，在此就不作深刻展开。

有哪些日志分析可视化工具？

对，你确定猜到了，又一堆轮子呼之欲出。

基于 Node.js 开发的展现工具，提供日志展现、汇总、搜索，分析仪表盘等功能的kibana。

基于 go 语言开发的专一于根据CPU 和 IO 利用率之类的特定指标提供时间序列图表的 Grafana。

如何实现告警呢？

万里长征，只差一步。日志归集完成了，那若是想看看有没有某个关键字，例如 error、exception 等等，出现关键字就发个告警通知，实现起来岂不是 so easy。

洋洋洒洒聊了这么多关于日志归集的，我常常用的是 ELK，后续找个时间详细写一篇关于日志归集的文章吧。

三. 升华一下，老司机带你装 B，带你飞

到目前为止，你已经了解了如何实现应用服务状态的监控，而且知道了如何基于日志作监控的思路。那你曾经有没有纠结过：一笔请求的调用关系呢？一笔请求大概穿越了多少个系统？一笔请求大概耗时都花费那个节点？

先给你们抛个概念“APM应用性能监控”（不懂的先自行填补一下知识空白），若是有时间的话，请你多重点关注如下三种 APM 组件。

第一种： Zipkin，是由 Twitter 公司开源的分布式的跟踪系统，主要包括：数据的收集、存储、查找和展示。

第二种：Pinpoint：由韩国人开源的分布式跟踪组件，是一款对 Java 编写的大规模分布式系统的 APM 工具。

第三种：Skywalking：国产的优秀 APM 组件，是一个对 Java 分布式应用的业务运行状况进行追踪、告警和分析的系统。

轮子千万款，总有一款适合你。

四. 写在最后

互联网寒冬下，大环境很差的状况下，你只能自强！自强！！自强！！！

不知不觉码了这么多字，不知道你 get 到了多少。若是感受对你有点帮助，请不用赞扬，请多多推荐给身边的朋友就很欣慰。