在技术选型时，我们往往会仔细考量各项成本，尤其关注实现成本，这种“斤斤计较”其实能带来直接的经济效益。那么，你是否有系统地思考过如何计算这些成本呢？本节课将通过一个日志中心的例子，带领你逐步进行成本计算。

之所以选择日志中心，主要有两点考虑：

1. 重要且通用：日志中心作为系统监控的核心组件，几乎所有系统的监控和故障排查都依赖它。因此，大部分系统中都能用到日志中心。
2. 高成本、计算复杂：日志中心是一个成本较高的项目，计算方式相对复杂。如果你能掌握课程中的这个例子，日后就能运用类似的思路去计算其他组件的成本，变得更加得心应手。

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

在互联网服务中，最大的变量就是用户流量。相比普通服务，高并发系统需要同时处理更多的在线用户，因此在设计这类系统的容量时，需要根据用户请求量和同时在线人数来推算系统硬件投入的成本。

很多系统在初期会采用云服务来构建日志中心。然而当核心接口流量超过10万 QPS后，许多公司就会考虑自建机房，甚至后期会持续改进日志中心，开发一些个性化的服务。实际上，这些优化和实现的核心目的都与成本息息相关。为了让这个概念更加直观，我们来通过一个实际例子，计算一个高并发网站的日志中心所需的存储容量和成本。

假设一个高并发网站在流量高峰期，其核心 API 的 QPS 约为 30 万，我们按每天 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 的日志，每天将会有约 8.6TB 的日志数据需要处理、传输、整理、计算和存储。

为了方便问题追溯，我们还需设定日志的保存周期。假设日志保留30天，那么一个月的日志量将达到：

8.6TB X 30 天 = 258 TB /30 天

通过以上计算可以看出，一个高并发网站的日志存储需求十分庞大。这种分析思路不仅适用于日志中心，还可以作为其他组件容量与成本计算的参考。

从容量算硬盘的投入

在计算出日志量后，我们就可以进一步估算购买硬件所需的成本。不过需要提前说明的是，硬件价格是动态变化的，且不同商家的定价会有所差异，因此具体成本可能会有差异。这次我们主要关注计算思路，学会后你可以根据实际情况来调整。

目前，常见的服务器硬盘规格为8TB、7200转、3.5寸，单价约为2300元。考虑到实际可用容量，8TB硬盘的实际可用存储空间约为7.3TB。结合之前的每月日志量，可以计算出所需的硬盘数量，计算公式如下：

258 TB/7.3 TB = 35.34 块

由于硬盘数量必须是整数，所以需要36块硬盘。然后将数量与单价相乘，就得出硬件的总成本：

2300 元 X 36 = 82800 元

为了确保数据安全并增强查询性能，我们通常会使用分布式存储，将数据存储三份。这样一来，在分布式存储方案下，至少需要108块硬盘。此时的投入成本为：

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

如果还要保证数据的可用性，我们可以选择 RAID 5 阵列。RAID 5 会将多个硬盘组成一个阵列，其中部分硬盘提供完整存储容量，另外一部分硬盘则用于校验和冗余。虽然具体的 RAID 配比有多种方案，但为了简化计算，我们选择以下配置：每四块硬盘组成一组，其中三块提供完整容量，一块用于校验。

在 RAID 5 模式下，容量计算公式为：

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

其中 n n n 为硬盘数量。将4块硬盘代入公式：

108 / 3 = 36 块校验盘

这表明，一组RAID 5由四块硬盘组成，其中三块提供完整的存储容量。由此可以计算出，为了满足存储需求，我们需要在108块硬盘的基础上增加四分之一的容量来存放校验数据，即：

108 / 3 = 36 块校验盘

因此，最终需要的硬盘数量为：

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

每块硬盘的价格为2300元，因此总成本为：

144 X 2300 元 = 331200 元

为了方便计算，我们可以取整按33万元来计算。

除了确保可用性外，还需考虑硬盘的寿命。由于硬盘是易损设备，一般在连续工作两到三年后会陆续出现损坏情况。为应对硬盘损坏和补货缓慢等问题，通常会预备大约总数三分之一的硬盘作为备件。也就是说，需常备40块硬盘用于故障替换，维护成本约为：

2300 元 X 40 = 92000 元

综上，至少需投入的硬件成本为一次性硬盘采购费用加上维护费用，即：

33 +9.2= 42 万元

根据硬盘推算服务器投入

接下来，我们需要计算服务器的相关成本。服务器有多种规格，不同规格可以插入的硬盘数量也不同，具体如下：

• 普通 1U 服务器：可插 4 个 3.5 寸硬盘，或 2 个 SSD 硬盘
• 普通 2U 服务器：可插 12 个 3.5 寸硬盘，或 6 个 SSD 硬盘

在上一步中，我们已经计算出做 RAID 5 的情况下需要 144 块硬盘。若采用 2U 服务器，则需要的服务器数量为：

144 块硬盘 12 块/台= 12 台服务器

假设每台服务器的费用为 3 万元，那么服务器的硬件成本为：

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

补充说明

：为了提高可用性，通常将相同数据的副本分散在不同的机柜和交换机上部署。这种方式可以在机柜或网络设备出现故障时，依然保证数据的高可用性。

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

除了购买服务器，还需要考虑维护费用。将 2U 服务器托管在优质机房内，每台服务器的年托管费用约为 1 万元。前面计算得出，我们需要 12 台服务器，那么一年的托管费用为：

12 台× 1 万元= 12 万元

接着，我们来计算第一年的总投入，包括硬盘采购与维护、服务器硬件成本、托管费用，以及带宽费用。具体计算如下：

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

后续每年维护费用包括硬盘替换（假设备用盘用完）、服务器托管费以及带宽费用，计算如下：

9.2 万（备用硬盘）+ 12 万（托管费）+ 10 万（带宽费）=31.2 万元

基于第一年投入和后续维护费用，我们可以计算三年内运转 30 万 QPS 核心服务所需的成本，具体如下：

31.2 万元× 2 年=62.4 万元+第一年投入 100 万元=162.4 万元

当然，这里未包含大客户的硬件采购折扣、冗余容量、网络设备、适配卡等费用以及人力成本。但即便忽略这些，当你看到这样的成本支出，再想想某些场景中用 2000 台服务器来运行 ELK，相信你会深刻体会到，多写一行日志的成本究竟有多高。

服务器采购冗余

接下来，我们谈谈采购服务器时保留冗余的问题。如果没有亲身经历过，可能会容易忽略这一点。

对于核心机房的托管，服务器的采购和安装周期需要特别关注。很多核心机房往往缺乏空余的机柜位，因此，为了满足未来几年的业务增长需求，许多公司会提前多采购一些备用服务器。曾有公司按照评估结果的四倍来备货，不过不同企业的业务增长速度不同，冗余比例并没有统一标准。就我个人而言，习惯根据当前流量增长趋势，预估未来三年的服务器需求量来进行采购。

因此，回头看我们之前计算的服务器成本，实际上只是基于现有需求而已，只能算是“刚好够用”。实际操作中，做成本估算时一定要将冗余考虑在内，以免因资源不足影响业务发展。

如何节省存储成本？

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

临时应对流量方案

如果在服务器采购时没有留出冗余，而服务流量增长了，我们可以采取一些临时措施来缓解压力。可以从节省服务器存储空间和减少日志量这两个方面着手，例如：

• 缩短日志保存周期：将日志保存周期从 30 天缩短为 7 天，这样可以节省约四分之三的存储空间。
• 区分核心和非核心业务日志：非核心业务日志可以只保存 7 天，而核心业务日志则继续保存 30 天，以优先保障关键数据。
• 减少日志量：这可能需要分析并调整日志输出，对稳定业务的排查日志适当缩减，减少不必要的记录量。
• 进行数据压缩：如果服务器数量充足或磁盘较少、CPU 负载不高，可以考虑对数据进行压缩处理，这样可节省一半的存储空间。

以上这些措施能够在短期内缓解存储压力，作为应急之策。但是在控制成本时，建议不要牺牲业务服务，尤其是核心业务的稳定性。接下来，我们可以探讨一种特殊情况。

如果业务高峰期的流量激增，远超过 30W QPS，就有更多流量瞬间请求尖峰，或者出现大量故障的情况。这时甚至没有报错服务的日志中心也会被影响，开始出现异常。高峰期日志会延迟半小时，甚至是一天，最终后果就是系统报警不及时，即便排查问题，也查不到实时故障情况，这会严重影响日志中心的运转。出现上述情况，是因为日志中心普遍采用共享的多租户方式，隔离性很差。这时候个别系统的日志会疯狂报错，占用所有日志中心的资源。为了规避这种风险，一些核心服务通常会独立使用一套日志服务，和周边业务分离开，保证对核心服务的及时监控。

高并发写的存储冷热分离

为了节省成本，还可以从硬件方面入手。如果我们的服务有明显的高峰期，但平时流量并不大，采购过多服务器可能会造成资源浪费。这时可以通过采购高性能硬件来支撑高峰期流量，达到更节约的效果。

例如，单个磁盘的写性能约为 200MB/s，在 RAID 5 环境下，单盘性能减半，约为 100MB/s。假设一台服务器能装 9 块硬盘，则总写性能为：

100 MB/s× 9 块硬盘= 900 MB/s

这样的磁盘吞吐量可以满足实时写入、少量读取的日志中心需求，但应对极端高峰时可能还需额外优化。为此，我们可以考虑冷热分离策略：在写入需求激增时，用 SSD 来处理高并发写入，而将冷数据存储在普通硬盘上。

假设每天产生 8TB 新日志，每个副本分布在 4 台服务器上，则每台服务器需承担 2TB 的每日存储需求。按 1TB SSD 的实际容量为 960GB，M.2 接口 SSD 单价约 1800 元、顺序写入性能在 3-5GB/s，则每台服务器需配备两块 SSD，总计 24 块 1TB SSD，计算如下：

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

此外，SSD 需要定期更换，其寿命约为三年，年维护费用为：

1800 元× 8 块= 14400 元

补充知识

：SSD 不仅能提升写入性能，还能提升读取性能，并且一些分布式检索系统支持自动冷热迁移功能，使高频数据更快速响应，而冷数据则存储在更节省成本的硬盘中。

需要多少网卡更合算

通过增加 SSD 和冷热数据分离，确实可以有效缓解业务高峰时日志写入的压力。然而，即便服务器磁盘能够承受住流量压力，网络瓶颈也会随之显现。

通常情况下，内网速度不会太低，但一些小型自建机房可能配备万兆交换机而服务器仅支持千兆网卡。理论上，千兆网卡的传输速度为：

1000 Mbps/ 8 = 125 MB/s

实际传输速度却往往达不到这个理论值，大致在 100 MB/s 左右。当我们在内网中进行大数据文件的传输时，千兆网卡的带宽会很容易被占满。

过去，为了提高网络吞吐量，常用的方法是多网卡接入交换机并在服务器上进行 Bond 处理。随着光纤网卡的普及，万兆光口网卡成为主流，其理论传输速度为：

10000 Mbps/ 8 = 1250 MB/s

而实际速度大概能达到 900 MB/s（即 7200 Mbps）左右。

再回到我们之前计算的日志高峰数据吞吐量：

300 , 000 QPS× 1 KB=292.96 MB/s

对于千兆网卡来说，100 MB/s 的带宽速度在四台服务器分摊下勉强够用。但在更高流量的高峰期，这一带宽仍显不足，因此需要升级为万兆网卡。值得注意的是，万兆网卡还需配合性能更高的三层交换机才能完全发挥作用。近年来，万兆交换机已普及，通常包含在基础设施成本中，这里不再单独计算交换机的投入成本。

在之前的硬件成本计算中，我们提到每组服务器需要存储三个副本，因此配置三块万兆光口网卡是足够的。然而，为了确保系统的稳定性，我们不会将网卡的带宽使用率保持在满负荷状态，最佳的传输速度应保持在 300 到 500 MB/s 之间，以便预留出额外的带宽供其他服务使用或应对突发情况。

对于 12 台服务器来说，它们分为 3 组副本（每组 4 台服务器，每个副本存储一份完整数据）。在这种配置下，每台服务器的日常网络吞吐量可以计算为：

292.96 MB/s (高峰期日志数据吞吐量)/ 4 台服务器= 73 MB/s

在使用万兆网卡的情况下，这样的吞吐量仅占总带宽的十分之一，完全能满足日常的日志传输需求。如果使用千兆网卡，情况就不一样了。

尽管千兆网卡的理论速度为 100 MB/s，计算得出的 73 MB/s 吞吐流量似乎可以在其容量范围内，但这样做是不够的。这是因为我们在估算容量时必须留有弹性。使用千兆网卡时，实际负载接近满载，一旦出现流量波动，就可能导致网络拥堵，从而严重影响系统的稳定性。

此外，日志中心的功能不仅仅是满足基础的业务需求，它还需要承担问题排查和数据挖掘分析的任务。如果仅仅为了基础服务而建设一个如此昂贵的日志中心，确实是得不偿失的。因此，在选择网络硬件时，确保充足的带宽和冗余设计是至关重要的。