在去年的时候, 我们的账单情况是这样子的, 就是单月的那个费用最高的时候, 居然能够达到三万多块钱这个数额。
这个数字被展示出来的当口, 那位掌权人的面色一下子就变得难看起来了。现世间的可观测性这块技术板块呢, 是完全没办法说舍弃就舍弃掉的------因为线上的所有异常状况, 全都必须要依托它所具备的能力来找到问题的源头究竟在哪里。
但是当前那个特定的计费体系, 真的是太容易让人产生想要放弃的念头了: 它是依据主机的数量来收取费用、也是依据其他维度来收取费用、还是根据日志数据的摄入量来收取费用、亦或是依照调用链路的跨度单元来进行收费, 这所有的每一项如果单独地拿出来看都不会花费很多钱。
可是把它们全部叠加在一起的话, 那就会变成一个难以承受的巨大的数字。只要流量的规模出现上升的情况, 所生成的账单金额, 就会跟着发生那种几何级别的速度进行猛烈的增长。
经过这一整个季度的反复折腾, 我们最终把这个系统更换成了我们自己搭建的版本。这样一来, 现在每个月的运行观测成本已经成功压低到了五六千元人民币左右, 这笔费用主要是用于支付数据存储以及那几台机器的相关开销, 综合计算下来, 总计节省下了将近两万元人民币。
为什么是
自建可观测，方案不止一个。最常见的是 + + Loki + Tempo 这套全家桶，、logs、 各管一摊，自己拼起来。
我们之前用的就是这套方案, 核心问题在于整体结构过于松散。
存在三个系统对应着三种不同的查询语言以及三个独立的界面设计, 导致在排查单个问题时, 技术人员不得不在各个组件之间频繁切换视图, 由于数据关联性较差, 当一个请求变得缓慢时, 操作人员必须先从追踪记录中手动提取相关标识信息, 然后再到日志存储部分进行搜索检索, 这种操作流程使得用户体验出现严重断裂。
其核心销售亮点在于实现了全部功能的一体化整合。在单一产品内部, 集成了追踪、日志检索与相关指标数据的完整闭环体系。从技术底层角度看, 这些功能的数据都存储在同一基础设施之上, 用户交互界面也是统一设计。
系统会自动将相关数据与日志关联起来, 这种操作体验更接近业界领先的平台那种「借助一个综合界面将所有问题串联起来」的处理逻辑, 这正是我们当前所追求的目标导向。
再说了, 这个东西生来就是吃的那个意思。
关键在于这一点, 不要对任何一个具体的厂商进行固定的绑定。
这一点我需要单独拿出来讲一讲, 因为它是我们在这次迁移工作里面找到的一个最大的隐藏的收获。
我们进行接入的时候, 应用在使用的层面上面所采取的所有的标准SDK以及相关的技术手段, 根本就没有用到任何由这家厂商自己提供的专有探针工具。这种状况带来的结果就是: 应用代码里面所埋下的监控点、以及系统里的相关配置参数, 从头到尾都是处于一种对各个不同的软件服务商都没有偏好的中立状态之下。
otel- 配置: 应用把数据发给 , 转发给。
:
otlp:
:
grpc:
: 0.0.0.0:4317
:
把这地方改一改的话啊, 就是能够让数据流向任何的一个支持 OTLP 协议这样一个接口的后端。
otlp/:
: -otel-:4317
tls:
: true
:
:
:
:
:
otlp/
:
:
:
otlp/
logs:
:
:
otlp/
这套配置真正有意义的一个地方, 就是到那个时刻, 如果发现它变得不好用了, 或者大家心里又想换回云服务的话, 那么用户只需要修改那一个部分的参数值, 至于说应用里的代码, 一行都不需要去改动。
因为我们之前之所以会被深深地套住, 挪都挪不动, 很大一部分的原因, 是因为我们当时埋点埋入的那些逻辑, 全部都是依赖该厂商提供的专有代理工具, 这样搞下来, 导致以后的迁移成本非常之高, 高到让人感觉完全不敢动手去操作这件事情。
这一次呢, 我们是老老实实吸取了教训, 学会了变聪明了一点儿, 那就是在技术选型上坚持用最基础的底线标准作为出发点。
账，得算全
省两万听着爽，但自建不是白嫖，账要算明白。
成本项
（云）
（自建）
软件/服务费
每月三万+
0（开源）
机器/存储
含在服务费里
每月约五六千
人力运维
几乎为零
需要做到人员与任务的对口匹配, 增加容量, 提升级别。
数据留存
越长越贵
自己进行存储的管控, 价格比较低廉。
最容易被忽略的点是关于人力运维的这个部分。你花钱的目的就是为了买省心, 出了问题有人负责兜底。在进行自建部署之后, 不管是存储容量进行扩充、系统保持长时间稳定、还是软件版本的升级迭代, 这些工作全都变成了需要你自己亲自动手去解决的问题。
我们单位之所以能够顺利推进这项工作, 关键是因为有一位同事原本就在技术层面非常熟悉相关领域, 如果缺乏这种内部人员的经验支撑, 那么这项工作在背后所产生出的隐性人力资源消耗, 完全有可能把原本打算通过自节约省下来的资金给直接抵消掉一大半。
数据量特别大的时候， 的存储和查询调优也得花心思。我们高峰期 trace 数据涨得猛，调采样率、调存储 TTL 折腾了一阵。
给个判断标准
要不要选择自己进行建设, 我想大家只需要看一个情况, 就是你的账单金额是不是高到让你感到心疼, 以及你有没有合适的人选能够承担起这套自建系统在日常运行和维护方面的工作。
因为那张账单的数额并不大, 而且团队里也没有人具备这方面的专业知识, 所以选择这种可以让人感到放心和省心的方案, 它的费用是属于值得支付的范畴的, 你们不应该为了节省一些微小的开支, 反而去消耗掉工程师们的宝贵工作时间。
但是就像是咱们这样的状况, 账单已经变成了财务部门每个月都要特意拿出来重点说明的一个很大的开销项目。又恰好有某个人能够完全掌控得住这些情况。那么这两万元的节省额度, 就让人觉得省得非常具有充分且正当的理由。