Monitoring vs ObservabilityMonitoring 指的是监控，重点强调系统是不是正在工作。

微信公众号：进击的大数据 关注大数据方面技术。问题或建议，请公众号留言。

Monitoring vs Observability

Monitoring 指的是监控，重点强调系统是不是正在工作。 Observability 更强调可观测，例如某一个组件或者servie挂了，能不能追踪到根源。

本文的起因也是因为看到了一个不错的视频，这里主要是照顾下没法fq的同志，文章会对视频里的内容有小部分的不同，有些是自己的理解。

能fq的同志可以看下原版的视频。地址：www.youtube.com/watch?v=ACL…

主要分为四个部分

HealthCheck
Metrics
Logging
Tracing

HealchCheck

健康监控主要的目的在于：

是否工作
可不可以完成任务
负载如何

完成healthcheck的方式有很多种，可以是广播模式，例如一个负责监控的service定期向所有的agent发请求，得到所有agent的health情况，再做进一步汇总，也可以是Register模式，例如利用Zookeeper或者etcd来检测健康状况。

这两种我都做过，区别在于：

广播模式的情况下，每个需要上报的agent可以做到轻量，而监控方需要自己调配监控的频率，数据的存储（例如需要监控的机器， service，以及agent的返回结果）等等。
Register模式下，以ZooKeeper为例，每个ZooKeeper的客户端都可以成为监控方，同时只需要知道ZooKeeper地址就可以，这一点针对于可能的扩容缩容帮助比较大。
总结下来就是如果不需要agent之间的协同工作，只是用于HealthCheck的话，广播模式就足够了。

一个典型的healthcheck响应可以包括

GET http://1.1.1.1:8080/health
200 OK
{
    "service": "registration-service",
    "healthy":true,
    "workload":{"healthy":true},
    "dependencies":[
        {"name":"cassandra","healthy":true},
        {"name":"billing-service","healthy":true}
    ]
}

Metrics

metric的scope可以是从底层到更上层的： System metrics(CPU, memory) -> Application metrics(Error rates) -> Business metrics metric收集： Metrics --> Metrics collector && Metrics query engine <-- Dashboard, Alert 开源的方案可以参照Prometheus & Grafana 这里有两点需要说明一下：

不是每一个metric都要alert，例如网络偶尔的异常
粒度太细，例如针对每个customerId，可以理解很多业务为了尽快上线，把逻辑放到这里来做，不过针对特定业务的告警，应该放到更细化的实时处理里面来做，之后会单独写一篇，并配代码。

Logging

集中
可搜索
串联
结构化例如：

ERROR [SVC=A][trace=a1b2c3] Failed to process order cause:xxxx
ERROR [SVC=F][trace=a1b2c3] Failed to process order cause:xxxx
ERROR [SVC=G][trace=a1b2c3] Failed to process order cause:xxxx
ERROR [SVC=B][trace=a1b2c3] Failed to process order cause:DB timeout

结构化的日志才能有威力，例如某个版本的代码，或者某个数据中心挂了导致的metric下降，总体来说体现不出来，要具体的细化才能反应出来

Trace

尾声

少侵入，在业务发展的初期，尽量在少侵入的条件下，来完成。
傻瓜化，术业有专攻，每个人的知识面不一样，百分之80的人也许只用百分之20的基本功能，这些基本功能让别人一次跑通。
可视化，将来的决策可能依赖于这些这些dashboard，做决策的人可能是老板，也可能是运维，也可能是运营，也可能是开发。