“线上服务停了，要重启一下”？久经职场做研发的程序员，视线会逐渐转移到线上应用的运行状态。设想一下，如果你在半夜两点正在酣眠美梦时，微信群里突然炸开锅：“服务停了，先重启。。。”，对于有起床气的你而言，美梦终结，是否能忍？
今天主要分三大块：应用状态监控、基于应用日志的监控、升华部分（老司机，带你飞），稍微聊一下应用监控相关的知识。
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}'
上面的方式是在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 到了多少。如果感觉对你有点帮助，请不用赞赏，请多多推荐给身边的朋友就很欣慰。欢迎关注微信公众号“一猿小讲”了解更多精彩分享。
