云杰通信面试

大文件写入磁盘和很多小文件，磁盘速率指标是不是时区参考价值

大文件顺序写入，和大量小文件写入，对磁盘的压力其实完全不一样。
大文件通常是：顺序 IO，磁盘吞吐会比较高，IOPS 压力不大，所以：磁盘速率（MB/s）参考价值比较大。
但如果是很多小文件：创建文件，inode更新，metadata操作，随机写
这时候更依赖：IOPS，await，磁盘延迟
而不是单纯看磁盘写入速率。因为很多小文件场景下：MB/s 可能并不高，但磁盘已经被打满了。
所以实际排查里：大文件重点看吞吐小文件重点看 IOPS 和 await，尤其 SSD 和机械盘差异会非常明显。

iops是什么？iops是什么？

IOPS 就是磁盘每秒能处理多少次 IO 读写请求。它不是看传输了多少数据，而是看处理了多少次操作。比如大文件顺序写入，可能一次 IO 就写了 1MB，但很多小文件场景下，4KB、8KB 的随机读写会产生大量 IO 请求，这时候磁盘吞吐量可能不高，但 IOPS 会非常高。所以数据库、Redis、日志、小文件场景，更关注 IOPS 和 IO 延迟，而不是单纯看磁盘 MB/s。

磁盘写入 ssd和固态硬盘，对cpu 有影响吗

有影响的。
磁盘写入本身就需要 CPU 参与，不管是 SSD 还是机械硬盘。只是 SSD 速度更快，单位时间内能处理更多 IO，所以高并发写入时，CPU 消耗反而可能更明显。
比如大量小文件写入时，CPU 需要处理：IO 调度，文件系统，inode/meta 更新，中断，数据拷贝，flush 落盘
如果是 NVMe SSD，高 IOPS 场景下，还可能看到：sys CPU，iowait升高。
尤其数据库、日志系统、Kafka 这类高频写入场景，经常会出现磁盘和 CPU 一起上涨，不是只有磁盘有压力。

prometheus 监控 磁盘需要关注哪些指标

Prometheus 监控磁盘，我一般重点关注磁盘容量、IO性能和延迟这几类指标。比如磁盘使用率，避免磁盘打满；然后关注磁盘读写速率、IOPS、await 延迟、iowait，以及磁盘 util 使用率。因为很多时候磁盘 MB/s 不高，但 util 已经 100% 了，说明磁盘已经成为瓶颈。像数据库、日志、大量小文件场景，我会更关注随机 IO、await 和 iowait。常见指标例如：

node_filesystem_avail_bytes
node_disk_read_bytes_total
node_disk_written_bytes_total
node_disk_reads_completed_total
node_disk_writes_completed_total
node_disk_io_time_seconds_total

如果是线上，我还会结合 Grafana 看磁盘延迟趋势和突发 IO 情况。

prometheus中Alertmanager抑制告警怎么去做
Alertmanager 里面，分组告警和抑制告警一般会一起配合使用。

分组告警主要是避免同类告警瞬间大量发送，比如同一个服务几十个 pod 同时报警，可以按照：

alertname
cluster
namespace
instance
这些标签做 group_by。
例如：
route:
group_by: ['alertname','cluster']
group_wait: 30s
group_interval: 5m
repeat_interval: 1h
这样同类型告警会合并成一条发送，而不是疯狂刷屏。
抑制告警则是控制“根因故障”产生的连带报警。比如 node down 后，会产生很多 pod、业务告警，这时候通过 inhibit_rules：
node down 抑制 pod unavailable
只保留根因告警。
所以：分组 = 多条相似告警合并发送 抑制 = 根因故障压制派生告警
两者一起用，才能真正减少告警风暴。