可观测技术概述

【可观测技术概述】
可观测性的简介

什么是可观测性
为什么需要可观测性
涉及的数据
- Metrics
- Logs
- Traces
- Profiles
- Dumps

由于工作的需求，特地去研究下可观测性技术，因此通过本文阐述下自己对可观测技术的理解。本篇只分析什么是可观测性、为什么需要可观测性以及可观测性收集哪些数据。后续将完成如何关联各种数据，如何呈现和展示以及如何分析这些数据。
什么是可观测性随着云计算、微服务和分布式系统的普及， oberservibility逐渐走进了大众的视野。似乎可观测性是个新兴的概念，然而在它却很久之前就出现在了控制理论中。在控制理论中他被定义为：衡量一个系统的内部状态可以从其外部输出的知识中推断出的程度（observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs）。对比于监控，监控主要包括白盒监控和黑盒监控，可观测性则更接近于白盒监控。一般来说“监控告诉我们系统的哪些部分是工作的，可观测性则告诉我们那里为什么不工作了” 。他能提供足够的信息帮助我们定位问题发生的原因，因此可观测性主要关注这几个方面：

收集哪些内容。
如何关联这些内容。
如何更方便的呈现和展示。
如何分析这些数据。

为什么需要可观测性简单的系统相对组件较少，通过监控CPU、内存、网络等加之日志分析尚且可以定位出系统问题发生的原因。但是随着云原生、微服务技术、分布式系统的不断发展，一个完成的系统所需的组件越来越多、而且其依赖关系也从较简单的树形结构更多的向网状结构发展，涉及的团队也成倍的增长，定位一个简单的问题甚至都需要跨团队的合作，光是协调各个团队共同定位问题就已经较为困难了（主要是各种扯皮），更别提整合各种不同目标、不同工具、不同方法所收集的数据进行统一分析的艰巨性，可以预见的场景便是在各种工具中来回切换，在各种规则中不断适应。
涉及的数据如前所述可观测性要求系统能够通过收集外部输出的知识推断系统的内部状态，那么收集哪些知识便是最重要的部分也是最基础的。根据目前主流的认知中，普遍认为可观测性主要包括三个支柱：Metrics、Logs和Traces 。而本文则采用tag-observability的观点，将Profiles和Dumps也加入到其中。
Metrics metrics数据主要包括的两大类数据，一是数字数据，这部分多是直接采集的数据例如cpu利用率，内存利用率；另一个则是提炼成数字的数据，这部分多是一些统计数据，例如api调用的qps、错误返回的次数等数据。这部分数据都是指标数据，多是结构化或者半结构化的数据，并且包含时间戳的记录，其用途通常只有以下两种：

监控和告警：通常作为看板数据和告警数据的来源使用。
趋势分析：对于时序数据跟进一步的使用是，推测指标未来的变化情况，做为预防问题出现和决策的依据。
这些指标数据通常能告诉我们系统发生了什么情况，但对于为什么会发生这种情况通常是无能为力的，他们通常是作为问题定位的入口。在这一部分最流行的开源项目莫过于作为CNCF第二个毕业项目Prometheus 。作为Prometheus的监控数据采集方案， OpenMetrics可能很快会成为未来监控的业界标准。

Logs 对比于Metrics ， Logs数据更多的是和事件触发强相关的，主要展示了事件的执行流程，保留所有应用程序和系统相关事件的记录，可以理解甚至重现导致特定情况的每一步操作。这些记录在分析系统为什么发生错误时非常有价值。而这部分数据多是半结构化或者非结构化的数据，这部分数据通常是很随意、很松散的，因此在过去三十年间，有很多将schema应用于日志的尝试，但普遍都不太成功。ELK普遍被认为是日志收集和分析较为成功的实践， Loki+promtail+garafa的架构也大有赶超的趋势。
Traces 分布式跟踪是一种了解分布式事务期间发生的事情的技术，例如最终用户发起的请求及其对所有下游微服务的影响。它可以帮助我们定位在分布式系统中，到底是哪个模块影响了我们对一个事件的调用。Trace的核心是如何在不同的模块传递trace信息，比如同一个程序的不同模块间如何传递、又比如通过HTTP请求GRPC请求分布在两台机器上的两个程序，如何关联两部分内容，这一部分可以使用 OpenTelemetry API/SDK、OpenTracing 和 OpenCensus 等项目、工具和技术。
Profiles 随着公司不断优化云原生应用程序，了解尽可能细粒度的性能指标变得越来越重要。Profile能够使我们能够深入了解特定系统为何会遇到此类问题。熟悉Go语言的一定对其强大PProf很了解，他便是对Profiles最好的实践，其收集的数据包括：

CPU Profilers
Heap Profilers
ALLOCS Profilers
Mutex profilers
IO profilers
BLOCKS profilers
GOROUTINE profilers

Traces让我们了解分布式系统的的哪个部分导致延迟问题，而Profiles则使我们可以更深入地钻取并了解为什么存在这些延迟问题。此外，它还可以帮助您了解哪些代码部分使用了最多的服务器资源。Parka是在可视化做的较好的开源软件（Go语言）。
Dumps 程序Core文件也是我们对系统问题定位的主要方式。在基于 Linux 的系统中，可以通过全局设置 (/proc/sys/kernel/core_pattern) 将核心转储文件设置为写入系统中的任何位置。从内核 2.6+ 开始，有一种处理核心转储的新方法（core dump handlers），不将文件的收集委托给操作系统，而是将崩溃进程的输出推送到负责写入文件的应用程序标准输入。例如，在基于 Ubuntu 的发行版中，这可以在 systemd 或 abort 的支持下完成。基于 RedHat 的发行版中使用 ABRT 。