监控工具

国产监控之光-夜莺监控（Nightingale）夜莺是什么？夜莺是一个服务端组件，相似 Grafana，能够对接不同的TSDB时序数据库作为数据源，反对的TSDB时序数据库如Prometheus、VictoriaMetrics、Thanos等等，只有数据进到这些库里了，夜莺就能够对数据源的数据进行剖析、告警、可视化，以及后续的事件处理、告警自愈。当然，夜莺也有端口接管监控数据，能够跟开源社区常见的各种监控采集器买通，比方Telegraf、Categraf、Grafana-agent、Datadog-agent、Prometheus生态的各类Exporter等等。这些agent采集了数据推给夜莺，夜莺适配了这些agent的数据传输协定，所以能够接管这些agent上报的监控数据，转存到后端对接的数据源，之后就能够对这些数据做告警剖析、可视化。夜莺部署架构依据生产网络环境，夜莺能够实现「核心汇聚式部署计划」和「边缘上层式混淆部署计划」。对于网络结构简略或小规模网络场景下，采纳「核心汇聚式部署计划」施行比较简单，能够n9e外围组件采纳单机或集群形式搭建，集群模式下前端需架设Nginx作为软负载或F5进行硬件设施负载，同时依赖MySQL和Redis中间件存储根底的元数据、用户信息等，不存在大数据量问题，因而，不必太思考性能瓶颈。Categraf是夜莺团队开发保护的监控采集侧外围组件，相似Telegraf、Grafana-Agent、Datadog-Agent，心愿对所有常见监控对象提供监控数据采集能力，采纳All-in-one的设计，岂但反对指标采集，也心愿反对日志和调用链路的数据采集。Categraf采集器采集了数据推送给夜莺，而后转存到后端数据源，如TSDB、ElasticSearch等。❝留神：Categraf不属于夜莺监控零碎组件，夜莺定位是服务端组件，不偏重监控数据采集侧。❞ 核心汇聚式部署计划所有机房网络域下监控数据采集器都间接推数据给n9e，这个架构最为简略，保护老本最低。当然，前提是「要求机房网络域构造简略、规模不大场景，即不太关注跨网络域拜访平安问题和大规模跨网络域传输数据网络带宽限度等」。如果非上述场景，则要应用上面的「边缘下沉式混淆部署计划：」 边缘下沉式混淆部署计划这个图尝试解释 3 种不同的情景，比方 A 机房和核心网络链路很好，Categraf 能够间接汇报数据给核心n9e模块，另一个机房网络链路不好，就须要把时序库下沉部署，时序库下沉了，对应的告警引擎和转发网关也都要追随下沉，这样数据不会跨机房传输，比较稳定。然而心跳还是须要往核心心跳，要不然在对象列表里看不到机器的 CPU、内存使用率。还有的时候，可能是接入的一个已有的Prometheus，数据采集没有走Categraf，那此时只须要把Prometheus作为数据源接入夜莺即可，能够在夜莺里看图、配告警规定，然而就是在对象列表里看不到，也不能应用告警自愈的性能，问题也不大，外围性能都不受影响。「边缘下沉式混淆部署计划」中波及到两个外围组件：「n9e-pushgw组件」和「n9e-alert组件」。「n9e-pushgw组件」提供相似于remote_write和remote_read性能，categraf采集器将数据通过remote_write推送给n9e-pushgw组件，而后转存到tsdb时序数据，n9e服务端查问检索数据时通过remote_read讲求转发到对应机房下的n9e-pushgw组件。n9e-alert组件提供基于tsdb时序库中的指标数据告警性能。一键部署「笔者曾经在私有云上搭建了一套长期环境，能够线登录体验下：」http://124.222.45.207:17000/login账号：root/root.2020上面介绍下应用docker-compose疾速一键部署。1、代码在这里： https://github.com/ccfos/nightingale 。如果有 docker 和 docker-compose 环境，咱们就能够一键装置了：git clone https://github.com/ccfos/nightingale.gitcd nightingale/dockerdocker-compose up -d2、装置实现之后，查看组件部署运行状况：[root@VM-4-14-centos docker]# docker-compose ps   Name                 Command               State                         Ports                       --------------------------------------------------------------------------------------------------------categraf     /entrypoint.sh                   Up                                                        ibex         sh -c /wait && /app/ibex s ...   Up      0.0.0.0:10090->10090/tcp, 0.0.0.0:20090->20090/tcpmysql        docker-entrypoint.sh mysqld      Up      0.0.0.0:3406->3306/tcp, 33060/tcp                 n9e          sh -c /wait && /app/n9e          Up      0.0.0.0:17000->17000/tcp                          prometheus   /bin/prometheus --config.f ...   Up      0.0.0.0:9090->9090/tcp                            redis        docker-entrypoint.sh redis ...   Up      0.0.0.0:6379->6379/tcp ❝留神，docker中不能有同名组件，比方我在装置过程中呈现：ERROR: for prometheus Cannot create container for service prometheus: Conflict. The container name "/prometheus" is already in use by container xxx. You have to remove (or rename) that container to be able to reuse that name。❞3、浏览器拜访n9e组件裸露的17000端口，即可看到页面，默认账号密码如下：username = "root"password = "root.2020" 4、拜访prometheus组件裸露的9090端口，能够关上Prometheus WebUI： 从Targets界面显示Prometheus接入2个指标采集点，从端口能够辨认一个抓取n9e组件监控指标，另一个就是抓取prometheus组件本身指标。根本应用1、关上【基础设施】/【机器列表】菜单，该界面提供Categraf采集点机器治理，在【未归组对象】下就能够看到方才部署的一个Categraf采集点： ❝Categraf 是一个监控采集 Agent，相似 Telegraf、Grafana-Agent、Datadog-Agent，心愿对所有常见监控对象提供监控数据采集能力，采纳 All-in-one 的设计，岂但反对指标采集，也心愿反对日志和调用链路的数据采集。❞Categraf通过Heartbeat心跳服务将节点的状态、内存、CPU、工夫偏移、核数、OS等信息上报给n9e组件，进而Web上不便查看。不便机器列表治理，能够进行分组，如下图咱们对机器依照机房地区划分，并创立chengdu业务组： ❝这里我关上【作为标签应用】开关，该业务组下机器采集数据推送TSDB库时会主动打上busigroup=[英文标识]标签，不便基于该维度进行数据聚合统计。❞【团队】这栏用于权限管制，比方管制哪个团队成员能够对该业务组下机器具备读写权限，或者只读权限等。【人员治理】/【团队治理】页面能够创立、治理团队。选中机器，点击【批量操作】下【批改业务组】，将机器移入到新创建的业务组里： 还能够选中机器，抉择【批量操作】/【绑定标签】，手工为机器打上指定标签，则关联机器指标存储到TSDB时序数据库时会带上这些标签： 2、配置数据源关上【系统配置】/【数据源】菜单，进入数据源治理界面，抉择增加Prometheus数据源： ...

为什么须要API监控？在当今数字化时代，企业应用程序及网站越来越依赖于内部 API 和第三方应用程序提供商。例如一家电商公司，他们的网站可能同时会接入多个内部API，包含领取、物流、广告等服务。如果在用户购买商品时，凑巧呈现了领取API故障，就会导致用户无奈实现付款动作，从而影响公司的整体营收。API的可靠性间接关系到公司的业务运行。当应用程序中的API呈现问题时，会影响到整个网站或应用程序的性能，甚至会导致网站或应用程序间接解体。因而，API监控变得至关重要。 监控宝API监控监控宝提供的API监控可能利用寰球近百个监测点，实时监控API的运行状况，包含可用性、正确性、响应工夫等性能数据。通过实时告警和历史统计分析，帮您疾速发现并解决问题，节约企业的运维老本，缩小业务损失。监控宝的API监控可能： 实时监控get、post、put、delete、head、options六种API申请形式，笼罩绝大部分的接口调用格局。反对JSON、XML、Text、Response Header、状态码验证及Postman，JMeter脚本导入。通过断言性能监测正确性，反对监控多步申请，从而实现对整个业务流程的监控。API监控包含可用性、正确性、响应工夫、可用率、故障率、正确率、均匀可用率、均匀正确率、均匀响应工夫、谬误总时长、谬误总次数、故障总时长、故障总次数13个监控指标。判断和计算规定如下： 创立监控工作配置入口：API监控>工作治理 单击创立我的项目创立API监控工作，须要配置监控工作的根本信息、事务设置、监控设置和告警设置。 设置根本信息在创立API监控工作页面设置监控工作的根本信息，包含定义工作名称、抉择我的项目是否退出分类。如下图所示。 工作名称 输出工作名称，以便于查找和辨别监控对象。您须要为监控工作设置一个有代表性的名称，例如您须要监控在淘宝中提交订单的业务流程，则可设置监控工作名称为“淘宝-提交订单”。 我的项目是否退出分类 为方便管理本人创立的监控工作，您可为以后监控工作抉择一个我的项目分类。您还能够单击创立分类，新建一个我的项目分类作为以后监控工作的分类。 设置初始变量您可利用变量来存储值，动静地提取HTTP响应数据，并在多个申请之间动静地传递数据和状态。比方，增加申请1时，可通过设置变量$a来动静提取Response Header中的Date值。而后在增加申请2时，应用变量a作为断言的目标值。应用变量时须要提前初始化变量，即为变量赋默认值。 在创立API监控工作的事务设置页面，单击设置初始化变量，增加并治理初始变量，如下图所示。 设置自定义变量 在自定义变量页面区域，单击增加变量增加一个变量，设置变量名称和变量值。自定义变量仅利用于本监控工作。留神：变量名称必须以$符号结尾，并且是纯字母组成。除自定义变量外，您能够查看零碎变量及自定义零碎变量，零碎变量可用于所有监控工作的API申请。 设置零碎变量 在零碎变量页面区域，单击自定义页签，单击增加变量增加零碎变量，定义变量名称和变量形容信息。留神：在自定义零碎变量时，变量名称必须以$public_结尾。在零碎变量页面区域，单击公共函数页签，查看可用的零碎变量，具体阐明见下表。 设置事务在创立API监控工作的事务设置中增加并治理须要监控的API申请。 您可能间接导入脚本来增加API申请，也可手动增加和设置API申请。增加API申请后，可间接复制已增加的申请来创立新的申请。 通过导入脚本增加API申请 为疾速创立多条API申请，单击导入脚本，在关上的对话框中间接输出脚本内容并导入。导入胜利后，监控宝依据导入的脚本主动创立对应的API申请。在关上的导入脚本对话框，单击查看实例理解脚本款式，脚本反对Postman和JMeter格局。您能够间接应用Postman中生成的脚本。 手动增加API申请 单击增加申请，关上申请编辑页面，如下图所示。 依据理论须要设置各项内容，具体阐明见下表。 复制API申请 为防止反复设置，增加API申请后，您可单击【复制按钮】复制以后API申请作为一条新的API申请，依据须要批改相应内容即可。 挪动API申请 当增加多个API申请，如果须要调换申请的先后顺序，鼠标拖动指标申请挪动到指标地位。 增加申请距离 单击增加申请距离，输出发送API申请的工夫距离，例如设置“10s”,则发送一次API申请后，期待10s发送第二次API申请。 测试API监控申请 增加API申请后，为保障失常监控，需查看是否能申请胜利。单击验证测试来测试申请并查看测试后果，如下图所示。 申请胜利即可用，所有申请都胜利时，监控工作（即整个业务流程）的状态为失常且可用，单击开展>返回后果，查看申请的返回后果。增加断言时能力测试申请的正确性，所有申请都正确时监控工作的正确性为“是”，单击开展>变量与断言，查看断言详情。 设置监控在创立API监控工作的监控设置中，设置监测点和监控频率，如下图所示。 监测点抉择相应的监测点对指标API进行监测。您能够抉择多个监测点也能够创立/抉择一个监测点分组。所抉择的监测点或监测点分组的成员均用来监测指标网API。 抉择监测点：依据需要抉择多个监测点。抉择监测点分组：抉择或创立监测点分组。若分组内监测点成员有所变动，工作创立后仍会同步。留神：抉择监测点分组后，监测点分组中的所有监测点都产生故障时才会向您发送告警音讯。监控频率：监控宝执行监控的工夫距离，例如抉择2分钟，则监控宝每隔2分钟就执行一次监控。设置告警在创立API监控工作的告警设置中，设置惯例告警重试次数，间断间断告警揭示，告警线，企业IM告诉及告警形式，如下图所示。 告警设置项阐明如下表所示： 小结在过来的封闭系统中，如果呈现故障，只会对该零碎内的应用程序产生影响，而对于当初大部分企业来说，一个故障就会影响到整个生态系统。监控宝能够利用寰球近百个监测点，实时监控API的运行状况，保障企业运维效率及用户体验。点击此处，马上申请监控宝收费试用名额

随着软件和云技术的遍及，越来越多的企业开始采纳微服务架构、容器化、多云部署和继续部署模式，这减少了因零碎失败而给运维/ SRE / DevOps团队带来的压力，从而减少了开发团队和他们之间的摩擦，因为开发团队总是想尽快部署新性能并启动新的A/B测试。在云时代，CI/CD 模式倒退迅速，它能帮忙研发团队疾速改良、修复零碎缺点，把新性能推向生产，极大进步开发效率。CI/CD 能实现这一点，因为它领有功能强大的工具，可能生成信息，也能实时或简直实时地从运行的应用程序中收集信息，这些信息反映了应用程序的健康状况、性能和可靠性。用户能够察看和剖析异样信号，捕获行为不端的应用程序，决定是否须要修补或禁用它们。CI/CD 模式能够帮忙开发者疾速检测异样，避免重大故障和安全漏洞的呈现，从而改善用户应用体验。 过来用于记录谬误和异样的信号传输办法倒退到当初，曾经演变成了最新的 OpenTelemetry 规范。本文将摸索 Jina 3.12 中引入的最新跟踪和监控性能，并应用 Sentry 跟踪索引或搜寻时零碎外部的工作状况。 监控和跟踪能够解决什么问题？嘿，让咱们一起意识新敌人小博吧！他创立了一个能够在线购物的网站叫J多多，咱们一起来看看这个网站是如何倒退的吧，同时也能够理解一下他的监控和跟踪性能哦！ J 多多 1.0：日志作为stdout一开始，为了进步 J 多多网站可靠性，小博采纳了一个简略的零碎，用来监控生成、捕捉和剖析信号： 应用程序日志存储在本地机器上，定期旋转防止磁盘空间耗尽。如果须要缩短日志的保留期限，能够将它们导出。如果客户或测试人员发现搜索引擎出现异常（例如常常超时等），能够创立投诉工单来取得解决方案。接着通过检查程序日志，将客户遇到的谬误与工夫进行匹配。小博意识到，这个过程的繁琐是因为该零碎未能改善客户的理论体验所造成的，因而他迫切尽快优化该零碎。 J 多多 2.0 ：结构化和长久化的日志随着程序日志的倒退迅速，小博很快就优化了日志格局，引入了结构化日志（JSON），改善了故障的报错音讯以及提供了更加便捷的工具。有些工具甚至能够将代码度量集成到正在运行的应用程序中，以实时测量应用程序栈各层（网络、磁盘、CPU）的代码性能。此外，小博能够捕捉、可视化并长时间存储这些信号。大数据处理框架能够让小博从不同的应用领域（语言、架构、设施平台）和部署环境中聚合、剖析数据。 J 多多 3.0：应用日志跟踪故障J 多多逐步走向成熟， 它开始反对云/混合部署环境，解决寰球数百万用户的不同设施类型。这意味着 J 多多须要更粗疏的跟踪监控办法： 生成有价值的信号。找出问题最可能的根本原因。以用户小美和小智为例： 小美在 J 多多 Android 利用上购买侈靡耳环，她应用的是美国的数据连贯。小智在 Ubuntu PC 端，从智利钻研基地购买彩色夹克。对于他俩来说，用户体验都不太称心。为了服务寰球各地不同设施、不同语言的本地化搜寻，零碎须要采纳更精准的形式生成信号，以找出导致问题的根本原因。此外，越来越多的用户和设施类型意味着也会带来更多的谬误形式和问题起因。总之，J 多多须要进一步优化。 什么是 OpenTelemetryOpenTelemetry[1] 是 CNCF[2] 的孵化我的项目,它反对分布式跟踪和度量。小博要求在 Jina Flow 中实现 Telemetry。在开始之前，咱们须要理解几个概念： Telemetry (遥测) 是一种近程数据采集技术，用于监控零碎性能和故障，它能够主动收集数据并将其发送至接管设施进行监控。简而言之，原始察看值或日志音讯在申请期间能够用作度量。Instrumentation（仪表仪器）是应用仪器记录和收集原始察看值，并将其转换为信号进行传输来实现监控的过程。Tracing（跟踪）则是指依据应用程序的日志记录，来监督它的运行状况。如何在 Jina 中应用 OpenTelemetry？Jina >=3.12 曾经集成了 OpenTelemetry，本文将介绍如何应用它构建文本到图像搜寻零碎。 DocArray 负责解决数据并与存储后端交互。Jina Executor 实现微服务。Jina Flow 用于加载、编码和存储编排微服务。OpenTelemetry Collector Contrib 收集微服务跟踪信息，能够实时监督微服务。Sentry 可视化微服务报告操作，帮忙用户及时发现和解决问题。请留神，本文仅波及后端，如果您想要构建低代码后端加前端神经搜寻解决方案，请查看 Jina AI Cloud 的 APPs。 ...

近年来，越来越多的企业实现了外围业务零碎互联网化，无论是企业外部员工还是企业内部用户或是供应链上下游合作伙伴，均通过互联网和Web利用与企业建设起了严密的分割。基于此，网络性能对企业业务的影响也变得越来越重要，监控宝则可通过进步网站的用户体验来保障企业支出、爱护企业品牌以及开释企业生产力。 点击中转监控宝官网 场景与用户价值网站品质监控互联网的应用已成为日常生活重要的局部，无论线上购物、订餐、挪动领取、互联网出行、政务查问、办理、医疗挂号、银行业务等等，这些业务都依赖着外网的稳固与可用，外网监控可能帮忙企业监控本人的业务零碎的可用性，无论在网络产生抖动、还是企业服务器呈现问题时都能及时向企业进行告警，监控宝为企业的业务提供保障。 企业外部的日常运行也离不开网络，无论办公零碎、人力零碎、财务零碎、客户管理系统、物流管理系统、交通管理零碎、服务器治理等等，这些零碎以及工作内容都依赖着内网的稳固与可用，内网呈现故障导致公司外部业务无奈解决，重大的还会影响对外的业务稳固。内网监控可能保障业务撑持零碎的失常稳固，当内网环境呈现不联通时，及时向企业进行告警，从而缩小业务零碎受影响工夫，保障企业的失常运行。 网络链路品质监控不同网络服务商带宽品质参差不齐，相互之间的连通性问题重大，当各地用户通过不同的网络接入商拜访网站或Web服务时，用户体验的差别十分大。因而，互联网企业和网络内容提供商须要对网络链路品质进行继续监测。但受老本和资源的限度，企业短少无效的网络链路品质监控伎俩，无奈对全国用户和海内用户的拜访链路进行7x24继续无效监控，不能被动发现链路故障。 监控宝通过遍布寰球的分布式监测点发动全链路网络品质探测，通过采集不同地区、不同运营商链路的时延、丢包、网络抖动状况，从工夫、地区、运营商等维度综合剖析网络链路品质及可用率，感知电信、联通、挪动等多家网络服务提供商的网络品质，疾速发现和精确定位网络问题，便于及时进行链路调整，保障所有网络用户的体验。 网页性能监控互联网用户通过Web页面获取大量信息——文本、图片、视频、动画……网页交互也越来越丰盛，而这些元素、资源会时刻影响网页的加载速度，一旦网页打不开、交互失败，用户就会放弃这个网站，对业务造成恶劣影响。而针对网站要害页面和要害业务的运行，必须监测其可用性和业务流程完整性，从寰球次要城市或区域发动对网站、业务零碎和次要服务模块的业务要害页面的模仿拜访，继续监测网站响应工夫和可用性。 监控宝通过遍布寰球的分布式监测节点实在模仿理论用户的地理位置，监控不同地区拜访网页元素的加载速度和性能问题，为页面优化提供实在的一手数据。 继续监测网页元素、内容更新、图片/视频/Flash等多媒体资源的加载状况。监测不同区域的用户拜访页面首屏、元素的性能体验。残缺反对HTML5页面性能监测和剖析。定位元素级的问题，包含JS、Image、CSS等资源加载状况。API接口性能监控API是随着互联网和云计算的衰亡而催生的产物。像云供应商亚马逊、互联网巨头Google、社交媒体Twitter，他们的服务都是通过API的形式来提供的。 “API经济”的概念应运而生。API 经济是利用互联网的Web API技术，将企业能力或竞争力作为API服务而进行商业替换的经济模式。 随着越来越多的国内零售商、媒体、政府和金融服务公司开始公开Web API，每天都有大量的API增长。API曾经成为扩大产品、获取客户，帮忙合作伙伴提供高价值服务以及扩张生态系统的要害渠道。 网络环境下 API 接口越来越凋谢， 大量的业务通过 API 去实现。稳固的API能帮忙企业降低成本，进步支出。随着挪动利用的暴发增长，将来API将会应用的越来越多，不论是提供API的服务商还是应用API的公司，都不心愿产生这样的情景： 调用第三方公司提供的应用程序API失败，导致业务中断，交易失败。游览网站通过API获取机票和酒店库存信息并抽取佣金，API调用失败导致失去一个客户或是一次机会。其余数据源信息的API调用失败，影响本人的内容整合。公司外部产品之间API不稳固导致业务下滑。公司提供进来的API稳定性间接影响业务收入。监控宝推出API监控服务，用于无效监控API服务的稳定性和正确性。帮忙用户解决API性能带来的业务问题。 CDN品质监测随着国内互联网环境的一直降级，越来越多的网站应用大量高分辨率的图片、视频、动画等多媒体文件以及API等内部资源。资源越大，对于网页的加载速度影响也越大。Google、Amazon等互联网巨头的专项钻研证实，网站每慢一秒钟，就会失落10%的访客，甚至造成客户的永恒散失。CDN成为互联网企业解决资源加载速度问题的重要抉择。 但用户网络环境简单，客户难以发现内部故障，无奈把握要害业务和页面的全国性拜访状况；服务覆盖全国和海内，对于边远地区和海内业务无法访问的状况，排查定位难；不足CDN减速成果监控，针对CDN故障定位排查时效性差，排查Cache节点故障难。 监控宝通过部署在寰球范畴内海量的分布式监测节点模仿实在用户拜访，对页面内每个元素申请从DNS解析到后果出现的全过程进行深度追踪剖析，来确定应用CDN减速的元素申请的性能体现，诊断剖析是Cache节点本身问题，还是同步策略问题，亦或是网络传输问题。 进步整体网络链路品质掌控能力，对链路故障及时进行应急解决，保障用户拜访体验。进步CDN节点故障感知能力，及时发现Cache节点异样，精确定位故障信息。进步网络资源调度能力，可能依据网络链路品质，优化用户拜访链路。特点与劣势300+寰球式分布式骨干网监测节点用户体验对线上业务的影响越来越大，而传统的网站监测工具所暴露出的诸多有余可能对用户体验造成致命的影响。 云智慧推出的监控宝领有寰球分布式监测网络，通过遍布全国所有省份、世界次要国家和各大支流运营商的300+监测节点寰球分布式监测节点，监控宝可能被动对挪动、浏览器、微信等终端的链路品质、CDN成果、DNS解析状态、响应工夫和可用率进行具体的评估。 整体性能数据实时展示数据细化到地级市响应工夫及可用率剖析报警与故障信息汇总世界和中国网络展现各运营商数据分析全天候7*24小时继续监控监控宝通过提供整体网络7×24全天候继续的网站可用性监控，实时把握响应工夫散布和可用率等总体运行状况，精确地剖析网站性能指标，及时发现问题、秒级告警，帮忙运维人员疾速定位并解决问题，进步运维效率。 CDN品质感知与评估对业务时效性要求较高的企业大都采纳了性能减速服务，但CDN服务厂商泛滥使得辨别Cache 节点的难度大，市面上的大部分产品在掂量CDN减速服务时须要进行简单的URL和监测点配置，减少了运维工作的复杂度。 监控宝通过弱小的数据库智能地辨认CDN服务厂商，帮忙客户省去简单的配置工作、升高运维的工作难度。监控宝通过云智慧300+寰球式分布式监测节点采集到的海量CDN数据，帮忙企业精确主观地评估CDN服务厂商在区域内的性能差别。监控宝通过智能地辨认CDN服务商的主机并对CDN主机在同一区域的监测点进行拜访，来主观、精确地评估CDN节点的减速状况，帮忙在客户评估CDN减速成果的过程中保障对于服务的选择权。监控宝反对从元素性能与主机性能层面查看与剖析目前的CDN策略，比照不同主机的性能体现以及元素的申请体现，从而享受更好的CDN减速服务。先进的问题剖析机制当用户的网站性能呈现问题时，及时地对问题进行剖析、定位对解决问题尤为重要。监控宝采纳了先进的问题剖析机制，帮忙用户剖析和定位网站的性能问题，防止因网站性能问题而导致的用户散失。 快照剖析 通过记录所有监测点的故障快照，帮忙客户进行故障定位。元素瀑布图剖析 通过元素瀑布图重现网站在加载过程中所有元素加载的时序、可用性及性能信息。同步主动网络诊断 当网站监控中呈现申请超时、无奈连贯服务器、申请被回绝或者无返回数据等网络问题时，零碎主动进行MTR诊断。MTR诊断从每个监测点登程帮忙定位问题区域。当网页呈现资源申请故障、元素加载异样时，零碎会主动对元素进行网络诊断。测试用于查看是否由网络层故障导致的元素加载异样，实用场景包含CDN Cache节点问题确认等。诊断的形式包含：ping（用来确定从客户端到服务器主机是否存在网络问题）、dns（用来测试指标域名是否能失常解析）以及traceroute（用来检测网络路由是否存在问题）三种。智能化告警治理当客户网站产生拜访故障时，及时的告警是十分必要的。监控宝提供的智能化告警治理，通过对告警的实时响应、解决与剖析，帮忙运维人员疾速定位故障，缩短故障中断的工夫，升高客户的损失。 先进的告警策略 间断告警揭示，确保告警接受者不会错过告警信息。重试几次告警，确保告警的准确率。自定义告警线，满足客户自主断定故障规定的要求。多重告警通道 邮件、手机短信、语音电话、App推送、URL回调等五种告警形式，不便用户按需抉择。多种告警频率的间断揭示，确保告警音讯即时送达。人性化的告警页面设计 按工作拆分零碎推送的告警信息并用精简的文字向客户报告告警内容，缩短客户的拜访门路的同时晋升客户的拜访效率。告警音讯汇总统计 汇总展现监控我的项目的故障音讯、零碎音讯以及揭示音讯，并能够查看音讯对应的历史快照信息。多维度数据报表不同于少数同类产品只提供很简略的短期数据报表，监控宝反对不同时间段内的多性能指标统计报表以及比照报表，并反对报告的导出性能，不便客户进行深入分析。 监测点、运营商、国内外地区、省份&运营商等多维度的报告统计 让用户关怀的数据通过用户须要的维度展现，使数据更合乎用户的需要，帮忙用户更有针对性的调整与欠缺产品。比照报表 通过比照不同工作间的性能，让客户在理解本身产品性能的同时，把握竞争对手的性能，以便客户在产品竞争中占有先机。总结监控宝领有开箱即用的性能，通过寰球分布式骨干网调度联动，实时把握各地用户的网站拜访体验，及时发现性能问题，解决企业因迟缓的外部应用程序导致企业工作效率升高，甚至业务停滞等问题。 从金融、教育到社交、电商等，每个业务场景对监控的需要均存在较大的差别，云智慧监控宝从外围场景切入，同企业外部监控零碎高效联合，从而解放企业局部运维工作，为企业运维人员提供对立视角，帮忙其疾速定位并解决问题。 点击中转监控宝官网

在现有的监控告警体系中 Prometheus + AlertManger + Grafana 始终是支流，但对于中小团队或集体来说，这种体系显的较为简单。而 HertzBeat 能让中小团队或集体很疾速的搭建监控告警零碎，并通过简略的配置实现利用、数据库、操作系统的监控与告警等。 HertzBeatHertzBeat赫兹跳动 是一个领有弱小自定义监控能力，无需Agent的实时监控零碎。网站监测，PING连通性，端口可用性，数据库，操作系统，中间件，API监控，阈值告警，告警告诉（邮件微信钉钉飞书）。 RainbondRainbond 是一个云原生利用治理平台，应用简略，遵循 以利用为核心 的设计理念，对立封装容器、Kubernetes和底层基础设施相干技术，让使用者专一于业务自身, 防止在业务以外技术上破费大量学习和治理精力。 疾速部署 HertzBeatHertzBeat 已公布到 Rainbond 开源利用商店，你能够在开源利用商店中搜寻 HertzBeat 一键装置。 装置后，能够通过 Rainbond 默认提供的域名拜访 HertzBeat，默认用户明码 admin/hertzbeat。 HertzBeat 疾速应用仪表盘 应用服务监控应用服务监控反对多种形式，如： 应用服务监控阐明PING连通性检测域名或 IP 的连通性HTTP API调用HTTP API接口，查看接口是否可用，对其响应工夫等指标进行监测，可自定义申请头JVM 虚拟机监控 JVM虚拟机的通用性能指标SpringBoot2.0监控 SpringBoot2.0 actuator 裸露的通用性能指标全站监控监控网站的全副页面端口可用性监控服务裸露的端口SSL 证书监控网站 SSL 证书过期工夫以及响应工夫 数据库监控反对监控多种类型数据库，如：MySQL、Redis、PostgreSQL、SqlServer、ElasticSearch、Oracle、MariaDB、OpenGauss、达梦数据库。 操作系统监控反对对支流的 Linux 和 Windows 零碎进行监控，例如：Centos、Ubuntu、Windows等。 告警配置反对自定义告警阀值，告警告诉反对 邮箱、WebHook、企业微信机器人、钉钉机器人、飞书机器人。 最初HertzBeat 还反对中间件的监控、对容器的监控以及自定义 Prometheus 监控等，小伙伴们能够自行摸索。 通过 HertzBeat 让咱们用简略的配置即可监控、告警咱们的业务，让咱们在监控告警这块节俭更多工夫、老本。

编者按：随着分布式系统和业务需要的飞速发展，监控告警在咱们保障系统稳定性和事变疾速复原的全周期中都是至关重要的。9 月 3 号，阿里云弹性计算管控 SRE 李成武老师(花名佐井)，受「TakinTalks 稳定性社区」邀请，在线分享日常预警治理工作的教训和心得，帮忙大家实现精准的监控和告警，把问题扼杀在摇篮里，缩小故障带来的业务损失。 以下是本次分享内容的文字整顿。 如果事件有变坏的可能，不论这种可能性有多小，它总会产生。—— 墨菲定律零碎的稳定性离不开无效的预警机制，依据墨菲定律：可能出错的中央，肯定会出错，咱们没法精确预测零碎会在什么时候在什么中央出错，然而却能够晓得当零碎出问题的时候，接口响应变慢、零碎服务不可用、业务流量上涨或客户操作无奈实现甚至有客户投诉。 为了反抗墨菲定律，咱们必须防患未然地在各种零碎节点上配置预警信息，免得出问题的时候太过被动；同时为了谋求问题发现率（更多的预警项、更不合理的阈值、更无关紧要的内容），咱们有陷入了预警笼罩的悖论，最终导致了当初广泛的预警天堂景象。咱们看下图，这是一个十分典型的正反馈加强回路，导致预警问题越来越多。 图：预警的正反馈加强回路 更多的预警项会使问题变好吗？依据熵增定律，这一过程必然导致不可逆的破坏性，最终可能分不清哪些预警须要解决，甚至导致对预警的漠视。有没有方法解决这个问题？有，做负熵！从预警的各个环节循序渐进做减法，明天咱们就聊聊预警环节的 6 因素。 在这 6 个预警因素中，有些是被公认且不言而喻的，另外一些常被疏忽导致预警天堂，本文综合了日常预警定义、告诉、治理的教训和智慧，是预警治理的现实实际规范，关注保持良好的预警解决，继续解决零碎隐患，促成零碎稳固衰弱倒退。 01 精确：预警自身精确并正确告诉在大量被疏忽的预警中，有很大一部分能够称为不精确，因为即便没有解决也不会产生什么理论问题，精确的第一个定义是预警达到了正告级别。无需解决的预警会导致“狼来了”效应，对预警越来越漠视，最终漏掉真正有须要解决的预警；已经发现过这样的团队，几个小时报一次的预警没人看，只有到短时间高密度的预警告诉能力引起留神，这样的团队对预警的免疫能力越来越强，也越来越危险。另外有效的预警告诉还会导致不必须到资源节约，比方：短信、电话费用等。所以，从当初开始，口头起来把有效预警干掉吧。 精确第二个定义是预警精确地告诉到正确的接管人。不要认为预警告诉的人越多就越可能被解决，理论不相干人收到告警更多是张望，实际上基本没人口头，因为这些无关的人没有能源也没有能力这么做。已经遇到过一个 case，与预警无关的同学告诉须要预警应急的团队，看看你们零碎是不是出力问题，尽管这种状况下无关告诉起了作用，但对应该预警应急的团队是如许难堪和可怕的事件啊。另外接管预警应急的同学也须要对预警告诉做响应动作，一方面告知关注的同学，预警曾经有人响应解决了，另一方面也未前面对预警的度量做数据筹备。 总结下精确因素是把真正的预警信息告诉到正确的接管人，这外面真正的预警和正确的接管人短少哪个都不应该发送；同时，这也是一次握手过程，接管人收到告诉后要接手并筹备解决。 02 适时：适时告诉、适时应急如果按预警的响应率，难道不是及时告诉和响应更好，有些状况的确如此；然而别忘了咱们来做负熵的，大部分状况咱们做到适时就够了，防止适度缓和和恐慌。 首先，适时须要咱们在不同时间段采纳不同强度的告诉渠道，比方夜间须要应急的预警，短信或 IM 很可能无奈及时触达，须要用更强烈的告诉形式，比方电话；然而在失常的工作工夫，大家都是在线状态就没有这个必要。十分重大的预警，还是须要持续放弃紧急的强告诉以达到时效性，然而咱们还是倡导非必须尽量不必。 其次，在应急上，对于没有及时响应的预警，能够升级成更强烈的告诉渠道；同时也能够在解决人员上做降级，比方降级到主管、SRE 等，以达到适时应急的目标。并不是每个预警都须要紧急解决的，比方：服务宕机，如果是线上许多机器中的一台，对业务流量不会造成影响，能够稍后再解决。 最初，适时要保障雷同的预警不要短时间反复发送，防止吞没在预警炸弹中。个别状况是合并报警并做相干统计，而后依据预警分类做对应的克制操作，或者让人工抉择暂停一段时间的这类预警发送。当第一条预警被认领后，示意相干的应急解决曾经启动，再推送相干预警更多是烦扰，解决的成果能够通过监控察看，所以是不须要持续再报同样的预警的。 03 详尽：给出影响范畴、上下文和诊断信息收到告警后第一要事是确定问题而后采取对应的隔离或止血措施，如果告警内容太过简略，会让这个过程变成一个猜谜游戏，须要从新去现场，通过多种手段验证和揣测，能力确定问题所在，这也是解决预警耗时最多的中央，而且这里很多是靠教训吃饭，新同学简直很难插手。所以，在预警信息中给出影响范畴和上下文和诊断信息，会上问题定位事倍功半。 首先，预警的影响范畴是判断应急轻重缓急的重要指标。影响范畴包含资源、业务、用户等维度： 资源：单机、集群、相干依赖；用户：个别、局部还是全副客户；业务：外围业务、旁路业务、非核心业。如果影响范畴是个别情况，能够疾速做隔离，比方把单个机器做隔离，摘除掉非核心链路或者单个客户做流控降级。相同，如果面积级别的，须要更采纳更紧急响应机制，比方拉起更多的人解决：主管、SRE 以及团队其它同学，甚至升级成故障级别。 其次，上下文信息会让定位事倍功半。上下文信息有助于判断谬误的诊断，省去从新还原现场的麻烦。上下文信息包含： ◾ trace：给出预警问题的一条 trace 链路，相当于把现场还原；◾ 日志：具体的谬误日志 link 能定位到具体代码和过后的堆栈信息；◾ 关联：关联的预警或变更，不便疾速判断预警是不是由其它问题关联导致或因变更引起。有了上下文信息，进一步排查的门路根本也确定了；否则须要去各种平台收集信息、甚至须要从新复原现成，而这些操作不仅耗时，还可能因为信息不全或工夫流程导致无奈失去须要的信息。 最初，预警中的诊断信息，甚至能间接给出定界起因，免去排查工夫。问题的定位很多时候依赖解决人对业务的了解，对工具的应用，对平台的数据和已经的教训。预警诊断就是把这些脑海中的流程教训通过规定+数据变成后果间接输入，诊断须要肯定的零碎能力建设能力实现，比方 ECS 外部采纳上面的架构来撑持诊断： 1.须要把不同渠道的预警信息对立接入，预警信息如果间接发送进来，就失落了诊断环节，预警信息首先接入诊断层，能力实现后续诊断动作。 2.须要有肯定的信息收集能力，包含：各种 meta 信息（利用、数据库、api、人员、值班 …）、变更信息、运维工具、日志和其它预警信息等。 3.须要有肯定的信息整合能力，把预警和收集的信息做整合，联合诊断框架给出诊断后果。 04 复原：隔离、止血、自愈复原是预警解决的第一要事，先要打消对系统、业务、客户的影响，而后才是排查问题。因素 3（详尽：给出影响范畴、上下文和诊断信息）业务为了定位到哪里出了问题，而后采取对应的复原手动。 个别状况下，复原须要执行一些动作，如果预警能更进一步，给出复原操作，那将极大晋升响应速度。 个别状况下复原动作有以下执行门路： ◾ 故障自愈，依据预警判断影响并关联预制动作实现故障自愈。首先须要预警反对绑定 call back 动作，能够依据预警内容抉择正确自愈操作；其次动作执行管制范畴，防止主动执行动作带来二次故障。比方：咱们能够检测到单机问题，把机器摘除掉。自愈须要判断好执行的范畴和影响面，对有信念的动作能力主动执行。◾ 止血动作的 action，能够通过 link 或者 chatops 形式嵌入到预警内容中，点击相干 action 疾速打消影响。比方：咱们会在预警告诉中，给出一些流控、重启、开关等动作，一键即可实现操作。◾ 最佳实际、操作手册或者相干联系人，在没有止血 action 的时候，能够给出持续操作的指引，依照手册持续操作或分割能解决的人。至此，咱们通过 4 个因素的优化，实现了预警的整个应急过程，接下来 2 个因素讲关注预警的经营，通过高效、无效的经营，更进一步对预警进行治理。 ...

随着分布式系统和业务需要的飞速发展，监控告警在咱们保障系统稳定性和事变疾速复原的全周期中都是至关重要的。 9 月 3 号（本周六） 14:00，受「TakinTalks 稳定性社区」邀请，阿里云弹性计算管控 SRE-佐井老师将在线分享日常预警治理工作的教训和心得，帮忙大家实现精准的监控和告警，把问题扼杀在摇篮里，缩小故障带来的业务损失。 关注直播，参加直播间多轮抽奖，有机会取得 SRE 精美书籍、马克杯、快客杯、三合一数据充电线，等等精美礼品哦～

云原生环境中的监控与传统应用程序的监控相似，均蕴含跟踪指标、日志和事件，而二者的次要区别在于云原生环境中的某些托管对象具备临时性和非持久性。监控能够让运维人员洞察零碎以后运行状况、监测问题并进行及时修复。此外，监控还能跟踪应用程序运行状况和用户行为等。因而，监控是无效运行应用程序的重要组成部分。 本期直播由云智慧运维开发工程师-李晨阳带大家具体解读云原生时代下各热门监控工具的架构设计及利用场景。 直播预报直播主题：云原生时代热门监控利器的解析利用 直播工夫：3月31日（周四）19:00-20:00 讲师简介： 李晨阳，云智慧运维开发工程师 直播亮点： 深度解析监控目标与监控维度，理解4个监控黄金指标；具体解构 Prometheus 架构设计，理解 Prometheus 的指标类型与高可用实际；高效实际 Grafana & Thanos，在线学习利用数据可视化剖析。听众收益： 理解监控的目标、纬度及相干指标；理解Prometheus、Grafana 、Thanos监控工具的架构原理、个性及应用场景；联合场景，理解各监控工具如何解决理论业务中所遇难题。报名形式扫描下方二维码，增加小助手微信，备注「331」获取直播链接 对于 MeetupAIOps Developer Meetup是由云智慧AIOps社区推出的，面向宽广开发者的系列线上直播及线下分享流动，咱们将汇聚AIOps社区专家团的力量给你提供优质的技术内容，无论是技术解读、开源治理、行业解决方案，置信宽广developers总能在这里找到你想要的内容。 AIOps社区由云智慧发动，针对运维业务场景，提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交换社区。该社区致力于流传AIOps技术，旨在与各行业客户、用户、研究者和开发者们独特解决智能运维行业技术难题、推动AIOps技术在企业中落地、建设衰弱共赢的AIOps开发者生态。 往期回顾上期Meetup由云智慧算法总监 —严川分享了 《 AIOps 指标相干算法体系分享》 次要内容回顾： AIOps（智能运维）算法体系总览AIOps异样检测算法场景深度分析解读AIOps预测场景视频回放&ppt材料：增加文中小助手，备注“干货”获取。

云智慧 AIOps 社区是由云智慧发动，针对运维业务场景，提供算法、算力、数据集整体的服务体系及智能运维业务场景的解决方案交换社区。该社区致力于流传 AIOps 技术，旨在与各行业客户、用户、研究者和开发者们独特解决智能运维行业技术难题，推动 AIOps 技术在企业中落地，建设衰弱共赢的AIOps 开发者生态。引言随着数字化时代的到来，各个行业的利用零碎从传统私有化部署逐步转向私有云、行业云、微服务，这种变迁给运维部门和利用部门均带来了较大的挑战。基于以后企业 IT 运维均为多部门负责，且应用多种运维工具，因而，当业务呈现问题时很难疾速定位故障本源。而随着业务上云，云平台运维和利用运维的责任归属不同，业务方（租户）只负责云平台之上运维，若是要对业务体验全链路负责，就会导致有责任没伎俩。同时，容器微服务架构利用后的业务之间的拜访关系更加简单，也会产生利用呈现故障后剖析艰难等问题。基于以上的背景，企业数字化时代利用的衰弱诊断变得至关重要。 问题及挑战如下图，当代码量的增长达到100倍，故障被企业 IT 部门觉察前已由用户申报达到80%时，作为企业会十分被动。用户对服务超时十分敏感，当5秒打不开利用时便会间接抉择放弃。同时，用户对故障解决时效要求也比拟高，75%的用户心愿在5分钟内解决业务故障，而业务零碎须要超过24小时能力解决的故障占比在25%左右。 利用是一个端到端的多技术栈简单整合环境，用户端包含挪动端、浏览器、小程序，网络层包含路由器、防火墙和负载平衡等，后盾撑持利用包含中间件、数据库、主机、MQ等。所以如何去高效精细化的实现整个利用端到端的全链路性能问题洞察和诊断、疾速找到故障的边界、以及特地是VIP用户呈现性能问题如何疾速追踪。这些利用的复杂度是企业运维部门和业务部门都须要思考的问题。 传统的监控工具早已无奈满足以后企业面临的问题。因为一个利用会波及到数据库、第三方的API 调用、应用服务器、中间件、Web、网络层等多个链路，因而，当零碎慢是无奈疾速定位就是是拿个环节、组件以及指标导致。日常企业去判断上述问题时，会须要网络团队、开发团队、数据库团队、基础设施团队等多方帮助排查，且排查效率较低。 解决方案与性能场景介绍基于以上问题与挑战，云智慧提供了全新一代架构的利用性能治理解决方案。以晋升数字化用户体验，帮忙企业实现数字化转型赋能为指标，提供了web用户、移动用户、被动拨测、压力测试前端侧性能监控，同时贯通网络层到后端各个组件的全栈一体化性能监控计划，蕴含Web服务器反对IIS、Nginx等。此外，利用后端反对市面上支流的开发语言以及微服务容器架构，基于Smart Agent的探针技术，部署在容器宿主机上就能够主动发现容器外部利用拓扑关联关系，实现整体的业务关联疾速剖析和根因疾速诊断。 产品技术架构下图为产品整体的技术架构，次要是分三层： 数据采集层：APM产品反对市面上比拟支流的开发语言，如Java、PHP、Python等。APP端反对 android 和 iOS 等各种版本。依赖被动拨测，基于寰球IDC实现Monitor数据监测。数据存储层：采集到的数据对立放到产品的数据存储层进行数据存储。云智慧产品基于列式存储的技术，在各行业我的项目上通过大量数据实际，能够实现秒级查问和展现。数据分析与展现层：该层次要提供了具体产品的相干性能。包含拓扑展现，申请剖析、用户追踪，代码堆栈详情剖析，网页性能剖析，页面响应工夫剖析、可用率剖析等相干性能。整个平台提供告警告诉性能及规范API接口，不便用户其余业务零碎调用数据进行利用。接下来，咱们次要围绕APM和拨测两款产品的利用场景进行整体论述。 监控宝：7*24小时被动IT性能监控云智慧拨测产品监控宝提供7*24小时被动IT性能监控；产品在寰球范畴内大略有 300 家的 IDC 节点，提供 800 家的服务器，IDC数量决定了数据反馈的全面性，能够无效保障业务在寰球的用户体验；国内节点笼罩30多个省份和100多个城市和地区，更能精准的定位问题所在区域。此外，也较为全面的笼罩了多个运营商，包含挪动、联通、电信、教育四大运营商。以上三个维度，能够看出云智慧监控宝产品能够为各行业企业提供业务保驾护航的能力。 监控宝平台反对的协定包含http/https、ping、DNS、ftp、traceroute等，反对协定类型品种丰盛，满足企业多方面应用需要。性能包含网页性能诊断、CDN评估成果、网络品质探测、网站访问速度、接口服务可用率等。同时，整个产品反对多页面脚本录制，不便企业在大型网站上提供多页面监控能力，以及可能疾速发现深层次的页面性能问题。 透视宝：端到端全链路利用性能诊断云智慧APM透视宝产品提供端到端全链路的利用性能诊断。用户体验端包含APP、浏览器、小程序的全栈性能剖析和性能探测。后端反对利用拓扑的发现和代码品质的追踪，真正做到端到端一体化，实时把握前端、透视后端，实现全业务链环节问题监控与剖析。 下图为透视宝产品的技术实现原理， APP 端通过嵌入 SDK 实现用户行为和 APP 解体卡顿数据的抓取；浏览器通过页面嵌入 JS 形式实现页面详情的剖析；主机操作系统通过部署 agent 实现 cpu、内存、网络、io等指标监测；利用后端依据不同开发语言部署不同的探针，在中间件启动脚本里注入参数，重启利用后就能够实现数据的采集，小程序通过mini agent抓取相干数据。 利用场景介绍业务服务继续监测与告警业务服务的继续监测和告警在一些互联网企业当中常常会遇见。比方北京区域网站拜访是衰弱的，但其余区域网站拜访异样时，也会收到的其余区域用户投诉。针对上述问题，因为目前各行业网站页面加载时序元素简单，外加整个页面会有一些动画图片成果的出现，所以须要可能实时探测网站在中国区域到地市级别和区级别的监控的被动拨测产品。监控宝可监测不同运营商链路拜访网站速度、404相干谬误，以及可通过IDC节点被动收集数据，帮忙企业及时剖析并被动探测业务问题。该场景次要利用于互联网企业，电商企业，还有企业官网、在线教育等行业。 内外网及网络专线品质监测与告警企业内外网业务服务于全国。运营商网络不稳固的用户投诉，分公司专线或 VPN 经常出现的各种问题，均会导致业务经营受到较大影响。 外网网络品质监测依靠于云智慧在寰球 IDC 节点提供被动的 ping、MTR、traceroute网络探测，60秒的探测频率能够让问题被及时发现。针对内网专线的监测，云智慧提供魔盒产品。相似机顶盒的小盒子，使用寿命长、无风扇设计、节能环保，间接部署在分公司数据中心机房中即可应用。该场景次要利用于医疗行业、电商、金融、政府军工等团体企业。 网页用户体验剖析与继续优化随着网站内容更加复杂化，大量元素加载耗时变长，首屏响应工夫变得更加重要。如：当用户点击二级页面时会呈现404谬误或响应慢等景象，企业尽管做了 CDN 减速，在此状况下也很难确定减速的品质的好坏。然而在互联网时代下，用户对网页的加载速度提出更高要求，呈现网页响应过慢或无法访问则会导致用户失去急躁而散失，以此便会给企业业务收入以及品牌均会带来损失。基于上述问题，监控宝产品提供了多页面脚本录制性能，能够模仿人点击操作所有页面各个环节的性能诊断，及时发现元素性能问题。此外，基于企业同时应用多家 CDN 厂商导致具体减速品质难以判断的景象，监控宝也提供了 CDN 整体性能评估性能，不便用户做 CDN 厂商性能体验比照。该场景次要利用在网站有丰盛的大型logo/图片/轮播要展现的企业，如汽车类、广告展现类以及大量应用 CDN 服务商的企业。 ...

能够的 WGCLOUD能够监控凝思操作系统的

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/...，下载完整版电子书，理解阿里十年DevOps实践经验。 随着云原生技术的倒退与演进，微服务和容器化技术成为大型分布式 IT 架构的必然选择。新技术在让 IT 零碎变得更麻利、强壮、高性能的同时，也带来了更高的技术架构复杂度，给利用监控带来了前所未有的挑战。 传统监控挑战系统监控爆炸式增长传统监控重点关注利用、主机、网络等零碎层面的监控。随着微服务、云原生等新技术的大量使用，零碎架构越来越简单，利用数量呈爆炸式增长。当一个故障产生时，大量零碎报警会产生报警风暴，使得技术人员无奈疾速定位问题。同时，大量的零碎级监控会产生大量误报，技术人员被迫破费大量的精力去解决这些误报，最终对报警产生麻痹。 监控后果和业务指标之间欠缺分割传统监控短少业务视角的监控，以及业务与 IT 零碎之间的分割。这导致用户、业务人员和技术人员之间无奈造成对立视角。很多故障往往是用户曾经反馈，技术人员却在用系统监控指标证实零碎没有问题。或者业务曾经受损，技术人员仍然无奈确定是哪个零碎的问题，复原工夫被大大拉长。 监控工具之间数据割裂，数据不足剖析以往阿里巴巴采纳多种监控工具，用于监控网络、物理机、利用、客户端等不同的对象，但不同工具之间无奈共享数据，监控数据不足对立的剖析，更加难以跟业务场景相结合，造成大量的故障只能依附技术人员的教训，在多个工具之间一直地切换和逐渐排查，大大增加了故障复原时长。 监控保护老本高，报警准确率低传统监控都须要大量的配置工作，整个过程麻烦费劲，不足自动化、智能化监控的伎俩，这也是造成各系统监控能力参差不齐的重要起因。一些新业务因为有力投入大量精力配置监控，导致业务监控能力缺失。同时，随着业务的倒退，技术人员须要一直地调整报警规定，又经常因不及时的调整造成误报和漏报。 业务驱动的监控理念为了适应 DevOps 研发模式，解决传统监控的问题，阿里巴巴总结了一套以业务驱动的自顶向下的全景监控体系，次要包含：业务监控、利用监控和云资源监控三层： 业务监控是整个监控体系的“顶层”，可能反映用户应用业务的真实情况，能够与业务后果间接挂钩，可能被不同部门、不同角色的人员所了解。利用监控提供利用中服务和零碎层监控能力，可能间接反馈零碎运行状态，帮忙研发人员全面理解利用中服务和中间件的衰弱状态，疾速定位系统问题。云资源监控提供利用依赖的各类云资源(如 RDS、OSS、SLB 等)的根本监控，在故障排查中可能为研发人员提供实例级别的明细监控数据，疾速确定是利用零碎的问题，还是云根底施行的问题。 监控分层当前，各层的监控指标和报警规定会按重要水平分成重大、正告、一般等多个等级，不同档次、不同级别的监控报警会被分派给不同的角色来解决，比方团体的平安生产团队只关注全团体的外围业务指标，事业部的稳定性负责人关注部门级的外围业务监控，每个团队的研发人员则接管本人负责业务和利用报警，而云资源实例的监控个别不发送告警音讯，次要用于故障排查和定位。这样充分发挥了 DevOps 的劣势，传统模式中多数运维人员成为故障排查瓶颈的问题也得以解决。同时，每个人须要解决的报警数量大幅缩小，也解决了在故障产生时因为报警风暴，而将重要的业务监控报警吞没的问题。 对立的监控架构基于全景监控的理念，阿里巴巴摸索出了一套对立监控的架构，该架构不谋求大一统的监控平台模式，而是采纳分层建设，形象出了云资源，利用，业务这 3 种监控零碎，每种监控都专一发现相干畛域的故障发现，再通过对立 CMDB 解决监控元数据互相不对立的问题，通过智能算法平台，报警核心和故障平台集中管理事件，故障以及晋升准确率。 业务监控阿里巴巴“业务监控”采纳专为监控自研的日志采集&计算框架，通过页面配置即可实时提取日志中的监控指标，具备简略易用、自定义能力强、响应速度快、对业务无侵入等特点；提供了残缺的业务监控畛域模型，疏导用户实现监控笼罩。 业务监控的畛域模型包含： 业务域：一个残缺的业务或产品称为“业务域”，如电商的“交易域”、“营销域”、“领取域”等。业务场景：业务域中的外围业务用例叫做“业务场景”，如交易域的“下单确认”、“创立订单”等，业务场景是整个监控模型的外围。业务指标：体现每个业务场景的特有指标，如每分钟的订单数量、交易成功率、错误码等。 在业务指标的抉择上，传统的运维人员喜爱应用穷举式的伎俩配上所有可观测性的指标，各种告警加上，显得有“安全感”。理论当故障来长期，满屏呈现指标异样、一直减少的告警短信，这样的监控看上去功能强大，实际效果却事与愿违。 通过对阿里巴巴历年故障的认真梳理，阿里巴巴团体内的外围业务的常见故障（非业务本身逻辑问题）都能够通过流量、时延、谬误等 3 类指标反馈进去，咱们称之为黄金指标： 流量 ：业务流量跌零 OR 不失常大幅度上涨上涨，中间件流量如音讯提供的服务跌零等，都可能触发重大故障；延时 ：零碎提供的服务 OR 零碎依赖的服务，时延忽然大幅度飙高，根本都是零碎有问题的先兆；谬误 ：服务返回谬误的总数量，零碎提供服务 OR 依赖服务的成功率。业务监控平台提供了“黄金指标”插件，通过单次配置就能够生成一组黄金指标，是目前业务监控应用范畴最广的指标模型。 业务监控报警间接与故障关联，对监控数据的品质有很高的要求，同时须要具备很好的灵活性（既满足不同技术实现的监控需要，又不能对被监控的业务零碎造成性能影响）。阿里巴巴的“业务监控”通过日志作为数据起源，能最大水平地保障业务监控的灵活性，可能适应简直所有的技术栈。日志采集采纳了无压缩增量采集、zero-copy 等技术，升高监控采集对业务零碎的性能影响；采纳拉模式架构、重试机制、数据齐全度模型保障了数据采集的可靠性和完整性；齐全白屏化的配置能力、欠缺的调试性能，最大水平升高了用户的配置难度和配置老本。 利用监控阿里巴巴利用监控采纳标准化和组件化的形式搭建，与阿里巴巴技术栈相结合，提供罕用的零碎和中间件层面的监控组件；运维同学无需批改程序代码，整个监控过程自动化，利用上线、扩容后主动开启利用监控，无需人为操作，大幅升高了监控的保护老本。 当运维零碎执行利用上线、扩容等操作后会将变更信息写入到 CMDB，CMDB 会将变更信息推送到MQ，利用监控平台订阅 MQ 实时获取利用的配置变动生成新的监控工作，监控工作下发到指定的指标服务器（容器）的 Agent 端，Agent 依据工作的配置信息发送对应的采集申请，从业务利用提供的 Exporter 等 EndPoint 中获取监控数据，并上传到监控集群进行计算和存储；同时异样检测模块也会依据利用配置的变动生成报警检测工作，从时序数据库中拉取监控数据进行异样检测，并将异样事件发送给报警核心。 云资源监控阿里巴巴云资源监控间接对接阿里云平台的“云监控” API 获取各类云资源的指标数据和报警事件，再将这些数据与 CMDB 中利用与云资源的关系信息连贯，最终造成利用视角的云资源衰弱状态视图，解决了云基础设施监控与下层利用监控互相隔离的问题。依靠云平台的监控能力和 CMDB 的数据积攒，整个云资源监控也是自动化实现的，无需用户人工配置。 智能检测平台为了解决报警准确率低、配置保护老本高的问题，阿里巴巴建设了智能检测平台，通过 AI 算法准确地发现线上业务和利用的异样，并且在此过程中不须要任何人工配置报警阈值。针对业务和利用监控数据的不同特点，采取不同的异样检测策略： ...

能够的WGCLOUD监控零碎，反对监测河汉麒麟操作系统，还有中标麒麟零碎也能够

摘要：在互联网信息爆炸式疾速倒退的明天，各类简单多样的平台零碎相继涌出。如何抉择最佳的监控产品以更好地保护这些平台和零碎是每个 IT 人员都需面临的难题。本文将从开源监控产品的起源和倒退，具体解析各个时代热门监控产品的劣势和劣势，并联合各个监控产品的应用场景，帮你抉择出最适宜本人的开源监控产品。因篇幅和工夫起因，上面介绍的材料和了解可能和理论状况有所偏差，欢送大家留言或者退出微信群批评指正。 作者：Ethan Chen ，云智慧解决方案架构师，领有丰盛的运维实践及实战经验。致力于将客户需要无效地转化为公司产品场景，让客户更有效率地了解公司产品并为其提供优质的技术撑持。 开源监控软件的前世今生如上面谷歌趋势图所示（因有些单词有二义性，具体数值可疏忽，只看趋势），与其余开源监控产品相比，2004 年的Nagios仍处在较高地位，但因为Nagios没有紧跟容器脚步、且配置简单等毛病导致热度直线式降落。反观Zabbix，从2004年至今，因为其监控的全面性，使得其热度始终处于安稳回升阶段。此外，基于RRD存储开发的Ganglia与Cacti因为产品本身的一些毛病，热度也在逐步降落。下文咱们将具体介绍各个产品的具体情况。 现代（2000-2010）Zabbix（2004）Zabbix于1998年开发，2004年正式Release。较于其余开源监控产品，Zabbix领有弱小的指标数据存储性能、画图性能，并且真正地做到了All in One全面监控，解决了运维人力和工夫老本上的问题。 基于以上性能长处，以及大量欠缺的教程文档，Zabbix在国内迅速流传倒退。现如今，Zabbix曾经进入了5.X时代，前端界面的优化、ES及TimescaleDB等时序数据库的反对，使得Zabbix又步入了一个的新的时代。 劣势丰盛的插件。Zabbix领有丰盛的MiB库资源以及模版等850多个插件；易用性、依赖少。基于PHP与MySQL搭建，可用性比拟强；可进行肯定颗粒度的权限管制；文档欠缺。Zabbix自身定位为企业级分布式监控零碎，故领有欠缺的文档，沉闷的官网社区，且自身也更新得比拟频繁，开发比拟踊跃；国内市场有相干的商业反对。劣势MySQL数据量问题。当MySQL数据量比拟大时，存储性能容易呈现问题；可视化问题。本身可视化灵活性较差，需用Grafana等进行补救；性能使用率低，80%的用户应用的仍为监控、看图、告警等根底性能，大部分高级性能未能被应用。应用场景剖析监控基础设施。主机、网络设备监控等；中小规模监控；对于大型场景的监控来说仍需注意数据问题。Nagios（2002）Nagios是一个次要用于监控零碎运行状态和网络信息的监控零碎。Nagios能监控所指定的本地或近程主机以及服务，同时提供异样告诉等性能。 Nagios领有4000多个插件，且在很早之前就开始领有本人的官网插件社区。这外面包含很多利用级别的监控插件。此外，Nagios的告诉尽管简略但能笼罩所有场景，以及自身领有弱小的监控任务调度的能力。 劣势性能简略易用，次要的性能是被动检测。劣势性能过于繁多，只能通过被动检测告知后果是否匹配，被动检测性能原生性能较弱；配置简单，配置批改主机、报警、阈值等时，在原生Nagios中只能通过批改配置文件来实现，操作较为简单。应用场景小场景简略监控。对于一些网站、端口等可进行简略监控；大型场景须要各种花式Hack，须要借助很多第三方的插件进行效率的晋升和分布式的扩大。Centreon（2005）Centreon是一款开源的软件，次要用于对Nagios的一些性能加强。可通过页面治理Nagios，通过第三方插件实现对网络，操作系统，应用程序的监控。 劣势界面敌对保护不便对立治理性能数据可追溯劣势批改配置须要重启或者重载Nagios主过程MySQL仍然存在数据问题文档资料较少应用场景剖析实用于百台规模的中等监控仍须要解决原生Nagios的一些弊病Check_MKCheck_MK是一款通用的Nagios/Icinga加强工具集。其插件有着相当成熟的检测机制和对硬件服务器的检测伎俩。非常适合对硬件服务器进行“体检”。 劣势界面敌对保护不便对立治理性能数据可追溯劣势减少变更须要重启Nagios主过程。因后端存储应用RRD，导致分布式扩大较为艰难。文档资料较少。应用场景剖析实用于百台到千台以内中等规模监控须要解决Nagios的一些弊病Cacti（2001）Cacti是用PHP语言实现的一个监控软件，它的次要性能是用SNMP服务获取数据，而后用RRD贮存和更新数据，当用户须要查看数据的时候用RRD生成图表出现给用户。 劣势网络设备反对好有权限管制有汉化版晚期在IDC笼罩广劣势SNMP依赖只适宜个性场景材料老旧应用场景剖析简略的IDC托管网络运维Ganglia（2001）Ganglia是UC Berkeley发动的一个开源集群监督我的项目，设计用于测量数以千计的节点。次要是用来监控零碎性能，如：CPU 、内存、硬盘利用率， I/O负载、网络流量状况等。 劣势数据集中，部署分布式适宜大规模部署对集群热点观测性反对较好劣势无告警集群内UDP播送问题多应用场景剖析大数据利用集群较多，关注整体资源使用率近代（2010-2015）监控宝（ 2010）监控宝是云智慧推出的新一代用户体验监控工具，从寰球节点被动模仿实在用户拜访，提供网站性能监控、API监控等服务，继续监测应用程序、网站、网络和数字化服务的可用性和性能，提前诊断，实时告警，帮忙客户晋升网络应用效力。 劣势寰球分布式监测网络。200+ 分布式监测节点笼罩寰球112个城市以及次要运营商网络，网络规模继续扩充中。被动监测。监测节点依照预设规定模仿实在用户发动被动监测，实时掌控网络性能，聚焦用户体验。立体化笼罩。HTTP/HTTPS/TCP/UDP/TR/DNS/PING等多种协定类型，全面问诊网络、业务衰弱。面向业务。通过蕴含多步申请的事物监控实现业务流程的监测，保障业务的稳定性和可用性。继续监控。24/7小时全天候监测网站和网络性能，多渠道服务反对，缩小可能产生的中断。快照+MTR。先进的问题诊断与剖析机制，问题产生之前和问题复原之后的数据尽在把握，疾速定位故障。灵便告警。短信、邮件、微信、语音、API等多种告警形式，确保告警可能被即时送达。业余的剖析报告。提供综合排名、竞品剖析、同比/环比、日/周报等多维度的数据报告，满足专业化定制需要。应用场景剖析网络链路品质监控与评估。通过采集不同地区、不同运营商链路的时延、丢包、网络抖动状况，从工夫、地区、运营商等维度综合剖析网络链路品质及可用率，疾速发现和精确定位网络问题，便于及时进行链路调整，保障全网用户的体验。CDN监控。通过海量的分布式节点模拟实在用户拜访，监控CDN性能，评估CDN的减速状况，确保最佳的用户体验，可用于CDN选型评估、CDN减速成果评估、CDN故障排查与定位等应用场景。API接口监测。通过监控API接口的响应工夫、可用性和正确性并及时告警来保障API服务的可靠性，可用于API接口性能优化、第三方API接口监控等应用场景。Graphite（2008）Graphite是一个开源实时的、显示工夫序列度量数据的图形系统，通过其后端接管度量数据，而后以实时形式查问、转换、组合这些度量数据。 劣势指标点分概念引入Grafana反对较早的协定之一统计函数反对（140+）劣势指标无Label反对应用场景剖析在做好数据归并时可用于大规模场景古代（2015-2021）Prometheus（2016 ）Prometheus 是由 SoundCloud 开源的监控告警解决方案。存储的是时序数据，即按雷同时序(雷同名称和标签)，以工夫维度存储间断的数据的汇合。 劣势时序型存储、查问效率高。反对集群模式，扩展性强。CNCF我的项目，社区沉闷。劣势一些Exporter采集的指标泛滥，需进行适当裁剪。自定义采集脚本须要脚本开发能力（Golang、Python），相比Shell脚本来说学习老本更高一些。应用场景剖析对于云计算、容器化场景更适宜夜莺（2018）夜莺是一套分布式高可用的运维监控零碎，前身是国内赫赫有名的open-falcon。基于一些国内非凡的运维场景和习惯，在运维圈中有着不俗的场景了解和用户体验。 劣势社区沉闷，有open-falcon大众根底。 产品设计灵便，人性化。 v4版本自带小型CMDB和自动化。 v5版本全面拥抱开源体系（Prometheus Telegraf）。 劣势v5刚公布，依然须要肯定的工夫积攒 后端存储的选型多样，须要依据场景进行抉择 短少日志类和Tracing类的监控场景 应用场景剖析所有指标类的监控 将来（2022-）云原生的呈现导致在k8s环境下的可观测性难度极具减少，因而呈现了eBPF等新技术，但无奈市场上大部分的客户Linux内核还不足以反对相干的技术。但能够看到的是DataDog skywalking 云杉等目前都在向eBPF进行布局。 除了加强程序本身的可观测性之外，能够预感在不久的未来，随着Linux内核的一直的欠缺以及客户环境逐步的成熟。在运维角度能够发力的可观测性的抉择肯定会越来越多。也心愿各位运维的同仁们时刻关注咱们的公众号，关注前沿的可观测性的信息。最初给大家介绍一些相干书籍： 优质监控书籍举荐 【Nagios系统监控实际（原书第2版）】Nagios系统监控实际（原书第2版） (豆瓣)") 【Cacti实战】Cacti实战 (豆瓣)") 【Ganglia系统监控】Ganglia系统监控 (豆瓣)") 【Graphite监控】Graphite监控 (豆瓣)") 【监控的艺术：云原生时代的监控框架】监控的艺术：云原生时代的监控框架 (豆瓣)") 【监控运维实际：准则与策略】监控运维实际：准则与策略 (豆瓣)") 【Prometheus云原生监控： 运维与开发实战】Prometheus云原生监控： 运维与开发实战 (豆瓣)") ...

WGCLOUD反对麒麟操作系统的 须要留神的中央，咱们下载linux版本的wgcloud安装包 如果麒麟零碎是arm架构 部署实现后，将server/wgcloud-daemon-release替换成arm版本的wgcloud-daemon-release https://www.wgstart.com/help/... arm版本的agent也在这里下载

目前越来越多的服务器被入侵，以及攻打事件频频的产生，像管理员明码被批改，外围配置文件被篡改，用户数据被脱裤，其余敏感文件被篡改等 咱们明天分享的正式这样一款工具，具备爱护服务器上文件被篡改的能力，若发现文件被篡改，会马上发送告警告诉（邮件微信钉钉等），咱们能够及时处理 WGCLOUD监控零碎：www.wgstart.com WGCLOUD是一款开源运维监控零碎，具备分布式、易部署、易上手、轻量等特点，咱们在此处不形容装置过程了，因为它网站有比拟具体的装置步骤，比较简单的 咱们来说说它的文件实时监测性能，就是文件防篡改性能，点击左侧菜单【文件防篡改】，就能够看到曾经增加的文件防篡改列表了 咱们能够增加本人的文件，来进行监测，首先啊，咱们抉择文件在哪个监控主机上，能力监测文件，录入文件的残缺门路，最初记得要把文件的MD5字符串输出进去，因为零碎要靠MD5来判断文件是否被篡改了，若被篡改，就会发送告警告诉，目前3.3.5版本每30分钟扫描一次文件 好了，到这里就增加完结了，WGCLOUD还有其余很棒的性能，咱们能够本人试用下 如下是我本人配置的微信告警音讯

以上面两个聚合规定为例，详解aggregator表达式的解析和计算过程，并提出能够优化的中央。 # 计算cpu.used.percent的平均值分子：$(cpu.used.percent)分母：$## 计算cpu.idle + cpu.busy为100的机器个数分子：($(cpu.idle) + $(cpu.busy)) > 90分母：11. 解析numberatorStr和denominatorStr别离是分子和分母的表达式字符串； 表达式中带$(的是须要计算的： // $(cpu.used.percent): true// $#: false// ($(cpu.idle) + $(cpu.busy)) > 90: true// 1: falseneedComputeNumerator := needCompute(numeratorStr)needComputeDenominator := needCompute(denominatorStr)func needCompute(val string) bool { return strings.Contains(val, "$(")}如果不须要计算，返回的numeratorOperands/numeratorOperators/numeratorComputeMode都为空； // $(cpu.used.percent)返回 [cpu.used.percent] [] ""// ($(cpu.idle) + $(cpu.busy)) > 90返回 [cpu.idle cpu.busy] [] ">90"numeratorOperands, numeratorOperators, numeratorComputeMode := parse(numeratorStr, needComputeNumerator)denominatorOperands, denominatorOperators, denominatorComputeMode := parse(denominatorStr, needComputeDenominator) func parse(expression string, needCompute bool) (operands []string, operators []string, computeMode string) { if !needCompute { return } splitCounter, _ := regexp.Compile(`[\$\(\)]+`) items := splitCounter.Split(expression, -1) count := len(items) for i, val := range items[1 : count-1] { if i%2 == 0 { operands = append(operands, val) } else { operators = append(operators, val) } } computeMode = items[count-1] return} 2. 计算先查问聚合组下的hosts列表，再查host列表的最新指标值，保留到map，以供聚合时应用： ...

aggregator组件负责聚合，即依据定义的指标表达式，聚合该组下所有host的指标值，生成新的指标发送到agent。 agent会将数据发送给transfer，transfer发送给graph，最终由graph存入TSDB。 值得注意的是，aggregator实例对分布式部署的反对无限，因为它每个实例都执行所有的聚合工作，没有进行聚合工作在不同节点的均分，也没有锁机制保障执行1个实例运行。当然，部署多份实例也不会呈现逻辑谬误，只是运行了多份雷同的工作而已。 1. aggregator的聚合表达式指标表达式分为分子和分母两局部，每局部都是1个表达式，别离计算出2局部的值，做商即得后果。 # 计算cpu.used.percent的平均值分子：$(cpu.used.percent)分母：$## 计算磁盘吞吐量的总量分子：$(disk.io.read_bytes)分母：1此外，还能进行更简单的汇合语义： # 计算disk.io.util大于等于40%的机器个数分子：$(disk.io.util)>=40分母：1# 计算集群diso.io.util大于40%的比率分子：$(disk.io.util)>40分母：$#2. aggregator的聚合模型聚合模型体现在Cluster构造中： type Cluster struct { ..... GroupId int64 //聚合组id Numerator string //分子表达式 Denominator string //分母表达式 Endpoint string //指标endpoint Metric string //指标metric Tags string //指标tags DsType string //指标metric类型 Step int //指标metric的step大小 ....}其中： GroupId: 聚合组id，依据该id能够查问失去该组下所有host；Numberator: 分子表达式，比方$(cpu.used.percent)；Denominator: 分母表达式，比方$#；Endpoint: 聚合后的endpoint；Metric: 聚合后的metric；Tags: 聚合后的tags；DsType: 聚合后的metric类型，GAUGE或COUNTER；Step: 聚合后的metric的step大小；以聚合组内所有host的cpu.used.percent平均值为例： GroupId = 900Numerator = $(cpu.used.percent)Denominator = $#Endpoint = 84aba056-6e6c-4c53-bfed-4de0729421efMetric = cpu.used.percentTags = nullDsType = GAUGEStep = 60聚合组内所有host的cpu.used.percent，计算平均值，而后生成endpoint=84aba056-6e6c-4c53-bfed-4de0729421ef，metric=cpu.used.percent, dsType=GAUGE, Step=60的指标。 ...

judge组件在做告警断定的时候，会解析配置的告警策略，生成一个fn，由fn.Compute()计算是否触发，比方： 配置 all(#3)>90 示意最近3次的数据都 > 90 触发；配置 max(#3)>90 示意最近3次的最大值 > 90 触发；配置 min(#3)<10 示意最近3次的最小值 < 10 触发；配置 avg(#3)>90 标识最近3次的avg > 90 触发；本文次要介绍fn如何生成，fn如何计算。 1. 告警判断告警断定的入口代码：解说judge代码时有介绍 ParseFuncFromString()生成fn;fn.Compute(L)依据最近的数据计算，断定是否触发;// modules/judge/store/judge.gofunc judgeItemWithStrategy(L *SafeLinkedList, strategy model.Strategy, firstItem *model.JudgeItem, now int64) { fn, err := ParseFuncFromString(strategy.Func, strategy.Operator, strategy.RightValue) historyData, leftValue, isTriggered, isEnough := fn.Compute(L) // 以后的数据点太少，不足以做告警断定 if !isEnough { return } ......}2. 如何生成fnfn由告警策略配置的string生成：比方配置 all(#3) > 90 str = all(#3)operator = >rightValue = 90// modules/judge/store/func.go// @str: e.g. all(#3) sum(#3) avg(#10) // @opeartor: > < func ParseFuncFromString(str string, operator string, rightValue float64) (fn Function, err error) { if str == "" { return nil, fmt.Errorf("func can not be null!") } idx := strings.Index(str, "#") args, err := atois(str[idx+1 : len(str)-1]) if err != nil { return nil, err } switch str[:idx-1] { case "max": fn = &MaxFunction{Limit: args[0], Operator: operator, RightValue: rightValue} case "min": fn = &MinFunction{Limit: args[0], Operator: operator, RightValue: rightValue} case "all": fn = &AllFunction{Limit: args[0], Operator: operator, RightValue: rightValue} case "sum": fn = &SumFunction{Limit: args[0], Operator: operator, RightValue: rightValue} case "avg": fn = &AvgFunction{Limit: args[0], Operator: operator, RightValue: rightValue} ...... default: err = fmt.Errorf("not_supported_method") } return}返回的Funtion是个interface类型，AllFunction、AvgFunction都实现了这个interface: ...

judge模块应用历史数据进行告警断定，其历史数据保留在内存中(仅保留最近的数据)，若触发告警，则发送event至redis，由alarm模块生产解决redis的事件。 因为judge模块将最近的历史数据保留在内存，因而它是有状态的；当节点宕机时，内存中的历史数据将失落。然而，因为监控数据会源源不断的上报，它会上报到其它judge节点，在其它节点从新进行告警断定。 judge模块的职责： 接管transfer转发的数据，并仅存储最近的几个点，以进行告警断定；配置remain=11，也就是依据最新的10个点数据，断定是否触发了告警；从hbs同步告警策略，hbs缓存了用户配置的策略列表，judge应用1个rpc长连贯查问策略列表；判断数据是否达到阈值产生告警事件：依据历史数据和策略表达式，判断是否达到阈值；判断告警事件是否应该写入redis: 告警事件不肯定写入redis，须要依据配置的最大报警次数来确定是否写入redis;比方配置最大报警次数=3，当第4次产生报警事件的时候，就不会写入redis；整体架构： 1. 接收数据：大Mapjudge接管transfer转发的数据，将数据存入本地内存： // modules/judge/rpc/receiver.gofunc (this *Judge) Send(items []*model.JudgeItem, resp *model.SimpleRpcResponse) error { remain := g.Config().Remain now := time.Now().Unix() for _, item := range items { ....... pk := item.PrimaryKey() store.HistoryBigMap[pk[0:2]].PushFrontAndMaintain(pk, item, remain, now) } return nil}本地的store.HistoryBigMap是个大Map: 为了加重大Map的并发读写压力，对itemKey的md5的前2个字符进行了拆分，分成了16*16=256个小Map，每个小Map内并发读写加锁，升高了锁粒度： // modules/judge/store/history.govar HistoryBigMap = make(map[string]*JudgeItemMap)func InitHistoryBigMap() { arr := []string{"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "a", "b", "c", "d", "e", "f"} for i := 0; i < 16; i++ { for j := 0; j < 16; j++ { HistoryBigMap[arr[i]+arr[j]] = NewJudgeItemMap() } }}type JudgeItemMap struct { sync.RWMutex M map[string]*SafeLinkedList}小map中：map[string]*SafeLinkedList，key=itemKey，value=最近的11个点，当有新数据时，会把老的数据从list中删掉；magicNumber=11(最近的11个点)在配置文件中指定，是一个教训数据，一般来讲依据最近的11个点来断定告警触发已足够；小map读写时应用Lock进行并发管制； ...

Open-falcon的graph组件应用rrd保留指标数据，rrd因为是本地存储，单机故障容易引起数据失落，Open-falcon提供了双写的逻辑(transfer双写2个graph节点)以加强可用性。 graph的指标数据的存储，可抉择不同的TSDB，比方InfluxDB、OpenTSDB等。 本文次要联合源码，介绍Open-falcon如何应用rrd保留和查问数据。 1. rrd文件的命名rrd文件的命名形式： md5=md5sum(metric, endpoint, tags)md5[0:2]_md5_dsType_step.rrd看一下代码中的实现： // RRDTOOL UTILS// 监控数据对应的rrd文件名称func RrdFileName(baseDir string, md5 string, dsType string, step int) string { return baseDir + "/" + md5[0:2] + "/" + md5 + "_" + dsType + "_" + strconv.Itoa(step) + ".rrd"}md5的计算：将endpoint/metric/tags拼成string，而后md5sum(string) //MD5的值func Checksum(endpoint string, metric string, tags map[string]string) string { pk := PK(endpoint, metric, tags) return Md5(pk)}func PK(endpoint, metric string, tags map[string]string) string { ret := bufferPool.Get().(*bytes.Buffer) ret.Reset() defer bufferPool.Put(ret) if tags == nil || len(tags) == 0 { ret.WriteString(endpoint) ret.WriteString("/") ret.WriteString(metric) return ret.String() } ret.WriteString(endpoint) ret.WriteString("/") ret.WriteString(metric) ret.WriteString("/") ret.WriteString(SortedTags(tags)) return ret.String()}比方:trovedev这台机器的agent.alive的数据，该指标将被存储在be/be3cdc0fce0d498e19e2c6e9f1f338b6_GAUGE_60.rrd文件中： ...

hbs负责周期性的读取db中内容，缓存到本地cache，而后提供RPC接口以供agent和judge两个组件查问调用。 // modules/hbs/rpc/rpc.gofunc Start() { server := rpc.NewServer() server.Register(new(Agent)) server.Register(new(Hbs)) l, e := net.Listen("tcp", addr) for { conn, err := l.Accept() ...... go server.ServeCodec(jsonrpc.NewServerCodec(conn)) }}hbs对接agent: 解决agent heartbeat申请；解决agent plugin的查问申请；解决agent 监控哪些过程、哪些端口的查问申请；hbs对接judge： 查问以后配置的所有告警策略；查问以后配置的所有告警表达式；整体流程图： 1. hbs对接agentagent查问执行哪些plugin: // modules/hbs/rpc/agent.gofunc (t *Agent) MinePlugins(args model.AgentHeartbeatRequest, reply *model.AgentPluginsResponse) error { if args.Hostname == "" { return nil } reply.Plugins = cache.GetPlugins(args.Hostname) reply.Timestamp = time.Now().Unix() return nil}agent查问监控哪些过程、哪些端口： // modules/hbs/rpc/agent.gofunc (t *Agent) BuiltinMetrics(args *model.AgentHeartbeatRequest, reply *model.BuiltinMetricResponse) error { if args.Hostname == "" { return nil } metrics, err := cache.GetBuiltinMetrics(args.Hostname) if err != nil { return nil } checksum := "" if len(metrics) > 0 { checksum = DigestBuiltinMetrics(metrics) } if args.Checksum == checksum { reply.Metrics = []*model.BuiltinMetric{} } else { reply.Metrics = metrics } reply.Checksum = checksum reply.Timestamp = time.Now().Unix() return nil}能够看到，下面的rpc接口操作的都是cache，hbs会定期的从db中查问数据，而后缓存在本地cache，以供agent查问： ...

Open-falcon提供了Grafana的插件，能够将Open-falcon的指标数据作为数据源，显示到Grafana上。 1. 装置Grafana# rpm -qa|grep grafanagrafana-6.5.2-1.x86_64# systemctl |grep grafanagrafana-server.service 2. 装置Grafana的Open-falcon插件# pwd/var/lib/grafana/plugins# git clone https://github.com/open-falcon/grafana-openfalcon-datasource# ls -alh总用量 0drwxr-xr-x 3 grafana grafana 43 4月 30 18:02 .drwxr-xr-x 4 grafana grafana 50 6月 8 10:23 ..drwxr-xr-x 7 root root 305 4月 30 18:02 grafana-openfalcon-datasource重启Grafana: # systemctl restart grafana-server.service3. 配置Grafana1)增加Open-falcon作为数据源： 2)增加query表达式：

agent通过RCP向transfer发送metrics时，应用rpc长连贯，通过net/rpc保护一个tcp connection。 agent封装了SingleConnRpcClient构造，来实现单连贯rcp client。 1. SingleConnRpcClient如何应用的？agent对应的后端transfer有多个，只有向1个transfer发送胜利就OK；发送时，先依据addr找可用的rpcclient，找不到就init一个，而后调用update实现调用操作。 func SendMetrics(metrics []*model.MetricValue, resp *model.TransferResponse) { rand.Seed(time.Now().UnixNano()) for _, i := range rand.Perm(len(Config().Transfer.Addrs)) { //把数组的程序打乱 addr := Config().Transfer.Addrs[i] c := getTransferClient(addr) //从map中找 if c == nil { c = initTransferClient(addr) //没找到，进行初始化 } if updateMetrics(c, metrics, resp) { //发送，若胜利则break break } }}初始化rpcclient: func initTransferClient(addr string) *SingleConnRpcClient { var c *SingleConnRpcClient = &SingleConnRpcClient{ RpcServer: addr, Timeout: time.Duration(Config().Transfer.Timeout) * time.Millisecond, } ...... TransferClients[addr] = c return c}发送的逻辑：调用RPC办法：Transfer.Update ...

semaphore即信号量，Open-falcon在将queue中的数据发送给graph时，用semaphore管制并发的goroutine数量，防止产生大量的发送goroutine。 func forward2GraphTask(Q *list.SafeListLimited, node string, addr string, concurrent int) { sema := nsema.NewSemaphore(concurrent) for { items := Q.PopBackBy(batch) sema.Acquire() go func(addr string, graphItems []*cmodel.GraphItem, count int) { defer sema.Release() err = GraphConnPools.Call(addr, "Graph.Send", graphItems, resp) .... } .... }}semaphore应用channel实现： 定义一个len的channel；当申请semaphore时，入队channel一个元素，当超过len时，阻塞住，也就是申请失败；当开释semaphore是，出队channel一个元素；type Semaphore struct { bufSize int channel chan int8}func NewSemaphore(concurrencyNum int) *Semaphore { return &Semaphore{channel: make(chan int8, concurrencyNum), bufSize: concurrencyNum}}申请semaphore: //channel入队胜利，返回true；否则返回false；func (this *Semaphore) TryAcquire() bool { select { case this.channel <- int8(0): return true default: return false }}//若channel未满，入队返回；否则，阻塞func (this *Semaphore) Acquire() { this.channel <- int8(0)}开释semaphore: channel出队一个元素 ...

transfer通过一致性hash算法，决定一条指标应该发送到哪个graph节点。 transfer应用了toolkits/consistent提供的一致性hash实现，调用办法很简略： //结构hash环GraphNodeRing = rings.NewConsistentHashNodesRing(int32(cfg.Graph.Replicas), cutils.KeysOfMap(cfg.Graph.Cluster))//查找key对应的nodenode, err := GraphNodeRing.GetNode(pk)本文解说一致性hash算法是什么，联合代码解说一下toolkits/consistent如何实现一致性hash算法。 1. 一般的 mod N hash算法最简略的hash是mod N： group = key % N mod N hash算法的毛病；只有集群N的数量发生变化，绝大部分的key的映射关系生效(翻倍的扩容/缩容，可维持50%的失效率)。 2. 一致性hash算法是什么一致性hash通过构建环状hash空间，代替了线性hash空间的办法，解决了hash映射下绝大部分映射生效的问题： 整个hash空间被构建成一个首尾相接的环，应用一致性hash时须要进行2次映射： 每个节点计算hash，确定其在hash环上的地位(uint32的整数)；每个key计算hash(uint32的整数)，而后顺时针找环上的第一个点，该key就存储到该节点上；一致性hash的长处是，当减少节点/删除节点时，只有一部分key的映射产生生效： 一致性hash的特点是满足枯燥性要求： 假如key调配在节点A上，当有新节点N退出集群时，key会映射到节点A或节点N上，不会映射到其它节点；一致性hash算法有2个问题： 数据歪斜：如果节点的数量很少，可能会呈现大部分key拥挤的散布在某个节点上的状况；缓存雪崩：当node1故障退出时，原来node1负责的key将由node2解决，意味着node2的压力会霎时增大；若node2因为压力过大而解体，那么更大的压力将冲向node3，造成雪崩；一致性hash引入虚构节点解决了这一问题： 一个理论节点映射为多个虚构节点，这样hash空间会绝对平均；一个实在的节点退出，它原来承当的压力会平均的扩散到其它节点； 3. 一致性hash算法的实现(toolkits/consistent)toolkits/consistent的实现也很简略： 应用CRC32结构了一个hash环(unit32)；对nodeKey进行hash失去value=A(uint32)，对应hash环的一个地位；对itemKey进行hash失去value=B(uint32)，二分查问hash环中第一个 > B的节点，该节点就负载该item；// Consistent holds the information about the members of the consistent hash circle.type Consistent struct { circle map[uint32]string members map[string]bool sortedHashes uints NumberOfReplicas int count int64 scratch [64]byte sync.RWMutex}增加节点：每个node有若干个replica，对每个replica都hash失去nodeKey，放入circle中： // Add inserts a string element in the consistent hash.func (c *Consistent) Add(elt string) { c.Lock() defer c.Unlock() c.add(elt)}// need c.Lock() before callingfunc (c *Consistent) add(elt string) { for i := 0; i < c.NumberOfReplicas; i++ { c.circle[c.hashKey(c.eltKey(elt, i))] = elt } c.members[elt] = true c.updateSortedHashes() c.count++}查问itemKey映射到哪个node:先算itemKey的hash，而后二分查找circle，找第一个 > hash的节点即为指标节点： ...

transfer组件通过一致性hash调配，应用RPC接口将数据发送给judge组件，由judge组件做告警断定。 在transfer中，对于没有配置告警策略的指标，没有必要存储到judgeQueue，也没有必要发送给judge节点。 Open-falcon的解决是由transfer把所有的指标无脑发给judge，由judge判断该指标是否有告警规定关联。 nightingale作为升级版的Open-falcon，它的解决较为奇妙，它在transfer组件中就做了判断，若指标没有告警规定关联，则就无需存入judgeQueue，也不会发送到judge了，大大减少了网络发送数据量。 基于此，可对Open-falcon的transfer-->judge做肯定的流程优化。 1. Open-falcon的transfer-->judgetransfer将所有的指标无脑发送给judge，由judge做告警规定的断定；看一下judge的代码，g.FilterMap中存储了metric及其告警规定信息，g.FilterMap的信息由judge申请hbs取得： //modules/judge/rpc/receiver.gofunc (this *Judge) Send(items []*model.JudgeItem, resp *model.SimpleRpcResponse) error { remain := g.Config().Remain now := time.Now().Unix() for _, item := range items { exists := g.FilterMap.Exists(item.Metric) //过滤有metric的数据 if !exists { continue } pk := item.PrimaryKey() store.HistoryBigMap[pk[0:2]].PushFrontAndMaintain(pk, item, remain, now) } return nil}流程如下图所示： 2. nightingale的transfer-->judgenightingale在transfer这一层就把无关告警规定的metric都过滤掉了，不再发送给judge。 Transfer接管agent指标的代码入口： //agent发送数据到transfer，transfer存储到queue// src/modules/transfer/rpc/push.gofunc (t *Transfer) Push(args []*dataobj.MetricValue, reply *dataobj.TransferResp) error { start := time.Now() items := make([]*dataobj.MetricValue, 0) for _, v := range args { if err := v.CheckValidity(start.Unix()); err != nil { ...... continue } items = append(items, v) } ...... if backend.Config.Enabled { backend.Push2JudgeSendQueue(items) } reply.Total = len(args) reply.Latency = (time.Now().UnixNano() - start.UnixNano()) / 1000000 return nil}筛选metric到judgeQueue的代码： ...

transfer能够了解为直达模块，它接管agent上报的指标，而后转发给后端的graph和judge实例。 transfer接管到agent上报的指标后，先存储到内存queue，而后再由goroutine默默的将queue的数据Pop进去，转发给graph和judge。 transfer后端接多个graph和judge实例，如何保障某一个指标稳固的转发到某个实例，同时还能保障多个graph间放弃平衡，不会呈现某个graph承当过多的指标而产生数据歪斜？transfer应用了一致性hash算法来做到这一点。 整体架构： 1. transfer接管agent上报的指标数据transfer通过TCP RPC接管agent的数据： // modules/transfer/receiver/rpc/rpc.gofunc StartRpc() { listener, err := net.ListenTCP("tcp", tcpAddr) server := rpc.NewServer() server.Register(new(Transfer)) for { conn, err := listener.AcceptTCP() go server.ServeCodec(jsonrpc.NewServerCodec(conn)) }}transfer的RPC办法：Transfer.Update，负责接收数据 //modules/transfer/receiver/rpc/rpc_transfer.gotype Transfer intfunc (t *Transfer) Update(args []*cmodel.MetricValue, reply *cmodel.TransferResponse) error { return RecvMetricValues(args, reply, "rpc")}func RecvMetricValues(args []*cmodel.MetricValue, reply *cmodel.TransferResponse, from string) error { items := []*cmodel.MetaData{} for _, v := range args { fv := &cmodel.MetaData{ Metric: v.Metric, Endpoint: v.Endpoint, Timestamp: v.Timestamp, Step: v.Step, CounterType: v.Type, Tags: cutils.DictedTagstring(v.Tags), } ....... items = append(items, fv) } if cfg.Graph.Enabled { sender.Push2GraphSendQueue(items) } if cfg.Judge.Enabled { sender.Push2JudgeSendQueue(items) }}能够看到，transfer间接将items放入graph/judge中的Queue就返回了，并不会间接发送；这样做有以下益处： ...

agent是指标采集模块，仅关注linux自身的监控指标，次要负责： 定期进行指标采集，而后通过RPC上报给Transfer；向hbs发送heartbeat，同时从hbs获取要监听的process、port和要执行的plugin信息；定期执行plugin，将plugin的指标后果发送给Transfer；整体架构： 1. 指标采集代码入口： func main() { ...... cron.Collect() ......}//modules/agent/cron/collector.gofunc Collect() { ..... for _, v := range funcs.Mappers { go collect(int64(v.Interval), v.Fs) }}其中funcs.Mappers是采集函数的汇合，agent为每一类采集启动了一个goroutine，有几种分类就有几个goroutine： //modules/agent/funcs/funcs.govar Mappers []FuncsAndIntervalfunc BuildMappers() { interval := g.Config().Transfer.Interval Mappers = []FuncsAndInterval{ { Fs: []func() []*model.MetricValue{ AgentMetrics, CpuMetrics, NetMetrics, KernelMetrics, LoadAvgMetrics, ...... }, Interval: interval, }, { Fs: []func() []*model.MetricValue{ DeviceMetrics, }, Interval: interval, }, ...... }}具体的采集过程，执行每个采集函数，将采集的指标会集起来，发送给transfer: // modules/agent/cron/collector.gofunc collect(sec int64, fns []func() []*model.MetricValue) { t := time.NewTicker(time.Second * time.Duration(sec)) defer t.Stop() for { <-t.C hostname, err := g.Hostname() if err != nil { continue } mvs := []*model.MetricValue{} ignoreMetrics := g.Config().IgnoreMetrics for _, fn := range fns { items := fn() for _, mv := range items { mvs = append(mvs, mv) ...... } } ...... g.SendToTransfer(mvs) }}2. 指标上报Transferagent与Transfer之间是TCP RPC通道，agent配置了多个transfer的地址，上报时随机选一个地址，只有上报胜利就退出，不再尝试其余的transfer地址： ...

什么是SkyWalking？分布式系统的应用程序性能监督工具，特地是为微服务，云原生和基于容器（Docker，Kubernetes，Mesos）的体系结构而设计。 SkyWalking是一个可察看性剖析平台和应用程序性能管理系统。跟踪，指标和日志记录多合一解决方案。反对Java，.Net Core，PHP，NodeJS，Golang，LUA，C ++代理反对Istio + Envoy Service Mesh 上述源自 SkyWalking 官网 链路追踪工具简介比照1、Zipkin：是Twitter开源的调用链分析工具，目前基于springcloud sleuth失去了宽泛的应用，特点是轻量，应用部署简略。 2、Jaeger 是 CNCF 云原生我的项目之一，Jaeger 受 Dapper 和 OpenZipkin 的启发，由 Uber 开源的分布式追踪零碎，兼容 Open Tracing API。 3、Pinpoint：是韩国人开源的基于字节码注入的调用链分析，以及利用监控剖析工具。特点是反对多种插件，UI功能强大，接入端无代码侵入。 4、SkyWalking：是外乡开源的基于字节码注入的调用链分析，以及利用监控剖析工具。特点是反对多种插件，UI性能较强，接入端无代码侵入。目前已退出Apache孵化器。 工具指标比照： 指标/组件ZipkinJaegerSkywalkingPinpointOpenTracing 兼容反对反对反对不反对客户端反对语言Java、C#、Go、PHP 等Java、C#、Go、PHP 等Java, .NET Core, NodeJS and PHPJava、PHP传输协定Http/MQUDP/HttpgRPCThriftWeb UI弱个别个别强扩展性强强个别弱性能损失个别个别低高实现形式拦挡申请，侵入拦挡申请，侵入字节码注入，无侵入字节码注入，无侵入告警不反对不反对反对反对小结：Zipkin与Jaeger相差不多且都有代码侵入，性能损耗方面Skywalking绝对Pinpoint较低，Pinpoint 在 Web UI上较其余三种较丰盛些 skywalking部署（本文应用Rancher2.X）skywalking-oap-server存储；elasticsearch 6.x 镜像：apache/skywalking-oap-server:7.0.0-es6 skywalking-ui镜像：apache/skywalking-ui:8.1.0 不便拜访加个Ingress配置个域名如：http://skywalking-ui.com/ skywalking-agent自建，参考https://hub.docker.com/r/prop...。 编写一个Dockerfile： FROM alpine:3.8 LABEL maintainer="123456789@qq.com" ENV SKYWALKING_VERSION=7.0.0 ADD http://mirrors.tuna.tsinghua.edu.cn/apache/skywalking/${SKYWALKING_VERSION}/apache-skywalking-apm-${SKYWALKING_VERSION}.tar.gz / RUN tar -zxvf /apache-skywalking-apm-${SKYWALKING_VERSION}.tar.gz && \ mv apache-skywalking-apm-bin skywalking && \ mv /skywalking/agent/optional-plugins/apm-trace-ignore-plugin* /skywalking/agent/plugins/ && \ echo -e "\n# Ignore Path" >> /skywalking/agent/config/agent.config && \ echo "# see https://github.com/apache/skywalking/blob/v7.0.0/docs/en/setup/service-agent/java-agent/agent-optional-plugins/trace-ignore-plugin.md" >> /skywalking/agent/config/agent.config && \ echo 'trace.ignore_path=${SW_IGNORE_PATH:/health}' >> /skywalking/agent/config/agent.configdocker build到镜像仓库， 待docker build结束后，push到仓库就能够了 ...

看下/server/下的wgcloud-daemon-release是否有执行权限，有时候拷贝过去的，执行权限就丢了，加上就好了，重启试试。 官网：www.wgstart.com chmod +x wgcloud-daemon-release

总结：aggregator聚合器就是从falcon_portal.cluster表中取出用户在页面上配置的表达式,然后解析后，通过api拿到对应机器组的所有机器，通过api查询graph数据算出一个值重新打回transfer作为一个新的点。 定时从db中拿出所有的聚合器配置放到一个map中第一次启动时遍历聚合器map生成workers map 这两个map的key都是id+updatetime同时下一次拿出db生成map 对workers这个map进行增量更新 和删除操作删除是通过 worker.Quit chan通信的workers这个map 通过 ticker跑cron 运行WorkerRun这个方法WorkerRun这个方法解析分子分母的配置调用api 根据grp_id拿出所有机器列表调用graph的last接口拿出所有endpoint的counter 的值然后进行计算计算后重新打回 一个线程安全的双向链表队列另外一个goroutine异步pop队列中的值发生给 transfer的http接口(不是给agent用的rpc接口)机器量很多时获取机器列表和查询最新的值都是瓶颈我在想如果直接在transfer中直接做数据的聚合速度上不存在瓶颈下面我们来看下代码: main.go中核心的两个地方 //查询db 调api算值 push 到push的队列中 go cron.UpdateItems() //从push队列push到transfer sender.StartSender()2.看下go cron.UpdateItems() func updateItems() { //从db中查询出结果 items, err := db.ReadClusterMonitorItems() if err != nil { return } //对比key(id+uptime),将已经变更的项删除 deleteNoUseWorker(items) //启动新的worker createWorkerIfNeed(items)}//看下这个读db的funcfunc ReadClusterMonitorItems() (M map[string]*g.Cluster, err error){ ...... /*看到这个funcreturn的是个map key是 每个聚合项的id和他更新时间的字符串 value 就是Cluster结构体指针 type Cluster struct { Id int64 GroupId int64 Numerator string Denominator string Endpoint string Metric string Tags string DsType string Step int LastUpdate time.Time } */ M[fmt.Sprintf("%d%v", c.Id, c.LastUpdate)] = &c return M, err}3.看下 deleteNoUseWorker 和createWorkerIfNeed 这两个func都是围绕 Worker这个struct的进行增删 ...