监控是分布式系统的重要组成部分。它可以发挥预警，问题排查和评估决策的作用。这是步行河流和湖泊以及家庭的必经之路。
一，监控系统功能划分
主机CPU的告警称为监控；服务日志的错误称为监控；触发APM条件也称为监控。分布式系统错综复杂，也是统计指标的集合。
如何实现泛化和澄清它们之间的关系需要一点努力，否则就不会被拆除。
我习惯上分为以下两种类型，实际执行时，根据数据象限系统仍然合理：
数据象限：从数据类型划分，它可以大致分为：日志（日志），监控（度量）和调用链（跟踪）。
功能象限：从业务角度划分，可分为：基础监控，中间件监控，业务监控
无论监控系统如何，都涉及以下模块化流程：
数据收集：如何在广度和效率方面合并数据。
数据处理：数据分类，传输和存储。
特别称为提取：大数据计算，中间结果生成存储。
数据显示：高价值，多功能显示。
其中，特征提取仅在数据量达到一定水平时才开始，因为其开发和运营维护成本通常不会由小公司承担。
第二，典型的实施
不同的监控模块侧重于不同的领域，具有不同的职责。我个人倾向于独立设计，但需要做一定程度的整合，主要是集成和优化的方式。
我将从一些典型的解决方案开始，并讨论为什么要分开设计而不是挤在一起。
1，系统监控
系统监控用于收集主机的监控状态（网络，内存，CPU，磁盘，内核等），包括大多数数据库和中间件的敏感指示器。这些指标的典型特征是固定结构和有限索引项，它们最适合使用时间序列数据库进行存储。
在指标收集方面，将优先使用支持多样化的组成部分。例如，telegraf支持所有系统指标收集和大多数中间件和DB指标收集。
注意：这里特别推荐使用jolokia2组件，并且很容易实现JVM监视和其他功能。
收集指标后，强烈建议使用kafka作为缓冲区。除了抗日堆叠功能外，还便于数据共享（例如将nginx日志推送到安全组）。指示符进入消息队列后，将通过logstash过滤副本并将其分类到库ES和其他NoSQL中；另一个副本将按流计算，并计算一些指标（如QPS，平均相应时间，TP值等）。
有几种方法可以计算触发警报的聚合计算。检查和叠加统计数据是常用方法。在特别大量的数据的情况下，需要预处理指示符数据。否则，牛的DB，如Influxdb，无法承受它。
在显示方面，grafana因其极高的价值而受到青睐，并支持通过iframe嵌入其他系统。
缺点也很重要：支持的类型是有限的（同比，环到环和坡度）；报警功能不是很有用。
怎么样？我觉得这个技术堆栈太长了？您实际上可以选择zabbix这样一个现成的解决方案组件，并且它有足够的插件。这对小公司来说是最好的。
但是组件过于集中，你不能轻易将其分解，并发现问题不能被其模块所取代，这是架构中的一个致命缺陷。最后，我突然发现实施成本实际上已经增加了。这也是为什么规模不大的公司没有使用它的原因。
发展自己也是可行的，但这并不简单。它必须处理各种复杂的前端问题，并不是每个人都可以做得很漂亮。
2，日志
说到日志部分，每个人都必须首先想到ELKB。但是，我觉得ELKB的链接不稳定性不完整。建议进行以下修改：
可以看出，系统监控的结构几乎相同，许多组件可以重复使用。不同之处在于数据量很大，而且带宽通常是意外占用的。日志的特征是数量大且不规则（nginx是一个好人），并且SLA要求不是太高。
此时，集合部分将使用一些经过测试的日志收集组件。 Logstash的资源控制不是太聪明。为了避免竞争商业资源，水槽和节拍是更好的选择。
同样，消息队列缓冲区是必要的，否则大量的Agent在业务方面被挂起并不是一个笑话。
关于日志放置。存储不需要许多日志，例如研发同学乐意播放的DEBUG日志，因此必须有日志规范。根据这些规范对Logstash进行过滤，并将其下载到ES。日志量通常很大，按日索引更好。在日志之前更长，可以收集到日志堡垒机（即非常非常大的磁盘），或者直接放在HDFS归档中。
那么如何过滤业务日志的错误，例如有多少XXX异常触发警报。在这种情况下，您可以编写脚本，或者可以使用一段数据来处理它，然后生成监视项并将其抛给度量收集器。哈！回去然后回去。
3，追踪
与常见的监控和日志记录相比，呼叫链APM要复杂得多。除了大量数据生成源之外，还有相应的业务组件来支持呼叫链聚合和显示。它的功能显示简单，但它是监控系统中最复杂的模块。
谷歌的论文
“Dapper，大规模分布式系统跟踪基础设施”
呼叫链的流行度已开启。后续可以说是百家企业，直到近年来OpenTracing等标准的出现。
在数据处理和后续显示方面，其技术要点与监控技术类似，其复杂性主要体现在呼叫链数据的收集上。
当前的实现方法，如Pinpoint，直接使用javaagent技术修改字节码；还有一个类似猫的直接编码。每个都有自己的优点和缺点，但都需要解决以下问题：
收集组件的异构化。开发语言可能有java或golang
组件多样化。从前端掩埋点，需要包括nginx，中间件和db等链接。
技术难点。如异步，进程间上下文传输等。
采样。特别是在大量呼叫的情况下，保证了准确性和效率。
关于跟踪的数据结构，已经很糟糕了，所以我在这里不多说。各种实现也是分开的，并且协议彼此不兼容并且已经完成了大量重复性工作。
为了解决不同分布式跟踪系统的不兼容API的问题，OpenTracing（http://opentracing.io/）规范诞生了。
说白了，它是一组接口定义。主流调用链服务器实现与此规范兼容，例如zipkin和jaeger。换句话说，只要您根据规范提供数据，就可以通过zipkin收集和显示。
OpenTracing具有强大的姿势，它结合了跟踪，日志和指标的概念。让我们继续看一下图片，现在知道它是什么时候（来自网络）还为时不晚：
值得一提的是SpringCloud更全面地支持它（OpenTracing API Contributions），但依赖关系和版本非常混乱。建议在参考后自行开发，并且通常使用可以轻松编写的“spring boot starter”技术。
至于“Spring Cloud 2”，更接近于集成千分尺工件也非常适合于prometheus集成。业务指标监控将节省大量精力。我谈了很多关于它的讨论，只是谈到了收集方面。标准的想法是非常正确的，否则每个公司都要编写大量的组件，这很无聊。至于国内大公司的产品，我们会主动向他们靠拢，我们拭目以待。
在服务器端，让我们以Uber的Jaeger为例来说明服务器所需的一般组件：
Jaeger客户：这就是我们上面谈到的内容。
代理：侦听在UDP端口上接收跨区数据的网络守护程序，该端口将数据批量发送到收集器。
收集器：接收jaeger-agent发送的数据，然后将数据写入后端存储。
数据存储：后端存储设计为可插拔组件，支持将数据写入cassandra，ES
查询：接收查询请求，然后从后端存储系统检索跟踪并通过UI显示它
是的，典型的无状态系统对对等节点没有影响。
4.分析和预警
上面的状态图指的是不止一次的流计算，这不一定是整个Spark Streaming，从kafka接收一块数据，它自己的处理也称为流计算，最新的kafka流的选择也是一个选择。重要的是聚合聚合，重要的是三次。
一般来说，计算一些QPS，RT等，即纯计数；或坡度，即增长率下降；复杂点具有TP值（在XX秒内有一定比例的请求对应），并且可以在此计算调用链服务拓扑图和日志异常统计信息。
幸运的是，流计算的API相对简单，调试起来比较困难。
分析的数据属于处理数据并单独存储。当然，如果数量很小，它可以与原始数据混合。
分析后的数据量是可评估的。例如，一个数据是5秒，并且17280在一天内被固定。警告模块读取分析的数据（原始数据太大）并且还涉及大量计算。
那么用于分析的统计数据是什么？一部分是警告；另一部分是显示器。
1）预警
查看我设计的原型，度量标准的操作具有以下一般内容：
在该间隔期间，监视项目触发阈值XX次。
触发动作是：大于，小于，平均大于，平均小于，大于环比，小于环比，大于同比，小于同比，自定义表达等。
阈值是一个支持多个监视项交互的数字数组
水平一般根据公司文化划分，6层就足够了
聚合配置用于指示它是阈值触发器还是聚合触发器。例如，它在时间跨度的5分钟内发生5次。触发警报后，它将发送电子邮件，拨打电话，发送短信，发送webhook等。
仅供参考，这只是冰山一角。要做各种各样的离开，你必须浪费大量的脑细胞。

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: Edge需要分层安全性

• 分享到：