微服务实践是一个漫长的过程， 教程只是个开始， 让我们填平这条路的坑
前言
在本次专题中讲解的是微服务的监控概要，该专题的内容非常多， 第一是因为监控本身可以说做得好就是一个子系统了， 要做的很好， 可能还需要一些监控工具的二次开发等， 而对于中小型企业， 能利用一些开源、认知度高的监控工具， 也足以满足基本要求。 在本节中， 主要介绍一下监控， 对于如何搭建微服务的监控， 将在下节进行介绍。
为什么需要监控
监控是一个不能被忽略的点， 想象一下， 服务突然宕机， 而如果监控做的不到位， 第一时间就连服务宕机也可能不知道。 如果此时用户正在使用， 那么对于产品的性价比将会是一个巨大的疑问， 对于公司， 损失的可能不仅仅是那么几个用户了。尽管我们可以做负载均衡来提高容灾性，但是如果监控不到位， 我们怎么能知道其中的一个服务发生了问题， 对于其中的一个服务发生问题后， 我们依据哪些东西来确定问题的原因， 还是说仅仅是重新启动服务呢？
所以， 搭建一套监控系统是非常有必要的， 而对于监控， 我认为主要从以下几个方面考虑
- 指标
- 告警
- 日志
指标
指标（metrics)： 衡量目标特征方法， 一些特定的指标能够反映出系统的稳定情况， 服务的健康状况， 比如磁盘剩余容量，磁盘剩余量/磁盘总容量 达到90%时， 我们可能就需要采取扩容策略了。 通过各个系统/服务指标的采集， 再通过一定的手段分析展示，
除了监控一些指标超标外， 我们还可以通过分析这些指标来优化性能，比如采集垃圾收集器的频率， 如果发现YGC过高的话，则可以通过增大Eden区域来优化。
告警
告警即当某种条件达成时， 向特定目标发送报警通知，通过告警， 我们可以第一时间去处理问题， 而不是通过用户偶然的发现某功能/服务不可用了。 当然告警的条件有很多， 比如服务上线或下线时进行告警， 因为下线可能是正常下线， 也可能是异常下线； 指标超标告警， 某些指标可能直接关系着系统/服务的健康情况， 一旦指标超标， 可能会存在着服务不可用的风险。通常告警的方式有短信、邮件， 当然现在主流的一些应用也支持通过接口推送到应用中。
告警是发生了问题或问题即将发生能够及时通知， 而优化是让问题尽可能少的发生， 所以我们的目标应重点放在优化上， 而不要过度依赖于告警后再采取行动， 但是告警也是监控必不可少。
日志
对于任何系统或服务， 日志是不可或缺的组成部分之一， 日志中记录了程序(服务）运行中输出的信息，而程序的错误日志也会记录在日志中， 而对于一个庞大的系统， 日志的大小就不在一个数量级， 在很多时候， 日志是通过文件进行存储的， 直接查看庞大的日志是几乎不切实际的， 即使将日志文件以天或时进行分割， 查阅如此庞大的日志是几乎无价值的， 所以需要有效的分析日志工具来帮我们从日志中找出其价值，在下节中， 我会介绍ELK以及我的ELK的实践。
