主流metric 、trace、logging框架介绍

部署运行你感兴趣的模型镜像
场景一:页面提示超时了,到底是哪个服务响应慢了呢?

场景二:系统当前的处理能力如何,TPS、QPS 指标是多少呢?

场景三:线上服务部署在多台机器上,你挨个登录机器去查日志,感觉烦不烦?

面对诸如上面的场景,如果你正在纠结,那今天罗列推荐的这些轮子,多少都能解你所惑。

0. 监控天下三分

先帝创业未半而中道崩殂,今监控天下三分。如下图所示,监控的天下被划分为基于 Tracing(调用链)监控、基于Metrics(指标)监控、基于Logging(日志) 的监控。

1. 基于 Tracing 的监控

基于 Tracing 的监控,背后对应的是追踪系统,也有人叫调用链系统,做应用性能监控(APM)这块是必不可少的。

如果你想知道一次服务调用,中间经过了哪些环节?如果你想了解一次服务调用过程中各个环节的耗时?如果... ... 那不妨了解了解下面的这些轮子。

Skywalking,国产的优秀 APM 组件。是一个对 Java 分布式应用的业务运行情况进行追踪、告警和分析的系统。

开源地址:https://github.com/apache/skywalking

Zipkin,是由 Twitter 公司开源的分布式的跟踪系统。主要包括:数据的收集、存储、查找和展现。

开源地址:https://github.com/openzipkin/zipkin

Pinpoint,由韩国人开源的分布式跟踪组件,是一款对 Java 编写的大规模分布式系统的 APM 工具。

开源地址:https://github.com/naver/pinpoint

贴一下效果图,不知能否勾起你心中的火热。

2. 基于 Metrics 的监控

基于 Metrics 的监控,背后对应的是度量(指标监控)系统。

如果你想知道机器在某段时间内的 CPU 使用率、系统负载;如果你想知道应用在某段时间内的 HTTP 请求访问量;如果你想知道 MySQL 的连接数、QPS;如果... ... 那不妨尽情的了解了解下面的这些轮子。

Prometheus + Grafana,普罗米修斯邂逅格拉法纳就成了监控界的 PGOne,宣称使用领先的开源监控解决方案去增强指标监控功能,不过敲摸试了一下,效果也确实强大。

学习地址:https://github.com/prometheus

Influxdata,定位也是一个强大的实时监控系统。大体流程是:telegraf 收集监控的指标;然后交给 InfluxDB 进行存储;chronograf 负责从 InfluxDB 查询数据展示;kapacitor 负责监控报警。

学习地址:https://github.com/influxdata

Grafana,格拉法纳专业负责展示,提供漂亮的UI。不过她可以跟上面的普罗米修斯 Prometheus、InfluxDB 任性组合搭配,这倒是给我们提供一种扩展的可能性,我们只需要把要监控的指标放进 InfluxDB,再搭上 Grafana,那效果堪称完美!

学习地址:https://github.com/grafana

Skywalking,在上面基于 Tracing 监控的部分已经提到了,看来是能者多劳了,既能做调用链监控,又能基于指标进行监控。

学习地址:https://github.com/apache/skywalking

Elastic,估计很多人都听说过它旗下的 ELK,也就是 ElasticSearch + Logstash + Kibana 的组合。由于后来推出了一系列的专门用于采集数据的 Beats,造就了无限的可能性,当然完成 Metrics 指标采集监控也不在话下。

学习地址:https://www.elastic.co/cn/products/infrastructure-monitoring

肆意贴一张 Grafana 的效果图,看看你是否钟爱这一款?

3. 基于 Logging 的监控

基于 Logging 的监控,说白了也就是日志监控。

我们都知道,在微服务盛行的今天,服务散落部署在各个节点,导致排查定位问题需要连续切换 N 台机器,操作相当繁琐,不知道你有没有同感。如果你也有此同感,不妨了解了解下面的技术轮子。

日志监控的整体设计思路大多为:日志采集、日志存储、日志分析及报警,如果日志量再大点,那就来一个对列(kafka、redis、RabbitMQ等)作为缓冲

Elastic,在上面基于指标监控的部分已经提到了它,其实由于采集数据的 Beats 下有一款 FileBeat 专门采集日志文件,然后把采集的日志存储到 ElasticSearch,接下来用 Kibana 进行分析展示,这样一套轮子组合让你查询日志不再难(小声的说一下,貌似它也支持 APM 应用性能监控,三分天下而它是交汇的覆盖区域)。

入门地址:https://www.elastic.co/cn/products/log-monitoring

Graylog,一个集日志归集、分析、展现和预警工具,而且是基于 Java 开发,你心不心动?有没有想跃跃欲试?

入门地址:https://www.graylog.org

Rsyslog,一款用于Linux系统以通过TCP/UDP协议转发或接收日志消息的开源工具。

入门地址:https://www.rsyslog.com

Flume,一款用 Java 开发的采集 agent,让 Java 猿二次包装开发不是问题。

入门地址:http://flume.apache.org/

4. 多说两句

说了这么多,轮子千万款,感觉总有一款适合你,或许有了轮子的助力,会让你事半功倍,腾出更多时间冲咖啡!

不过话又说回来,纸上得来终觉浅,绝知此事要躬行;纵然轮子千万款,唯有实践才是硬道理!

您可能感兴趣的与本文相关的镜像

FLUX.1-dev

FLUX.1-dev

图片生成
FLUX

FLUX.1-dev 是一个由 Black Forest Labs 创立的开源 AI 图像生成模型版本,它以其高质量和类似照片的真实感而闻名,并且比其他模型更有效率

<think>我们正在讨论路由配置中的metric(度量值)。根据引用内容,metric是路由选择过程中的一个重要参数,用于在到达同一目的地的多条路径中进行选择。以下是对metric的详细介绍: ### 一、Metric的定义和作用 1. **基本概念** Metric(度量值)是路由协议为每条路由分配的一个数值,用于**衡量路径的优劣**。当存在多条通往同一目的网络的路由时,路由器会选择metric最小的路径[^2]。 2. **核心作用** - **路径选择**:在静态路由或动态路由协议中,metric是路径优先级的量化指标 - **负载均衡**:当多条路径metric值相同时,路由器可能进行负载均衡(分流数据包)[^1] --- ### 二、Metric的计算依据 不同路由协议使用不同的metric计算方式: | 路由协议 | Metric计算依据 | 示例值范围 | |----------|-----------------------------------|-----------------| | RIP | 跳数(经过的路由器数量) | 1-15(最大15跳) | | OSPF | 带宽(Cost=参考带宽/接口带宽) | 1-65535 | | EIGRP | 复合值(带宽、延迟、可靠性、负载等)| 自定义 | | BGP | 路径属性(AS路径长度等) | 0-65535 | > ⚠️ 注意:**静态路由的metric可手动指定**(如 `ip route 192.168.1.0 255.255.255.0 10.0.0.1 metric 50`) --- ### 三、Metric与AD(管理距离)的关系 1. **AD的作用** 管理距离(Administrative Distance)用于**区分不同路由来源的可信度**,值越小优先级越高[^1]: | 路由来源 | 默认AD值 | |----------------|---------| | 直连接口 | 0 | | 静态路由 | 1 | | EIGRP汇总路由 | 5 | | eBGP | 20 | | OSPF | 110 | | RIP | 120 | | 不可信路由 | 255 | 2. **选路优先级规则**: ```mermaid graph LR A[收到去往同一网络的路由] --> B{比较AD值} B -->|AD不同| C[选择AD最小的路由] B -->|AD相同| D[比较Metric值] D -->|Metric不同| E[选择Metric最小的路由] D -->|Metric相同| F[进行负载均衡] ``` --- ### 四、Metric的配置示例 #### 1. Linux中添加带metric的默认路由 ```bash # 使用iproute2工具(推荐) ip route add default via 192.168.1.1 dev eth0 metric 100 # 传统route命令 route add default gw 192.168.1.1 dev eth0 metric 100 ``` #### 2. Windows中修改路由metric ```powershell # 查看接口索引 Get-NetIPInterface # 修改默认网关metric Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 50 ``` #### 3. Cisco路由器静态路由配置 ```cisco ip route 192.168.5.0 255.255.255.0 10.1.1.1 50 ! metric=50 ``` --- ### 五、Metric的优化实践 1. **多网卡优先级控制** - 有线网络:设置较小metric(如50) - 无线网络:设置较大metric(如100) ```bash # 有线网卡eth0 ip route add default via 192.168.1.1 dev eth0 metric 50 # 无线网卡wlan0 ip route add default via 192.168.1.1 dev wlan0 metric 100 ``` 2. **故障切换机制** 当主路由(metric小)失效时,系统自动切换到备用路由(metric大)[^3]。 --- ### 六、常见问题排查 #### 1. 查看路由表及metric值 ```bash # Linux(iproute2) ip route show # 输出示例:default via 192.168.1.1 dev eth0 metric 100 # Windows route print -4 ``` #### 2. 修改现有路由的metric ```bash # Linux ip route change default via 192.168.1.1 dev eth0 metric 200 ``` --- > 📌 **关键总结**: > - Metric决定**同源路由的路径优先级** > - 与AD协同工作:AD选路由来源,Metric选具体路径 > - 配置原则:关键业务路径设置更小metric §§相关问题§§ 1. 如何通过路由metric实现网络故障自动切换? 2. OSPF协议中的cost是如何计算的? 3. 在多协议环境中AD如何影响路由选择? 4. 负载均衡场景下metric如何配置? : 路由表结构与转发原理 [^2]: Metric的作用与修改方法 [^3]: 路由器工作原理与多路径管理 </think> ### 路由配置中 Metric 的详细解析 Metric(度量值)是路由表中决定**路径优先级**的关键参数,用于在通往同一目标网络的多条路径中选择最优路由[^2]。以下是核心要点: #### 一、Metric 的本质作用 1. **路径决策依据** 当路由器发现多条通往同一目标网络的路由时,会优先选择 **Metric 值最小的路径** $$ \text{优选路径} = \min(\text{Metric}_1, \text{Metric}_2, ..., \text{Metric}_n) $$ 示例: ``` 目标网络:192.168.1.0/24 路径1:Metric=10(优先选择) 路径2:Metric=20 ``` 2. **负载均衡触发条件** 当多条路径 Metric **值相同时**,路由器会启用负载均衡,将流量分散到多条路径[^1]。 --- #### 二、Metric 值的计算依据 不同路由协议使用不同的 Metric 计算方式: | 路由协议 | Metric 计算依据 | 特点说明 | |----------|-----------------------------------|----------------------------| | RIP | 跳数(Hop Count) | 每经过一个路由器+1,最大15跳 | | OSPF | Cost(基于带宽) | Cost = 参考带宽/实际带宽 | | EIGRP | 复合值(带宽、延迟、可靠性、负载) | 算法:$ \text{Metric} = [\text{K1} \times \text{带宽} + ...] $ | | BGP | 路径属性(AS_PATH 长度等) | 多用于跨自治系统路由 | | 静态路由 | 手动指定 | 管理员直接设置固定值 | > 📌 **关键公式**:OSPF 的 Cost 计算 > $$ \text{Cost} = \frac{\text{Reference Bandwidth}}{\text{Interface Bandwidth}} $$ > (参考带宽通常为 100 Mbps) --- #### 三、Metric 与 AD(管理距离)的关系 两者协同工作但作用不同: | 参数 | 作用范围 | 优先级决策逻辑 | 值域 | |---------|-------------------------|----------------------------|-----------| | AD | **不同路由来源**之间 | 先比较 AD,值小者优先 | 0-255(直连=0,静态=1) | | Metric | **同一路由来源**的多条路径 | AD 相同时,比较 Metric | 协议相关 | **选路流程**: ```mermaid graph TD A[到达同一目标的多条路径] --> B{AD 是否相同?} B -->|是| C[选择 Metric 最小的路径] B -->|否| D[选择 AD 最小的路径] ``` --- #### 四、Metric 的配置与查看 ##### 1. Linux 系统操作 ```bash # 添加带 Metric 的静态路由 ip route add 192.168.2.0/24 via 10.0.0.1 dev eth0 metric 50 # 修改现有路由 Metric ip route change default via 192.168.1.1 dev eth0 metric 100 # 查看路由表(显示 Metric) ip route show # 输出示例:default via 192.168.1.1 dev eth0 metric 100 ``` ##### 2. Windows 系统操作 ```powershell # 查看路由表 route print # 添加带 Metric 的路由 route add 192.168.2.0 mask 255.255.255.0 10.0.0.1 metric 50 ``` --- #### 五、典型应用场景 1. **多网关负载均衡** ```bash # 两条等值默认路由 ip route add default via 192.168.1.1 metric 100 ip route add default via 192.168.2.1 metric 100 ``` ✅ 流量将自动分流到两个网关 2. **主备链路切换** ```bash # 主链路(低 Metric) ip route add default via 192.168.1.1 metric 50 # 备用链路(高 Metric) ip route add default via 10.0.0.1 metric 200 ``` ✅ 主链路故障时自动切换到备用链路 3. **服务质量分级** 对 VoIP 流量配置低 Metric 路径,确保低延迟。 --- #### 六、Metric 优化建议 1. **设计原则** - 关键业务路径设置更小 Metric - 避免不同路径 Metric 值随意设置导致非预期选路 - 动态路由协议优先使用协议自动计算的 Metric 2. **故障排查命令** ```bash # 显示详细路由信息(含 Metric) ip -d route show cache # 跟踪选路过程 ip route get 8.8.8.8 ``` > ⚠️ **注意**:Metric 仅在**相同协议和相同AD值**的路由间比较时才生效[^2]。 --- ### 总结对比表 | 特性 | Metric | AD(管理距离) | |---------------------|------------------------------------|-----------------------------| | **作用目标** | 同一来源的多条路径 | 不同来源的路由 | | **决策优先级** | 第二优先级(AD相同时生效) | 第一优先级 | | **典型值范围** | RIP:1-15, OSPF:1-65535 | 0-255(0最可信) | | **是否可手动修改** | 是(静态路由/接口Metric) | 是 | | **负载均衡触发条件**| 多条路径Metric相等 | 不直接参与负载均衡决策 |
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值