com后缀的网站,郑州个人做网站汉狮,西安网络技术有限公司,制作企业官网哪家好现代服务架构常常谈及三个性#xff1a; 弹性#xff0c;韧性#xff0c;可观测性。今天且按下其他两性不表#xff0c;着重聊一聊可观测性。本文就几个主题对可观测性展开讨论#xff1a;
可观测性是什么可观测性是必须的吗企业的可观测性落地 可观测性理念
可观测性是…现代服务架构常常谈及三个性 弹性韧性可观测性。今天且按下其他两性不表着重聊一聊可观测性。本文就几个主题对可观测性展开讨论
可观测性是什么可观测性是必须的吗企业的可观测性落地 可观测性理念
可观测性是什么
从概念上讲可观测性的源自于控制论即通过获取系统运行数据以推测系统运行状况进而推断系统状态进行系统诊断调整的过程和能力。如果要说清楚什么是可观测性可以与其前辈监控进行比较。
可观测性描述的是系统而非这个支持可观测性的平台或机制。这是迥异于传统监控的。传统的监控是由外而内的一个过程传统的企业组织架构常常会有相对独立的研发部门和运维部门。研发部门负责开发运维部门负责实施稳定性由运维部门负责自然监控也由运维团队设置这导致一个问题研发部门开发设计的时候缺少对线上状态监控的考虑导致运维团队缺乏有效的监控机制来监控系统只能做一些系统表征的识别判断进程端口是否存活cpu内存是否过载等等但伴随着越来越复杂的软件架构特别是微服务架构的场景简单的表征无法有效的反馈系统状态传统监控力所不逮。而可观测性是个由内向外的过程其不仅仅是一种观测机制更强调是一种开发实施观念即数据采集是由开发部门要保证的埋点是常态研发过程要保证关键数据应采尽采而运维部门只是这些数据的使用者甚至进一步弱化部门之间的隔阂运维只提供可观测性的平台和工具整个可观测性的采集分析稳定性的保证都是由研发部门负责的运维团队逐步进化为SRE。传统监控缺乏对系统的诊断能力其往往只能观察到问题的点而无法将这些表象的问题关联更遑论进行深入的问题分析。常常是一个故障导致告警风暴关键告警信息隐藏在次生的告警中。可观测性依赖常规的可观测性三要素Trace, Log, Metric进行信息关联支持多维度的关联查询甚至进行线上Profiling的采集进行实时的系统状态分析。传统监控是由故障驱动的缺乏预见性。监控所监控的对象往往是基于经验的经验之外的场景只能由故障驱动补全。今日故障添加对inode数量的监控明日故障添加对socket个数的监控。而为了保证稳定性很多监控是基于预警设计的阈值设置的很保守导致经常性的触发。研发和运维疲于日常的告警排查最终又没有发现什么问题常常上演狼来了的故事。而可观测性的实施角度不再是某个指标某个特征。而是通过指定的可观测性数据的采集汇总。对这些数据分析进而判断是否真的有问题是否应该报警。对于预见性的告警通过定义SLO来识别是否是真的狼来了。监控是运行在系统层面监控目标往往是服务接口链路等是站在开发和运维的角度来观测分析。而可观测性强调监测业务通过业务指标判断应用是否受损。
这里再系统的总结一下什么是可观测性通过采集运行中的系统数据包括TraceLogMetric乃至EventDEMDigital Experience Monitoring信息进行系统分析和诊断。其数据通过多维度的关联以支持多种角度的展示和分析。空间上多维度数据关联纵向上将主机容器进程等信息关联横向上通过Trace进行调用关系关联。分析问题常常是通过受损的业务指标下钻系统组件再通过各种关联定位问题根因。
可观测性是必须的吗
软件行业没有银弹每钟技术都有其适用的场景也会带来新的问题和挑战。如果一个系统结构简单部署规模小可能一个简单的监控就够用了。但如果期望稳定性达到三个9,四个9乃至五个9那么可能就需要应用可观测性来进行更高的稳定性保证。尤其是当处于一个存量的市场竞争环境中产品形态上又与对手没有拉开身位的优势拼的就是产品的质量和稳定性。当系统复杂到一定程度的时候其线上会出现故障不是偶然而是必然这就必须要有一种机制来进行线上的系统监控和实时诊断甚至能够进行运营分析那就不得不使用可观测性即使其会引入额外的开发复杂度增加额外的开发周期。
稳定性保证是一个复杂的系统工程投入很多的时候不能像业务产品一样获取明显的收益效果投入减少又可能会导致故障而产生巨大影响。当一个企业增长到一定程度其不光对内有增长盈利的诉求在资本市场上有市值管理的诉求在社会上也有稳定可靠的民众诉求。我们已经看到过很多因为故障而导致市值暴跌冲上热搜讨全民论的情况其对一个企业的影响不可谓不大。而可观测性是进行系统稳定性保障工作的重要工具。如何进行可观测性评估我觉得可以通过以下几个方面考虑
系统复杂性: 如果系统是分布式的或由多个微服务组成具备了一定的复杂性那么可观测性是非常重要的因为它可以帮助理解系统的整体行为和各个组件之间的交互。业务需求: 如果业务对系统的可靠性和性能有高要求即所谓的几个9那么可观测性可以帮助快速识别和解决问题减少停机时间。故障排查: 在系统出现问题时是否能够快速定位和解决问题是否还需要登陆线上机器定位可观测性可以提供详细的诊断信息帮助工程师更快地找到问题根源。性能优化: 是否需要持续监控和优化系统性能全链路压测耗时长效果差可观测性可以提供实时的性能数据帮助识别瓶颈和优化资源使用。用户体验: 用户体验是否受到系统性能的影响可观测性对数字体验的监控可以帮助了解用户交互的各个方面确保提供最佳的用户体验。合规性和安全性: 是否需要满足特定的合规性要求或安全标准可观测性可以帮助记录和审计系统活动确保合规性。团队能力: 团队是否具备实施和维护可观测性系统的能力需要考虑团队的技术水平和资源。成本效益: 实施可观测性是否具有成本效益需要评估可观测性带来的价值与其实施和维护成本之间的平衡。
简而言之一句话有条件上没有条件创造条件也要上。
企业的可观测性落地
一个标准的可观测性平台主要解决几个问题
数据的收集采集和处理数据的存储持久化落盘数据的分析展示和告警等
所以进一步可以拆分为几个组件
数据采集端常见的技术包括SDK, Agent, 探针等开源组件包括老派的zabbix, 新派的Prometheus exporter等数据处理将采集到的数据进行清洗转换和数据湖的数据处理过程有些类似进行标准化和非标准化的数据转换。关键数据的聚合计算告警生成等常见的技术Apache FlinkSpark进行流式处理Kafka进行数据传输等数据存储常见的有列式存储的OLAP数据库ClickHouse 、 Doris等也有时序数据库Prometheu 、 VictoriaMetrics等。也可能需要图数据库存储关联关系包括: Neo4j 、 Amazon Neptune等数据可视化分析将存储的结构化数据通过图表直观的展示分析。典型的开源组件Grafana。一般将报警策略和通知也会相应的展示在页面中。AI分析运行中的系统的状态时刻的处于动态变化当中故障的分析定位告警的识别跟进靠人力依然不够及时这就需要有AI帮助定位识别根因进一步缩短故障实现AIOps是大模型带给运维领域的变化。
一个企业是否要自建可观测性平台呢通过上述的几个模块我们可以知道一个可观测性平台已经是一个复杂的项目如果企业有能力自建可观测平台自然是一个最好的选择因为通过第一节中什么是可观测性的讨论我们已经知道要获取可观测性需要很大程度的入侵现有代码业务方需要埋点需要引入SDK. 需要输出特征日志。当然这也和当前的系统情况有关
全量的采购三方服务使用其提供的SDK, Agent进行数据采集。有一定的开发适配工作但平台适配性好接入过程比较顺滑。缺点是会与三方平台绑定。不一定需要大而全的采用外部系统如果系统已经进行了数据采集工作可以将数据对接三方平台因为可观测的复杂度大多是在平台的数据处理存储分析上而非数据的采集上。这要求系统使用标准的可观测性数据格式包括OpenMetric, Opentelemetry等协议标准与平台解耦降低接入成本就使用现在的数据场景要求外部平台非侵入性的进行数据采集。一定程度上也能做到但数据的利用程度会降低。举一个简单的例子多维度数据如何进行关联最直观的是通过Trace ID进行关联但非入侵的情况无法有效的插入和追踪Trace ID,如果有过线程切换调用链很难再被有效追踪。这就需要其他的关联信息比如实体关联所有的数据都要关联到实体上然后通过实体的关系确定数据的关联关系。时间关联数据中的时间戳判断发生在同一时刻的数据具有关联关系等。其准确度都会有所降低。
不论是自研还是采购可观测性平台都与其他系统有显著区别其与开发的绑定之深导致不论哪个选择都影响颇大。
可观测性理念
前面提到了可观测性选型实现等方面希望能让大家对可观测性有了一个初步的认识。最后一节再讨论下可观测性为什么是一种理念其为研发流程稳定性工程带来了什么变化。
1. 数据驱动决策可观测性强调通过数据来驱动系统设计、开发、运维和优化通过实时数据分析来做出的业务和技术决策即所谓数据决策。
2. 全生命周期集成可观测性应从开发阶段开始考虑并贯穿于测试、部署和运维在设计阶段就考虑如何采集和利用数据以便在系统上线后能够有效监控和诊断。
3. 跨职能协作打破开发和运维之间的壁垒促进DevOps文化研发团队负责数据埋点和采集负责数据的使用和分析运维团队提供平台。
4. 持续改进通过可观测性数据不断评估和优化系统性能和稳定性定期回顾和调整监控策略和告警阈值以适应系统变化。
5. 用户体验优先通过监控用户交互数据来确保最佳用户体验识别和解决影响用户体验的问题。
6. 透明性和可见性: 提供系统内部状态的透明视图帮助团队快速理解和响应问题, 确保所有相关人员都能访问和理解可观测性数据。
7. 平台将数据汇总最终的数据为不同角色展示为不同的表达 a. 业务负责人关心业务指标的健康状况比如电商的推广的成单量出行应用的撮合成单量等系统中的某个服务是否健康其并不关心 b. 具体服务的负责人则关心自己负责服务的健康情况其TPS, 查询耗时等等状况 c. 运维负责人则关系资源的使用情况, 系统是否过载等
8. 通过SLO识别告警是否有效只有影响到SLO的告警是紧迫告警避免狼来了的情况, 业务团队为SLO负责。通过SLO定义SLA量化团队的稳定性程度。
可观测性不仅仅是一种技术手段更是一种稳定性保证的实施理念其在CNCF的landspace中独占一席可见其重要程度。落地引进的过程对团队的组织架构系统的落地实施都会产生深远的影响。
