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

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

Tips：

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 到了多少。一起聊技术、谈业务、喷架构，少走弯路，不踩大坑。欢迎关注「一猿小讲」，会持续输出原创精彩分享，敬请期待！