百度提交网站,建筑设计网站大全网站,wordpress信息分类主题,wordpress手机发布上一篇文章#xff0c;我们介绍了可观测性的三大支柱#xff1a;日志、指标和追踪#xff0c;并对业界常见开源方案做了横评对比。在接下来的我们继续学习可观测性监控的相关概念#xff0c;包括 监控指标、指标类型#xff0c;告警收敛与闭环#xff0c;时序库数据库等。…上一篇文章我们介绍了可观测性的三大支柱日志、指标和追踪并对业界常见开源方案做了横评对比。在接下来的我们继续学习可观测性监控的相关概念包括 监控指标、指标类型告警收敛与闭环时序库数据库等。
监控monitor从字面意义上理解就是对事物对象行为状态进行持续关注而这里所介绍的监控系统指的是持续针对系统运行及资源状态指标进行关注例如系统CPU使用率、内存占用等所以监控体系中最基础的是监控指标metric它是度量系统运行状态的手段作为一名运维通常围绕指标的采集、传输、存储、分析、可视化并通过相应规则进行告警通知等一系列流程。
0x01 监控指标
监控指标Monitoring Metrics是用于量化系统、应用或服务运行状态和性能的数据点帮助运维、开发或业务团队实时了解健康状态、发现问题并进行优化。它们是监控系统的核心要素通常以时间序列的形式存储和展示如折线图、仪表盘。
如何设计有效的监控指标 明确目标区分核心指标如SLA相关与辅助指标。 分层覆盖从硬件到业务逐层监控网络→应用→订单。 设定阈值定义正常/异常范围如CPU90%告警。 避免冗余平衡指标数量与存储成本。 动态调整随业务演进迭代监控策略。 不同的监控系统对于监控指标有不同的描述方式下述列举三种典型的方式 全局唯一字符串作为指标标识
例如某计算机CPU使用率指标可以表示为host.10.10.1.1.mem_used_percent此字符串中包含了实例类型实例信息以及指标名称。 # 如 Graphite 监控系统使用这种方式来标识监控指标的而 Collectd 监控数据采集器也支持这种方式。
{ name: host.10.10.1.1.mem_used_percent, points: [ { clock: 1662449136, value: 45.4 }, { clock: 1662449166, value: 43.2 }] }
虽然该方式可以很好地标识监控指标但是当实例数量较多时会导致监控系统存储大量的冗余数据并且由于缺少对维度信息的描述不便于进行多维度的聚合查询。 # 例如比如下面几条用于描述HTTP请求状态码的指标若想计算 service1 成功率则需要统计将状态码为200的请求数总和再除以 service1 的所有请求数总和提取数据也相对于麻烦。
myhost.service1.http_request.200.get myhost.service1.http_request.200.post myhost.service1.http_request.500.get myhost.service1.http_request.500.post 标签集的组合作为指标标识
例如推送给 OpenTSDB 的时序数据库的指标格式如下所示其中包含了度量名称、时间戳、指标值以及多个标签tags/labels信息每个标签都是keyvalue的格式多个标签之间使用空格分隔。。 mysql.bytes_received 1287333217 327810227706 schemafoo hostdb1
mysql.bytes_sent 1287333217 6604859181710 schemafoo hostdb1
mysql.bytes_received 1287333232 327812421706
schemafoo hostdb1
除了 OpenTSDB新时代的时序库大都引入了标签的概念比如 Prometheus、VictoriaMetrics 等业界主流的指标采集与存储系统在Prometheus中甚至认为指标名也是一种特殊的标签其标签 key 是__name__ 所以 Prometheus 仅仅使用标签集作为指标标识从Prometheus 的数据结构定义中就可以看出来。 # 如 Prometheus 监控系统使用这种方式来标识监控指标的。
cpu_usage{instance10.10.1.1, jobwebserver} 多度量集合作为指标标识
例如InfluxData公司有一款开源时序库 InfluxDB它支持多维度的度量集合作为指标标识在接收监控数据时写入时会将多个度量名称和标签集合作为一个整体进行存储。简单来说可分为4个部分measurement,tag_set field_set timestamp其中tag_set是可选的tag_set 与前面的measurement之间用逗号分隔其他各个部分之间都是用空格来分隔的。 若将上面 OpenTSDB 的指标示例换成InfluxDB的格式一行数据对应多个度量集合写法设计很精巧标签重复度低field越多的情况下它的优势越明显网络传输的时候可以节省更多带宽此文。 # 示例 mysql,schemafoo,hostdb1 bytes_received327810227706,bytes_sent6604859181710 1287333217000000000
最后大致对比一下三种指标标识方式的优缺点 指标标识 优点 缺点 全局局唯一字符串 简单 缺失维度信息不利于多维聚合计算与灵活赛选 标签集组合 灵活 稍显冗余 多度量集合 灵活、精巧、语义丰富 理解成本稍高
总得来说监控指标的概念非常重要它贯穿整个监控系统的各个环节它是系统可观测性的基石结合日志Logs和链路追踪Traces能构建完整的运维洞察体系提前预警问题减少故障恢复时间MTTR。 0x02 指标类型
不同监控系统的监控指标的类型多种多样每种类型都有其特定的用途和意义。例如在 80 年代 RRDtool它是一个环形数据库也是一个绘图引擎很多监控工具Cacti、MRTG、Zabbix都是使用 RRDtool 来存储或绘制监控趋势图的它提出了数据类型的概念即 GAUGE、COUNTER、DERIVE、DCOUNTER、DDERIVE、ABSOLUTE 等多种数据类型。
这里以目前主流的 Prometheus 监控系统为例进行讲解它支持四种基本的指标类型计数器Counters、计量器Gauges、直方图Histograms和摘要Summaries。 计数器Counters用于记录事件发生的次数它们通常单调递增不会重置为零。例如: HTTP请求数、错误发生次数等。 http_requests_total{methodGET} 1027 errors_total{typetimeout} 34 计量器Gauges用于测量当前值它们的值可以增加或减少通常关注的是当前时刻的值。例如当前内存使用量、CPU负载百分比等 memory_usage_bytes 52428800 cpu_load_percent 2.5 直方图Histograms用于测量和统计数据的分布情况包括最小值、最大值、平均值、中位数等统计信息常用于跟踪请求延迟、响应大小等数值的分布。其核心思想是将测量值分配到预先定义的桶(buckets)中每个桶记录小于等于该桶上限值的观测数量即客户端定义桶服务端计算分位数。 例如你在学校需要测量全班同学的身高然后需要统计多少人在150cm以下多少在150-160cm之间多少在160-170cm之间等你只需要测量一次即可将所有数据放入对应的桶中然后统计每个桶的数量即可。使用 Histogram 作为统计工具可以用较小的代价计算一个大概值虽然准确精度不高但是应用在监控中足矣。例如监控延迟数据计算90分位、99分位的值 http_request_duration_seconds_bucket{le0.1} 125 // 有125个请求响应时间≤0.1秒 http_request_duration_seconds_bucket{le0.5} 324 // 有324个请求响应时间≤0.5秒 http_request_duration_seconds_bucket{le1} 500 http_request_duration_seconds_bucket{le2.5} 750 http_request_duration_seconds_bucket{le5} 900 http_request_duration_seconds_bucket{le10} 1000 http_request_duration_seconds_bucket{leInf} 1000 // 总请求数 http_request_duration_seconds_sum 1234.5 // 所有响应时间总和 http_request_duration_seconds_count 1000 // 总请求数(与Inf桶相同) // 查询示例 http_request_duration_seconds_bucket{le1} // 有多少请求响应时间小于1秒 histogram_quantile(0.5, rate(http_request_duration_seconds_bucket[5m])) // 5分钟内的中位数(第50百分位)延迟是多少 注所谓的分位值就是把一批数据从小到大排序然后取X%位置的数据90分位就是指样本数据第90%位置的值。 前面可知Histograms 不需要将所有请求的延迟数据全部拿到再排序虽然性能有了巨大的提升但是要同时计算成千上万个接口的分位值延迟数据还是非常耗费资源的甚至会造成服务端OOM于是 Summary 类型便孕育而生。 摘要Summaries类似于直方图区别是客户端直接计算分位数服务端只接收结果通常用于存储较小的样本集它们提供了总和、计数和分位数等统计信息。 http_request_duration_seconds_sum 1024 http_request_duration_seconds_count 128 到这里我们就把 Prometheus 的四种数据类型介绍完了再看看 Prometheus 数据传输结构即 TimeSeries 的 Proto 结构看看能否发现一些问题 问题Sample.value 仅为 double 类型无法直接支持其他类型如直方图、分位数、字符串标签值需转为数值不过虽然 Proto 的简洁性牺牲了存储效率但提高了编解码速度适合网络传输。 并且 TimeSeries 数据结构中并没有包含类型信息从时序数据库存储角度触发它只需要知道指标标识、时间戳、值就足够了而后续使用 PromQL 进行查询时不同函数对指标值的处理方式不同例如rate、increase 函数传入Counter 类型的指标而 histogram_quantile 函数传入 Histogram 类型指标带有 le 标签的 bucket 指标。 0x03 时序数据库
描述在了解监控系统中指标采集和传输后接下来就是如何存储采集的指标数据众所周知监控指标数据是周期 性采集的每条指标数据都关联一个时间戳称为时序数据通过使用时序数据库库存储下面我们就来 看看时序库的概念以及当下主流时序库的优缺点。 什么是时序数据?
描述时序数据是一种特殊类型的数据它按照时间顺序记录信息。简单来说就是带有时间戳的数据点序列其核心特征是每个数据点都有明确的时间标记、数据按时间先后排列、通常是持续不断地产生虽然可能有间隔流式发送给服务端、一旦记录历史数据不会改变
例如生活中每天各时刻测量的体温值、每分钟的股价变化以及一天中每小时的气温记录以及 Nginx 访问日志数据等都属于时序数据的范畴。 # 体温记录每天测量的体温值
2023-05-01 08:00: 36.5°C
2023-05-01 12:00: 36.7°C
2023-05-01 18:00: 36.9°C
# 股票价格每分钟的股价变化
10:00: $100.2
10:01: $100.5
10:02: $100.1
# 天气数据每小时的气温记录
00:00: 22°C
01:00: 21°C
02:00: 20°C
# 监控数据每分钟的CPU使用率/以及内存使用量 CPU使用率
[08:00: 30%, 08:01: 32%, 08:02: 28%] 什么是时序数据库?
描述时序数据库Time Series DatabaseTSDB是一种专门用于存储和查询时间序列数据时序数据的数据库系统。它主要用于处理带有时间戳的时间序列数据常用于监控数据、日志分析、物联网(IoT)设备数据等场景。
目前我们常见的数据库中大家应该知道 MySQL、Oracle 是关系型数据库, Redis 是 KV 数据库 mongoDB 是文档型数据库而 InfluxDB、VictoriaMetrics、PrometheusTSDB 等都是时序数据库。
例如Prometheus 时序数据库其时序数据格式为 指标名称{标签集} 值 时间戳存储的数据如下所示 http_requests_total{methodGET, status200} 1500 1625097600 cpu_usage{hostserver1} 42.5 1625097600 时序数据库核心特点 高效写入支持高频率、高并发的数据写入满足每秒数百万数据点的写入需求。 时间索引优化数据按时间维度进行组织和索引加速时间范围查询。 高压缩率采用专用压缩算法如Delta编码、Gorilla压缩等存储效率比传统关系型数据库高5-10倍。 冷热数据分离自动区分热数据近期频繁访问和冷数据历史归档数据。 聚合分析能力支持基于时间窗口的预聚合和降采样查询。 主流时序数据库介绍 1.InfluxDB 是一款开源的时序数据库Time Series Database, TSDB专门用于高效处理时间序列数据由 InfluxData 公司开发采用 Go 语言编写具有高性能写入、高效存储和实时查询能力。 特点开源分布式时序数据库采用自定义TSM存储引擎支持高效数据压缩和类SQL查询语言 优势社区活跃度高写入性能优异支持多种数据摄入协议 局限分布式版本未开源, 高基数High Cardinality问题企业版价格较高。 适用场景DevOps监控、IoT传感器数据、金融数据实时分析 官网地址: https://www.influxdata.com 2.VictoriaMetricsVM 是一款开源的高性能时间序列数据库和监控解决方案专为处理大规模时序数据而设计。凭借其高性能、低资源消耗和良好的扩展性已成为时序数据库领域的重要选择特别适合需要处理大规模监控指标和传感器数据的场景。推荐 特点高性能架构高效数据压缩兼容Prometheus生态灵活部署模式。 优势查询处理卓越性能表现资源效率高操作简洁灵活的采集能力。 局限可视化功能较弱告警功能不完善APM支持有限 适用场景基础设施监控云原生环境监控大规模IoT数据处理工业监控系统 官网地址https://victoriametrics.com 3.Prometheus (普罗米修斯)是一款开源的监控报警时间序列数据库的工具由 SoundCloud 开发并维护。它专注于收集、存储和查询时间序列数据广泛应用于系统和服务监控领域。 特点开源监控系统和时序数据库专注于指标数据的采集、存储和告警 优势丰富的查询语言(PromQL)集成监控和可视化功能维护简单 局限聚合分析能力较弱不适合大容量存储 适用场景系统和服务监控云原生环境监控 官网地址: https://prometheus.io 4.TimescaleDB 是一款开源的时序数据库它基于 PostgreSQL 的扩展专门为时间序列数据优化。其利用了 PostgreSQL 的强大功能和 SQL 支持同时提供了针对时间序列数据的特定优化和功能增强。 特点基于PostgreSQL的时序数据库扩展支持完整SQL功能 优势兼容PostgreSQL生态支持复杂查询和事务透明时间分区 局限压缩比相对较低(约4:1) 适用场景需要SQL复杂查询的时序应用 官网地址TimescaleDB Community | Timescale 5.GreptimeDB 是一个云原生、实时的可观测数据库,专为存储和处理指标、日志和追踪数据而设计。它可在任意规模下提供快速且经济高效的洞察,并实现从边缘到云的无缝数据集成 特点云原生分布式时序数据库支持SQL/PromQL/向量搜索统一处理指标/日志/事件Rust编写高性能存储引擎 优势50倍存储成本优化对象存储列式压缩边云协同部署灵活多协议兼容MySQL/InfluxDB等智能索引提升查询效率 局限新生态工具链待完善分布式版本成熟度需验证 适用场景IoT监控、云服务指标分析、AI向量搜索如图片嵌入、车联网边云数据协同 官网地址快速、高效、用于实时可观测的统一数据库 | Greptime 最后大家可在 DB-Engines 时序库的流行度排序 网站上了解到当下哪些时序库比较流行市场使用占比多并根据具体应用场景进行选型。 时序数据库国内发展趋势
2025年国内时序数据库市场需求持续增长主要受物联网和工业互联网发展推动。中国国家发改委已将大型高性能时序数据库系统列入鼓励类项目。在技术方面时序数据库正朝着更高压缩率、更强分布式能力和更智能的运维方向发展。 0x04 监控告警
描述在监控系统中有两个核心能力一个是监控一个是告警告警是非常重要的一环它能够在系统出现异常时及时通过邮件、企业微信、钉钉自定义webhook通知相关人员进行处理从而避免潜在的系统故障以及快速恢复异常基础设施或应用减少故障持续时间。
但在企业实践中告警事件层面的话题是所有监控系统都需要处理的并且告警系统往往存在一些问题例如告警风暴、误报率高、冗余度高、处理不及时等这些问题不仅会增加运维人员的工作负担还会导致系统故障的响应时间延长。因此如何构建一个高效、可靠的监控和告警体系至关重要。 这里不得不提到告警中几个关键概念即告警规则告警通道告警收敛, 告警抑制, 告警静默,告警闭环它们是在监控告警中常常遇到的术语下面我们来一一解读。 告警规则定义了触发告警的条件并可根据实践影响设置告警等级例如主机CPU使用率超过80%或者磁盘空间低于10%。
告警通道用于发送告警通知的渠道例如邮件、短信、企业微信、钉钉等。
告警收敛指将多个事件聚合成告警聚合时间维度、策略维度、监控对象维度等不同维度进行分组Grouping例如 如果100台机器同时报失联就可以合并成一条告警通知减少打扰。
告警抑制高级别告警触发后自动抑制低级别相关告警例如 集群宕机时忽略其下属服务的告警。
告警静默通过标签匹配临时屏蔽特定告警例如 维护期间屏蔽预期内的告警。
告警闭环: 指从告警产生到问题解决再到告警关闭的完整流程包括确认、处理和恢复例如 oncall 中排班人员认领告警并反馈解决结果。 主流监控告警产品
目前开源和商业监控告警产品众多可以选择一个专门的产品和多种监控系统对接专注处理告警事件的组合架构此处我们来看看目前几个主流的监控告警产品 1.Prometheus Alertmanager: Prometheus 告警处理的核心组件负责接收、处理和路由来自 Prometheus Server 的告警信息支持邮件、Slack、Webhook 等多种通知方式。 特点开源、轻量级易于集成支持告警分组Grouping、抑制Inhibition、静默Silences以及多通道通知 优势与 Prometheus 深度集成支持多实例部署高可用支持自定义告警内容模板灵活的告警管理 局限配置复杂度高缺乏多租户支持历史告警功能薄弱扩展性依赖插件自定义webhook 文档地址Alertmanager | Prometheus 2.Grafana Alerting: 是 Grafana 4.0 版本引入的告警模块允许用户直接在 Grafana 中定义、管理和发送告警无需依赖外部组件如 Prometheus Alertmanager但仍支持与其集成。 特点开箱即用、可视化告警规则Alert Rules配置通知策略Notification Policies告警状态管理 优势可视化配置、多数据源支持、灵活的告警分组减少通知风暴、告警与仪表盘深度集成可视化数据 局限告警规则灵活性较低多维告警管理复杂大量实例时依赖 Grafana 渲染历史告警功能较弱部分高级功能需企业版 官网地址Create and unify alerts at scale | Grafana Alerting 3.夜莺-Nightingale: 是一款国产开源的 All-in-One 云原生监控系统集成了数据采集、可视化、告警管理、日志分析等功能旨在替代传统的 Prometheus Alertmanager Grafana 组合方案提供更统一、易用的监控体验。(推荐) 特点支持多数据源支持基于 PromQL、LogQL 等查询语言配置告警规则支持 多通道告警通知支持 告警订阅按团队或业务划分告警接收人支持 边缘部署n9e-edge 模块适用于多机房、网络割裂场景。 优势开箱即用降低运维复杂度支持 级别抑制、生效时间、告警屏蔽减少告警风暴国产化 社区支持。 局限有学习成本部署需依赖 MySQL Redis可视化能力弱于 Grafana部分高级功能需商业版 FlashDuty (做告警聚合降噪、排班OnCall)。 官网地址夜莺监控 - 快猫星云Flashcat 此外,国外还有一些优秀的 Bigpanda、Pagerduty 的产品此处不一一列举介绍有兴趣的朋友可自行 Google另外企业监控告警实践作者将在后续专栏中更新敬请期待。 此篇我们聊了很多监控方面的基础知识现在我们来互动一下你能否用一句话或者一个词来证明你是运维万精油让我们一起看看有多少同道中人。也欢迎你把今天的内容分享给你身边的朋友邀他一起学习下一讲再见不见不散
