一般来说，白盒和黑盒分别从内部和外部监控系统的运行状态，比如机器存活、CPU内存占用、业务日志、JMX等，HTTP检测和端-端到端的功能监控属于黑盒监控的范畴。下面将主要从白盒监控的采集入手，针对以上关于新系统如何添加监控的问题进行解答。图1黑盒和白盒监控监控指标的采集在配置监控的时候，我们首先面临的是如何采集监控数据。一般来说，我们可以将监控指标分为两类：基础监控和业务监控。基本监控包括CPU、内存、磁盘、端口、进程以及其他机器和网络操作系统级别的信息。通常成熟的监控系统（如开源的Prometheus、Zabbix等）都会提供采集基础监控项的能力，这里不再介绍。但需要注意的是，机器层面的基础监控指标一般不能代表服务的真实运行状态。例如，单个实例的故障不会给设计得当的分布式系统带来严重后果。因此，基础监控指标只有结合业务相关的监控指标才有意义。业务监控业务监控指标是由业务系统内部的服务产生的，一般能够真实反映业务运行状况。一个设计良好的系统一般都会提供相关的监控指标供监控系统收集。监控数据的收集方式一般可以分为以下几类：日志：日志可以包含服务运行的方方面面，是监控数据的重要来源。例如错误（5xx）、延迟（响应时间）、流量可以通过Nginx访问日志统计，饱和度可以结合已知的容量上限计算。一般除了监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件JMX：大部分Java开发的服务都可以通过JMX接口输出监控指标.很多监控系统也集成了JMX采集插件。此外，我们还可以使用jmxtrans和jmxcmd工具进行REST采集：提供RESTAPI采集监控数据，如Hadoop、ElasticSearchOpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监测的行业标准。目前流行的开源服务大多都有官方或非官方的exporter可供使用命令行：部分服务提供本地命令输出监控指标主动上报：对于采用PUSH模型的监控系统，服务可以主动上报的方式推送监测系统的监测指标。例如，Java服务可以使用Metrics接口来自定义接收器输出。另外，运维也可以使用自定义的监控插件来完成监控采集和埋点：埋点是侵入式的监控数据采集方式，它的好处是可以更灵活的为我们提供内部业务监控指标。当然，缺点也很明显：需要在代码层面进行操作（往往需要研发支持，成本高）其他方式：上面没有涉及的监控指标采集方式，比如四字Zookeeper的命令，MySQL的showstatus命令，以及上面列举的几种常见的监控指标采集方式，在实际工作中，如果没有现成的监控采集插件，我们需要自己开发采集脚本。四大黄金指标图2四大黄金指标无论业务系统多么复杂，监控指标多么眼花缭乱，它们都是一样的。监控的目的无非是了解服务运行状态，发现服务故障，帮助定位故障原因。为了实现这个目标，GoogleSRE总结的监控的四大黄金指标，对于我们添加监控有着非常重要的指导意义。四项黄金指标中包含的主要监测指标如图2所示。下面分别对四大黄金指标进行说明，并给出一些监控项的采集实例。Errors：Errors是指当前系统出现的错误请求和错误率说明：Errors是添加监控时需要关注的指标。在添加错误相关的监控时，需要注意以下几个方面：基础监控：故障如宕机、磁盘（坏盘或文件系统错误）、进程或端口挂起、网络丢包等业务监控：核心功能处理错误，每个系统都有特定的核心功能，比如HDFS文件块读写，Zookeeper的关键读写和修改操作。HDFS的块，Kafka的消息，这种基础数据的丢失一般会直接影响到业务功能Master的故障，对于中心化分布式系统来说，Master的健康状态是重中之重。比如HDFS的NameNode，Zookeeper的Leader，ElasticSearch的MasterNode。可用节点的数量对于分布式系统也非常重要。例如Zookeeper、ETCD等系统需要满足可用节点数大于不可用节点数才能保证功能。Normal注意：除白盒监控外，主要功能或接口，以及内部边界明显的功能模块和上游依赖模块，还应增加黑盒端到端监控。Latency：服务请求所需时间解释：服务延迟的增加不仅仅体现在用户体验的下降，还可能导致请求的堆积，最终演变成整个业务系统的雪崩。以下是延迟指标主要关注点：基础监控：IO等待、网络延迟业务监控：业务相关指标主要需要关注核心功能的响应时间。例如Zookeeper的延迟指标zk_avg_latency，ElasticSearch的索引，搜索延迟，慢查询注：与错误指标类似，白盒延迟指标通常只代表系统内部的延迟。建议对主要功能或接口添加黑盒监控，以收集端到端的延迟指标。Traffic：当前系统的流量说明：流量指标可以指系统层面的网络和磁盘IO，服务层面的QpS、PV、UV数据。流量和突然增加或减少都可能表明系统可能存在问题。基础监控：磁盘和网卡IO业务监控：核心功能流量，比如通过QpS/PV/UV等，通常可以代表web服务的流量，ElasticSearch的流量可以用来表示创建索引率和搜索率。饱和度：用来衡量当前服务的使用率解释：更通俗的来说，饱和度可以理解为服务的使用率，它可以代表系统的压力。因此，饱和度与流量密切相关，流量增加一般会导致饱和度增加。通常情况下，每个业务系统都应该有自己的饱和度指标。在很多业务系统中，消息队列长度是饱和度的重要指标。此外，CPU、内存、磁盘、网络等系统资源的利用率也可以作为反映饱和度的一种方式。基础监控：CPU、内存、磁盘和网络利用率、内存栈利用率、文件句柄数、TCP连接数等业务监控：基本功能单元使用情况，大部分系统对其基本功能单元的处理能力都有上限，接近或达到上限可能会导致服务错误和延迟增加。比如HDFS中block数量的增加，会导致NameNode堆的内存占用增加。Kafka中Topic和Partition数量的增加以及Zookeeper中节点数量的增加都会给系统带来压力。消息队列的长度。许多系统使用消息队列来存储待处理的数据，因此消息队列的长度在一定程度上可以代表系统的繁忙程度。比如ElasticSearch、HDFS等都有队列长度相关的指标进行采集。小结以上总结了常见的监测指标采集方式以及四大黄金指标所包含的共性内容。在实际工作中，不同的监控系统设计多种多样，没有统一的标准，不同的业务系统通常有特定的监控采集方式和黄金??指标的不同定义。如何采集监控指标和添加告警需要我们。灵活应对不同的系统特性。本期作者：葫芦瓜京东云应用研发部在之前的监控系列文章中，我们介绍了Kafka、Zookeeper、ElasticSearch、Hadoop、电商平台等一系列开源软件和业务系统的监控实践。但是一般情况下，线上业务一般是由很多开源或者自研的中间件加层业务系统组成的。业务系统的复杂度会随着系统的变更和新业务的推出而快速增长。在瞬息万变的商业环境中，新的业务层出不穷。面对新系统，监控工作应该如何开展？【本文为专栏作者“京东云”原创稿件，转载请通过作者微信公众号JD-jcloud获得授权】点此阅读更多本作者好文
