wordpress浮窗音乐,德州网站优化,用手机怎么看自己做的网站,html5网站建设 教程作为全球首家以超连接为核心的云服务商#xff0c;Zenlayer 致力于将云计算、内容服务和边缘技术融合#xff0c;为客户提供全面的解决方案。通过构建可靠的网络架构和高效的数据传输#xff0c;Zenlayer 帮助客户实现更快速、更可靠的连接#xff0c;提升用户体验和业务效… 作为全球首家以超连接为核心的云服务商Zenlayer 致力于将云计算、内容服务和边缘技术融合为客户提供全面的解决方案。通过构建可靠的网络架构和高效的数据传输Zenlayer 帮助客户实现更快速、更可靠的连接提升用户体验和业务效率。Zenlayer 在全球范围内运营着超过 290 个边缘节点 骨干网带宽超过 50Tbps 10000 的数据中心接入点快速连接全球公有云与数据中心。 监控现状
Zenlayer 运营着全球数百个边缘机房和庞大的骨干网网络我们的监控目标主要包括
各种硬件设备如交换机、裸金属超大大规模网络的连通性和质量Kubernetes 云原生技术栈
在 Zenlayer监控系统不仅仅是作为一个内部工具服务于运维和研发团队我们的售后团队高度依赖监控系统为客户提供高水平的技术支持服务监控系统是 Zenlayer 最重要的基础服务和产品之一是我们交付用户价值的关键所在。
目前我们使用的监控工具有Zabbix、Prometheus、夜莺 Nightingale、ClickHouse
采用 Zabbix 监控各种网络设备将全球各个边缘节点的监控数据汇聚到中心统一处理。采用 Prometheus 收集 Zenlayer 的云原生技术栈的监控数据统一使用夜莺 Nightingale 来配置和管理告警规则。使用 ClickHouse 对系统日志进行分析。
痛点和挑战
考虑到 Zenlayer 的设备数量近万台网络设备、设备种类、全球化布局Zabbix 逐渐接近性能瓶颈
海量数据的查询、看图、报警对 Zabbix 数据库有很大的写入和查询压力且无法有效扩展。全球的监控数据汇总一处会有频繁的监控数据中断、时延等问题影响报警的及时性和准确性。对网络专线强依赖若专线发生异常会导致相应边缘节点的监控报警完全不可用产生监控盲区。数据合规性要求某些边缘节点的数据不允许汇聚到中心目前的架构难以有效应对。 鉴于我们在 Zabbix 之外也用到了另外多种监控工具
工具多体验不一致技术团队学习成本很高。数据孤岛现象严重关联分析成本高效率低比如 Zabbix 、Prometheus、夜莺之间的数据难以有效串联。日志分析的能力较为不足比如缺少高效便捷的日志报警等功能。
我们迫切需要对现有的监控方案做出改进以支撑不断增长的业务、适应不断变化的用户需求提供可持续的服务能力具体而言有以下三个目标 解决方案
Zenlayer 技术团队在调研技术方案的时候关注到了快猫星云的 Flashcat 平台。使用 Flashcat可以在一个平台上完成指标、日志、链路追踪数据的统一采集、可视化、告警、分析和 OnCall 免去搭建和维护多套 Prometheus/Zabbix/Grafana/ELK/Jaeger 的工作量屏蔽多云监控的复杂度。Flashcat 平台的定位和特点与 Zenlayer 新一代监控方案的设计目标极为吻合
水平扩展的架构高性能高可用有上千家企业使用经受了严苛的生产实践检验。支持边缘节点部署模式可以在中心端高效、便捷的监控众多边缘节点契合 Zenlayer 边缘计算的业务特点。内置了故障处理的最佳实践当业务受损时Flashcat 能第一时间发现并辅助技术团队快速展开调查特别适合我们构建售后监控支撑平台的目标。支持物理机、网络设备、容器、K8s微服务、主流云产品完全覆盖我们的监控场景。
Zenlayer 与快猫星云技术专家一起重点从全球化架构、边缘计算、网络监控、Zabbix 替代等方面出发根据 Zenlayer 自身的业务特点结合快猫星云在统一监控和稳定性保障方向的最佳实践构建起了「Zenlayer新一代的统一监控方案」最终也实现了对 Zabbix 的完美替代解除了困扰已久的难题。
落地效果
边缘部署模式
首先我们测试了 Flashcat 的边缘节点部署模式将 Zenlayer 全球划分为 7 大 Region其中以 HK 为中心 Region其余为边缘端我们采用了如下部署架构
在每个边缘端本地保存监控数据即使网络中断本地仍然能够闭环工作独立告警。中心端进行告警规则、仪表盘、数据采集策略的集中式管理、集中查询降低多 region 运维成本用户只需要面对 Flashcat 中心端。中心端、边缘端均采用集群方式部署可横向扩展以满足本区域不断增长的监控需求。当前主要采集存储 Metrics 指标接下来可在边缘机房部署日志组件不适合传输到中心端的数据可以本地化处理。 利用 Flashcat 的边缘部署模式有效的解决了 Zenlayer 全球节点监控数据汇聚带来的问题提升了监控数据的时效性、可靠性降低了监控数据汇聚带来的网络传输成本同时还减轻了整个监控系统的维护和配置成本。
Zabbix 替换
在 Zenlayer我们深度使用 Zabbix特别的我们本质上是一家网络公司背后有近万台各种型号的网络设备分布在全球范围内所以重度依赖 Zabbix 对网络设备的数据采集和报警能力比如
Zabbix 对网络设备的自动发现能力Zabbix 对各种网络设备SNMP采集的配置模板Zabbix 采集所支持的设备型号更全面Zabbix 报警中的宏模式…
此外我们的技术团队对于 Zabbix 使用时间久如果迁移到新的工具有一定的迁移成本。带着以上的问题出发我们对 Flashcat 进行了细致的测试发现 Flashcat 对 Zabbix 能力的兼容性非常不错以网络设备的监控数据采集为例介绍如下。
网络设备采集配置模板化
Flashcat 针对特定型号的网络设备支持用户将采集该设备 Metrics 的 SNMP 配置以模板的形式在 WebUI 上管理和配置然后下发给指定的采集器 Categraf。比如 通过SNMP采集华为某型号交换机 uptime 和 sysname 指标的采集模板 oid RFC1213-MIB::sysUpTime.0
name uptime[[instances.field]]
oid RFC1213-MIB::sysName.0
name sysname
is_tag true采集内存总量和使用量的采集模板 ...
[[instances.field]]
oid .1.3.6.1.2.1.25.2.3.1.5.1
name memsize[[instances.field]]
oid .1.3.6.1.2.1.25.2.3.1.6.1
name memuse
...Zabbix 用户尤其是深度用户 之前在 Zabbix 中已经积累了很多模板这个模板如果按照 Flashcat 的格式去人工配置一遍也是一个很大的工作量。为了减轻这方面的工作量Flashcat 支持将 Zabbix 的 XML 格式转换为 Flashcat 格式的采集模板这样就可以加速从 Zabbix 采集模板往 Flashcat 采集模板迁移的过程。在测试中我们和快猫星云的技术专家在 Flashcat 中创建了30多种网络采集模板。
- Arista Device Status
- Juniper Device Status
- Juniper BGP
- Nokia Device Status
- Huawei BGP
- Arista BGP
- Ciena Optical
- Juniper Optical
- Ruijie Device Status
- Sintai Optical
- Ruijie Optical
- H3C Optical
- IDC Interface
- Network Status
- ...报警支持宏模式
宏变量是 Zabbix 中很强大的一个特性告警阈值可以通过宏变量来设置这样不同角色的设备就可以分别设置自己的阈值了。Flashcat 平台对宏变量也进行了支持。在测试中我们从 Zabbix 中迁移了上百条告警规则到 Flashcat 中。
Pingmesh
Pingmesh 是一种用于测量和监控网络性能的技术通过在一组通信对等体之间执行 Ping 测试来评估网络的可用性和延迟。Flashcat中的 Pingmesh 功能提供了 TCP、UDP、ICMP 三种协议在设备之间进行互相探测并绘制各个层面的连通性视图从全局视角观测整个网络的连通性这对于我们的全球化布局特别有价值能够帮助我们一目了然的看清楚不同的边缘节点之间、不同的机柜之间的网络连通质量。如果你想了解更多 Pingmesh 的技术细节请查阅网络问题排查必备利器Pingmesh。
SNMP采集支持多进制转化
在网络设备中,有些 OID 对应的值可能并不是数值需要从 string 或者 hex-string 格式进行转换。比如某些设备其 MAC 地址和 IP 地址都是以 hex-string 形式存储和展示的如果直接采集在 Flashcat 平台上展示的话会是乱码形式。下面的示例就是演示如何配置将 BGP 对端的 IP 地址作为 tag 附加到指标上的。如果指定conversionhwaddr则是进行 MAC 地址转换指定conversionfloat则是将字符转为 float 类型还支持转为 int、 hextoint 等。
[[instances.table.field]]
oid .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11
name peer_addr
conversion ipaddr
is_tag trueSNMP采集支持返回多值
绝大部分 OID 返回值都是单值的只需要考虑将返回值转换为合适的格式即可。但是光模块功率是一个典型的多值返回Flashcat 针对光模块采集做了扩展。比如下面这段配置是将返回值中4个部分分别对应rx_0_lane0 rx_0_lane1 rx_0_lane2 rx_0_lane3 这4个返回值都按照 float 类型进行了转换。
[[instances.table.field]]
oid .1.3.6.1.4.1.2011.5.25.31.1.1.3.1.32
name rx_0
conversionlane0:float,lane1:float,lane2:float,lane3:float支持relabel/rename
比如 index 原始值如下, 想把这两个字段前3位1.1.4.和1.2.16.去掉,生成新标签 peer_addr
index1.2.16.36.4.255.64.0.1.0.99.0.0.0.0.0.0.0.2
index1.1.4.103.140.146.151增加如下配置即可
[[instances.relabel_configs]]
source_labels [index]
target_label peer_addr
#separator /
regex \\d\\.\\d\\.\\d\\.(.*)
action replace
replacement $1如果不想保留老的index label那么配置如下
[[instances.relabel_configs]]
regex index
action labeldropBGP监控数据采集
假设有两张表需要做关联 , 比如 BGP 中 peer_index 对应的 OID 是 .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14 另一张 receive 表对应的 OID 是 .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7想对两张表做关联peer_index 表的 index 中第一位作为 receive 表的 index 的一部分。
先看peer_index的返回:
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.178 0
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.179 1
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.1.128.1.130.176.1.128.1.130.180 2
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.2 3
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.3 4
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14.0.2.38.4.9.128.224.5.47.255.0.0.0.0.0.0.0.1.2.38.4.9.128.224.5.47.255.0.0.0.0.0.4 5再看receive表的返回:
.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.0.1.1 2071
.1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7.3.2.1 0这两张表关联查询那就用 peer_index 对应的值 0/1/2/3/4/5 和 receive 表中的 index 0.1.1/3.2.1 关联匹配但是因为他们长度不同(peer_index的值只有一位)所以长度对齐就用到了一个 oid_index_length 配置。 比如 oid_index_length1 表示 receive 表的 index 的第一位只要匹配到 0/1/2/3/4/5 中任意一位就认为匹配成功。peer_index的配置如下:
[[instances.table.field]]
oid .1.3.6.1.4.1.2636.5.1.1.2.1.1.1.1.14
name peer_index
is_tag true
secondary_index_table true # 这个表的index对应的值要被其他表使用receive表配置如下:
[[instances.table.field]]
oid .1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7
name receive_total_prefix
oid_index_length1 # 只取关联index的第一位
secondary_index_use true # 使用上面指定的index这样最终取到的指标只有一个
snmp_juniper_bgp_prefix_receive_total_prefix{index0.1.128.1.130.176.1.128.1.130.178} 2017从监控走向可观测
除过对 Zabbix 替换的需求突破扩展性瓶颈限制等问题。Zenlayer 对于建立全面的可观测性体系在过去的工作中或多或少都有一些建设了比如
我们使用 ClickHouse 存储和分析日志制作报表我们使用 Prometheus 收集多套 K8s/K3s 云原生技术栈的数据并使用夜莺 Nightingale 管理告警规则我们构建了网络层面的立体化的监测在某些特定场景下我们借助智能监控提升效率降低维护成本我们使用 on-call 工具管理告警的全生命周期过程提高告警的处理效率降低工作失误…
客观讲我们不缺少工具也不是缺少数据困扰我们的反而是工具太多了数据太多了更多的工具意味着更多的学习成本面对更多的数据如果缺乏高效的分析能力数据只能是负担。我们在测试 Flashcat 的过程中充分调研了 Flashcat 的多数据源接入功能包括 Metrics 源、Logging 源、Tracing 源、事件源四大类。在对接数据源后用户就可以在 Flashcat 平台上对这些数据源背后的数据进行集中的查询、可视化分析、告警等。并借助 Flashcat 的北极星和灭火图我们构建起了面向业务场景、层层下钻的故障发现、定位体系。
比如在故障发现层面我们利用 Flashcat 提供的智能检测算法对骨干网络流量进行实时监测当流量出现异常波动1分钟就可以被检测到并发送我们的技术团队知晓和应急。 总结
Zenlayer 与快猫星云技术专家一起重点从全球化架构、边缘计算、网络监控、Zabbix 替代等方面出发根据 Zenlayer 自身的业务特点结合快猫星云在统一监控和稳定性保障方向的最佳实践构建起了 Zenlayer 新一代的统一监控方案最终也实现了对 Zabbix 的完美替代解除了困扰已久的难题。
