22 存储成本：如何推算日志中心的实现成本？ 你好，我是徐长龙。

前面我们比较过很多技术，细心的你应该发现了，比较时我们常常会考虑实现成本这一项。这是因为技术选型上的“斤斤计较”，能够帮我们省下真金白银。那么你是否系统思考过，到底怎么计算成本呢？

这节课，我会结合日志中心的例子带你计算成本。

之所以选日志中心，主要有这两方面的考虑：一方面是因为它重要且通用，作为系统监控的核心组件，几乎所有系统监控和故障排查都依赖日志中心，大部分的系统都用得上；另一方面日志中心是成本很高的项目，计算也比较复杂，如果你跟着我把课程里的例子拿下了，以后用类似思路去计算其他组件也会容易很多。

根据流量推算存储容量及投入成本

在互联网服务中，最大的变数就在用户流量上。相比普通的服务，高并发的系统需要同时服务的在线人数会更多，所以对这类系统做容量设计时，我们就需要根据用户请求量和同时在线人数，来推算系统硬件需要投入多少成本。

很多系统在初期会用云服务实现日志中心，但核心接口流量超过10W QPS后，很多公司就会考虑自建机房去实现，甚至后期还会持续改进日志中心，自己制作一些个性化的服务。

其实，这些优化和实现本质上都和成本息息相关。这么说你可能不太理解，所以我们结合例子，实际算算一个网站的日志中心存储容量和成本要怎么计算。

通常来说，一个高并发网站高峰期核心API的QPS在30W左右，我们按每天8个小时来计算，并且假定每次核心接口请求都会产生1KB日志，这样的话每天的请求量和每天的日志数据量就可以这样计算：

  • 每天请求量=3600秒 X 8 小时 X 300000 QPS = 8 640 000 000次请求/天 = 86亿次请求/天
  • 每天日志数据量：8 640 000 000 X 1KB => 8.6TB/天

你可能奇怪，这里为什么要按每天 8 小时 计算？这是因为大多数网站的用户访问量都很有规律，有的网站集中在上下班时间和夜晚，有的网站访问量集中在工作时间。结合到一人一天只有 8 小时左右的专注时间，就能推导出一天按 8 小时计算比较合理。

当然这个数值仅供参考，不同业务表现会不一样，你可以根据这个思路，结合自己的网站用户习惯来调整这个数值。

我们回到刚才的话题，根据上面的算式可以直观看到，如果我们的单次请求产生1KB日志的话，那么每天就有8T的日志需要做抓取、传输、整理、计算、存储等操作。为了方便追溯问题，我们还需要设定日志保存的周期，这里按保存30天计算，那么一个月日志量就是258TB大小的日志需要存储，计算公式如下：

8.6TB X 30天 = 258 TB /30天

从容量算硬盘的投入

算完日志量，我们就可以进一步计算购买硬件需要多少钱了。

我要提前说明的是，硬件价格一直是动态变化的，而且不同商家的价格也不一样，所以具体价格会有差异。这里我们把重点放在理解整个计算思路上，学会以后，你就可以结合自己的实际情况做估算了。

目前常见的服务器硬盘（8 TB、7200转、3.5寸）的单价是 2300元 ，8 TB硬盘的实际可用内存为7.3 TB，结合前面每月的日志量，就能算出需要的硬盘个数。计算公式如下：

258 TB/7.3 TB = 35.34 块

因为硬盘只能是整数，所以需要36块硬盘。数量和单价相乘，就得到了购入硬件的金额，即：

2300元 X 36 = 82800元

为了保证数据的安全以及加强查询性能，我们常常会通过分布式存储服务将数据存三份，那么分布式存储方案下，用单盘最少需要108 块硬盘，那么可以算出我们需要的投入成本是：

82800 X 3 个数据副本 = 24.8W 元

如果要保证数据的可用性，硬盘需要做 Raid5。该方式会把几个硬盘组成一组对外服务，其中一部分用来提供完整容量，剩余部分用于校验。不过具体的比例有很多种，为了方便计算，我们选择的比例是这样的：按四个盘一组，且四个硬盘里有三个提供完整容量，另外一个做校验。

Raid5方式中计算容量的公式如下：

  • 单组raid5容量=((n-1)/n) /* 总磁盘容量，其中n为硬盘数

我们把硬盘数代入到公式里，就是：

((4-1)/4) X (7.3T X 4) = 21.9 T = 三块8T 硬盘容量

这个结果表示一组Raid5四个硬盘，有三个能提供完整容量，由此不难算出我们需要的容量还要再增加1/4，即：

108 / 3 = 36块校验盘

最终需要的硬盘数量就是 108块 + 36块Raid5校验硬盘 = 144块硬盘，每块硬盘2300元，总成本是：

144 X 2300元 = 331200元

为了计算方便，之后我们取整按33W元来计算。

除了可用性，还得考虑硬盘的寿命。因为硬盘属于经常坏的设备，一般连续工作两年到三年以后，会陆续出现坏块，由于有时出货缓慢断货等原因以及物流问题，平时需要常备 40 块左右的硬盘（大部分公司会常备硬盘总数的三分之一）用于故障替换，大致需要的维护成本是2300元 X 40 = 92000 元。

到目前为止。我们至少需要投入的硬件成本，就T是一次性硬盘购买费用加上维护费用，即33 + 9.2 = 42W元。

根据硬盘推算服务器投入

接下来，我们还需要计算服务器的相关成本。由于服务器有多个规格，不同规格服务器能插的硬盘个数是不同的，情况如下面列表所示：

  • 普通 1u 服务器 能插 4个 3.5 硬盘 、SSD硬盘 2 个
  • 普通 2u 服务器 能插 12个 3.5 硬盘 、SSD硬盘 6 个

上一环节我们计算过了硬盘需求，做 Raid5的情况下需要144块硬盘。这里如果使用2u服务器，那么需要的服务器数量就是12台（144块硬盘/12 = 12台）。

我们按一台服务器3W元的费用来计算，服务器的硬件投入成本就是36W元，计算过程如下：

12台服务器 X 3W = 36W元

这里说个题外话，同样数据的副本要分开在多个机柜和交换机分开部署，这么做的目的是提高可用性。

根据服务器托管推算维护费用

好，咱们回到计算成本的主题上。除了购买服务器，我们还得算算维护费用。

把2u服务器托管在较好的机房里， 每台服务器托管的费用每年大概是 1W元。前面我们算过服务器需要12台，那么一年的托管费用就是 12W元。

现在我们来算算第一年的投入是多少，这个投入包括硬盘的投入及维护费用、服务器的硬件费用和托管费用，以及宽带费用。计算公式如下：

第一年投入费用 = 42W（硬盘新购与备用盘）+ 36W（服务器一次性投入）+ 12W（服务器托管费）+ 10W（宽带费用）= 100W元

而后续每年维护费用，包括硬盘替换费用（假设都用完）、服务器的维护费用和宽带费用。计算过程如下：

9.2W（备用硬盘）+12W（一年托管）+10W（一年宽带）=31.2W元

根据第一年投入费用和后续每年的维护费用，我们就可以算出核心服务（30W QPS的）网站服务运转三年所需要的成本，计算过程如下：

31.2W X 2年 = 62.4W + 第一年投入 100W = 162.4W 元

当然，这里的价格并没有考虑大客户购买硬件的折扣、服务容量的冗余以及一些网络设备、适配卡等费用以及人力成本。但即便忽略这些，算完前面这笔账，再想想用2000台服务器跑ELK的场景，相信你已经体会到，多写一行日志有多么贵了。

服务器采购冗余

接下来，我们再聊聊采购服务器要保留冗余的事儿，这件事儿如果没亲身经历过，你可能很容易忽略。

如果托管的是核心机房，我们就需要关注服务器采购和安装周期。因为很多核心机房常常缺少空余机柜位，所以为了给业务后几年的增长做准备，很多公司都是提前多买几台备用。之前有的公司是按评估出结果的四倍来准备服务器，不过不同企业增速不一样，冗余比例无法统一。

我个人习惯是根据当前流量增长趋势，评估出的3年的服务器预购数量。所以，回想之前我们计算的服务器费用，只是算了系统计算刚好够用的流量，这么做其实是已经很节俭了。实际你做估算的时候一定要考虑好冗余。

如何节省存储成本？

一般来说，业务都有成长期，当我们业务处于飞速发展、快速迭代的阶段，推荐前期多投入硬件来支撑业务。当我们的业务形态和市场稳定后，就要开始琢磨如何在保障服务的前提下降低成本的问题。

临时应对流量方案

如果在服务器购买没有留冗余的情况下，服务流量增长了，我们有什么暂时应对的方式呢？

我们可以从节省服务器存储量或者降低日志量这两个思路入手，比如后面这些方式：

  • 减少我们保存日志的周期，从保存 30 天改为保存 7 天，可以节省四分之三的空间；
  • 非核心业务和核心业务的日志区分开，非核心业务只存 7 天，核心业务则存 30 天；
  • 减少日志量，这需要投入人力做分析。可以适当缩减稳定业务的排查日志的输出量；
  • 如果服务器多或磁盘少，服务器 CPU压力不大，数据可以做压缩处理，可以节省一半磁盘；

上面这些临时方案，确实可以解决我们一时的燃眉之急。不过在节约成本的时候，建议不要牺牲业务服务，尤其是核心业务。接下来，我们就来讨论一种特殊情况。

如果业务高峰期的流量激增，远超过30W QPS，就有更多流量瞬间请求尖峰，或者出现大量故障的情况。这时甚至没有报错服务的日志中心也会被影响，开始出现异常。

高峰期日志会延迟半小时，甚至是一天，最终后果就是系统报警不及时，即便排查问题，也查不到实时故障情况，这会严重影响日志中心的运转。

出现上述情况，是因为日志中心普遍采用共享的多租户方式，隔离性很差。这时候个别系统的日志会疯狂报错，占用所有日志中心的资源。为了规避这种风险，一些核心服务通常会独立使用一套日志服务，和周边业务分离开，保证对核心服务的及时监控。

高并发写的存储冷热分离

为了节省成本，我们还可以从硬件角度下功夫。如果我们的服务周期存在高峰，平时流量并不大，采购太多服务器有些浪费，这时用一些高性能的硬件去扛住高峰期压力，这样更节约成本。

举例来说，单个磁盘的写性能差不多是200MB/S，做了Raid5后，单盘性能会折半，这样的话写性能就是100MB/S x 一台服务器可用9块硬盘=900MB/S的写性能。如果是实时写多读少的日志中心系统，这个磁盘吞吐量勉强够用。

不过。要想让我们的日志中心能够扛住极端的高峰流量压力，常常还需要多做几步。所以这里我们继续推演，如果实时写流量激增，超过我们的预估，如何快速应对这种情况呢？

一般来说，应对这种情况我们可以做冷热分离，当写需求激增时，大量的写用 SSD扛，冷数据存储用普通硬盘。如果一天有 8 TB 新日志，一个副本 4 台服务器，那么每台服务器至少要承担 2 TB/天 存储。

一个1TB 实际容量为960G、M.2口的SSD硬盘单价是1800元，顺序写性能大概能达到3～5GB/s（大致数据）。

每台服务器需要买两块SSD硬盘，总计 24个 1 TB SSD （另外需要配适配卡，这里先不算这个成本了）。算下来初期购买SSD的投入是43200元，计算过程如下：

1800 元 X 12 台服务器 X 2 块SSD = 43200 元

同样地，SSD也需要定期更换，寿命三年左右，每年维护费是 1800 X 8 = 14400 元

这里我额外补充一个知识，SSD除了可以提升写性能，还可以提升读性能，一些分布式检索系统可以提供自动冷热迁移功能。

需要多少网卡更合算

通过加SSD和冷热数据分离，就能延缓业务高峰日志的写压力。不过当我们的服务器磁盘扛住了流量的时候，还有一个瓶颈会慢慢浮现，那就是网络。

一般来说，我们的内网速度并不会太差，但是有的小的自建机房内网带宽是万兆的交换机，服务器只能使用千兆的网卡。

理论上，千兆网卡传输文件速度是 1000mbps/8bit= 125MB/s，换算单位为 8 mbps = 1MB/s。不过，实际上无法达到理论速度，千兆的网卡实际测试传输速度大概是100MB/s左右，所以当我们做一些比较大的数据文件内网拷贝时，网络带宽往往会被跑满。

更早的时候，为了提高网络吞吐，会采用诸如多网卡接入交换机后，服务器做bond的方式提高网络吞吐。

后来光纤网卡普及后，现在普遍会使用万兆光接口网卡，这样传输性能更高能达到1250MB/s（10000mbps/8bit = 1250MB/s），同样实际速度无法达到理论值，实际能跑到 900MB/s 左右，即 7200 mbps。

再回头来看，之前提到的高峰期日志的数据吞吐量是多少呢？是这样计算的：

30W QPS /* 1KB = 292.96MB/s

刚才说了，千兆网卡速度是100MB/s，这样四台服务器分摊勉强够用。但如果出现多倍的流量高峰还是不够用，所以还是要升级下网络设备，也就是换万兆网卡。

不过万兆网卡要搭配更好的三层交换机使用，才能发挥性能，最近几年已经普及这种交换机了，也就是基础建设里就包含了交换机的成本，所以这里不再专门计算它的投入成本。

先前计算硬件成本时，我们说过每组服务器要存三个副本，这样算起来有三块万兆光口网卡就足够了。但是为了稳定，我们不会让网卡跑满来对外服务，最佳的传输速度大概保持在 300～500 MB/s就可以了，其他剩余带宽留给其他服务或应急使用。这里推荐一个限制网络流量的配置——QoS，你有兴趣可以课后了解下。

12台服务器分3组副本（每个副本存一份全量数据），每组4台服务器，每台服务器配置1块万兆网卡，那么每台服务器平时的网络吞吐流量就是：

292.96MB/s （高峰期日志的数据吞吐量） / 4台服务器 = 73MB/S

可以说用万兆卡只需十分之一，即可满足日常的日志传输需求，如果是千兆网卡则不够。看到这你可能有疑问，千兆网卡速度不是100MB/s，刚才计算吞吐流量是73MB/s，为什么说不够呢？

这是因为我们估算容量必须留有弹性，如果用千兆网卡，其实是接近跑满的状态，一旦稍微有点波动就会卡顿，严重影响到系统的稳定性。

另一方面，实际使用的时候，日志中心不光是满足基础的业务使用，承担排查问题的功能，还要用来做数据挖掘分析，否则投入这么大的成本建设日志中心，就有些得不偿失了。

我们通常会利用日志中心的闲置资源，用做限速的大数据挖掘。联系这一点，相信你也就明白了，我们为什么要把日志保存三份。其实目的就是通过多个副本来提高并发计算能力。不过，这节课我们的重点是演示如何计算成本，所以这里就点到为止了，有兴趣的话，你可以课后自行探索。

总结

这节课我们主要讨论了如何通过请求用户量评估出日志量，从而推导计算出需要多少服务器和费用。

图片

你可以先自己思考一下，正文里的计算过程还有什么不足。

其实，这个计算只是满足了业务现有的流量。现实中做估算会更加严谨，综合更多因素，比如我们在拿到当前流量的计算结果后，还要考虑后续的增长。这是因为机房的空间有限，如果我们不能提前半年规划出服务器资源情况，之后一旦用户流量增长了，却没有硬件资源，就只能“望洋兴叹”，转而用软件优化方式去硬扛突发de 情况。

当然了，根据流量计算硬盘和服务器的投入,只是成本推算的一种思路。如果是大数据挖掘，我们还需要考虑CPU、内存、网络的投入以及系统隔离的成本。

不同类型的系统，我们的投入侧重点也是不一样的。比如读多写少的服务要重点“堆“内存和网络；强一致服务更关注系统隔离和拆分；写多读少的系统更加注重存储性能优化；读多写多的系统更加关注系统的调度和系统类型的转变。

尽管技术决策要考虑的因素非常多，我们面临的业务和团队情况也各有不同。但通过这节课，我希望能让你掌握成本推算的思维，尝试结合计算来指导我们的计算决策。当你建议团队自建机房，或者建议选择云服务的时候，如果有一套这样的计算做辅助，相信方案通过的概率也会有所提升。

思考题

1.建设日志中心，使用云厂商的服务贵还是自己建设的贵？

2.大数据挖掘服务如何计算成本？

期待你在留言区和我交流互动，也推荐你把这节课分享给更多同事、朋友。我们下节课见！

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e9%ab%98%e5%b9%b6%e5%8f%91%e7%b3%bb%e7%bb%9f%e5%ae%9e%e6%88%98%e8%af%be/22%20%e5%ad%98%e5%82%a8%e6%88%90%e6%9c%ac%ef%bc%9a%e5%a6%82%e4%bd%95%e6%8e%a8%e7%ae%97%e6%97%a5%e5%bf%97%e4%b8%ad%e5%bf%83%e7%9a%84%e5%ae%9e%e7%8e%b0%e6%88%90%e6%9c%ac%ef%bc%9f.md