API就像数字业务的血管。
随着数据的流动，能量被传递以激活新的机会。通常情况下，我们专注于专门的组件，即我们软件系统的重要器官。
通过挖掘连接器本身，从数据流中提取洞察力，我们能学到什么？这里有一个关于引导API的可观察性策略的快速概述。
发现信号
由于我们的业务有很多是由API驱动的，我们是否能寻找到正确的信号？
首字母缩写MELT定义了我们的出发点。
- M--指标，随着时间的推移收集和跟踪的数字测量。
- E - 事件，重大状态变化的快照。
- L--日志，系统行为的详细记录。
- T - 追踪，组件之间互动的路线，加上一个相关的背景。
检查管道
我们可以从下面思考中获得什么信号？
- 什么时候流量发生了重大转变？
- 花了多少时间从外部来源接收数据？
- 随着时间的推移，连接错误的趋势是什么？
当涉及到较低级别的组件时，我们通常可以利用自动仪器化的优势。这可以以在标准库中包装组件的形式出现，或者沿着连接路径添加监听器。
案例：
记住领域
今天，我们努力捕捉比以往更多的信号。我们看到虚拟机指标和应用程序日志都被运送到存储和分析工具。
但是，在这两者之间的所有业务性的东西呢？我们如何捕捉业务关键绩效指标（KPI）的测量？我们期待对领域进行测量。
领域事件是将业务领域的命令应用于特定环境的结果。
无论捕获与否，这些事件都在不断发生。我们可以对这些洞察力提出什么样的问题？
- 在提供折扣代码和结账时应用之间的平均时间长度是多少？
- 应用中的产品公告和通讯注册之间的关联是什么？
- 当预约被取消时，什么行为直接导致了这个行动？
随着我们问的问题的发展，我们收集这些信号的方法也必须发展。
当我们把单体分裂成许多微服务时，我们就失去了用调试器来浏览我们的代码的能力：它现在在网络上跳动。 我们的工具仍在适应这种地震式的转变。
贴近底层
日志和监控解决方案是在我们编写贴近金属的代码时开始的。曾经主导局面的开源堆栈是这些工具的组合。
- Graylog - 完整的日志管理系统。
- Nagios - 系统、网络和应用程序监控和警报。
- StatsD--指标收集和转发。
- Carbon - 为Graphite摄取指标，存储在Whisper数据库中。
- Graphite - 指标查询、可视化和警报。
许多可观察性文章倾向于忽略的是，这个堆栈今天仍在大量部署和使用。我们中的一些人还在这里，这很好。
抽象化
随着虚拟机--最终是云基础设施--获得了比在裸机服务器上运行更多的吸引力，我们看到了我们在处理信号收集方面的转变。这就产生了可观察性领域的两个突出的堆栈。
ELK栈
- ElasticSearch - 用于日志存储和查询的全文本搜索引擎
- Logstash--日志摄取
- Kibana--日志可视化和警报
TICK栈
- Telegraf - 衡量标准的摄取
- InfluxDB - 一个用于指标存储和查询的时间序列数据库
- Chronograf - 度量的可视化
- Kapacitor - 指标处理和警报
平行运行这些堆栈--或者它们的一些组合，是很常见的。许多组织仍然在这里，这是有道理的。在大多数情况下，它们是非常强大和成熟的解决方案。
容器化
现在已经出现了向云原生基础设施的戏剧性转变。对于在自我管理的数据中心运行的系统来说，容器开始作为应用部署的原子单元被取代。
在此基础上，Kubernetes已经成长为主流的容器协调器（注：在Kubernetes世界中，一个原子单元被称为Pod，由一个或多个相关容器组成）。
在这个新的世界里，我们用什么工具来捕捉信号？
- Prometheus - 指标收集、查询和警报。
- Grafana - 度量指标的可视化和警报。
- EFK栈
- ElasticSearch
- Fluentd
- Kibana
- Jaeger或Zipkin - 跟踪查询和可视化