监控运维面试题.运维工程师面试题

一、基础概念题（8 题）

监控的核心目标是什么？运维监控的 “黄金指标” 有哪些？
参考答案：
核心目标：提前预警故障、快速定位根因、保障业务连续性、优化资源利用率。
黄金指标（参考 Google SRE 标准）：
可用性（Availability）：服务正常运行时间占比（如 99.99%）；
延迟（Latency）：用户请求从发起至响应的耗时（P50/P95/P99 分位数）；
吞吐量（Throughput）：单位时间内处理的请求数（如 QPS/TPS）；
错误率（Error Rate）：失败请求占总请求的比例（如 HTTP 5xx/4xx 占比）；
饱和度（Saturation）：资源（CPU / 内存 / 磁盘）的使用率，预测资源瓶颈。

什么是白盒监控和黑盒监控？两者的区别与适用场景是什么？
参考答案：
白盒监控：基于系统内部指标（如 CPU、内存、数据库连接数、代码日志）的监控，需了解系统内部结构；
适用场景：服务器、数据库、中间件等组件的性能监控，故障根因定位；
黑盒监控：基于外部行为（如用户访问、接口调用）的监控，不关心系统内部实现；
适用场景：业务可用性监控（如网站是否可访问、接口是否正常响应）、用户体验监控；
区别：白盒侧重 “组件健康度”，黑盒侧重 “业务可用性”，运维中需两者结合（如 Zabbix 白盒监控 + Nagios 黑盒监控）。

监控告警的 “分级” 和 “降噪” 有什么意义？如何实现告警降噪？
参考答案：
意义：
分级：避免所有告警同等对待，让运维人员优先处理核心故障（如 P0 级故障影响千万用户，P3 级仅影响单个非核心功能）；
降噪：减少 “告警风暴”（如某 OLT 宕机触发旗下所有 ONU 离线告警），避免运维人员疲劳。
降噪实现方式：
告警抑制：父故障触发后，抑制子故障告警（如服务器宕机后，抑制该服务器上所有应用的离线告警）；
告警合并：相同类型、同一节点的告警在一定时间内合并为一条（如 1 分钟内同一接口的 5 次超时告警合并）；
告警过滤：过滤已知非故障告警（如测试环境的临时告警）；
阈值优化：避免阈值过严导致的高频无效告警（如 CPU 使用率短期超 80% 不告警，连续 5 分钟超 80% 才告警）。

什么是 “监控闭环”？完整的监控闭环包含哪些环节？
参考答案：
监控闭环：从 “指标采集→告警触发→故障处理→复盘优化” 的完整流程，确保故障全生命周期可追溯、可优化。
环节：
数据采集：通过 Agent、SNMP、日志等方式采集指标；
指标分析：对比阈值、趋势，判断是否触发告警；
告警推送：通过多渠道（短信、电话、钉钉）推送告警；
故障处理：运维人员响应并修复故障；
复盘优化：记录故障原因、处理过程，优化监控规则（如调整阈值、增加关联指标）。

监控数据的 “时效性” 和 “准确性” 哪个更重要？为什么？
参考答案：
分场景判断：
核心业务故障监控（如支付接口、发电站设备）：时效性更重要，需毫秒级告警，避免故障扩大；
资源容量规划（如磁盘空间增长趋势）：准确性更重要，需精准数据支撑决策，避免误扩容 / 漏扩容；
平衡方案：核心指标（如业务接口响应时间）提高采集频率（1-5 秒），非核心指标（如设备温度）降低频率（1-5 分钟）。

什么是 “分布式监控”？其核心优势是什么？适用于哪些场景？
参考答案：
分布式监控：监控平台的采集、存储、分析模块分布在多个节点，而非集中在单台服务器（如 Zabbix Server+Proxy 架构）；
核心优势：
支持大规模节点监控（如百万级基站、千万级设备）；
跨地域监控（如总部监控全国分支机构设备）；
高可用（某 Proxy 节点故障不影响其他区域监控）；
适用场景：运营商、电力、金融等行业（设备分散、规模庞大）。

日志监控和指标监控的区别是什么？各自的适用场景？
参考答案：
维度
指标监控（如 Zabbix、Prometheus）
日志监控（如 ELK、Graylog）
数据类型
结构化数据（数值、状态）
非结构化 / 半结构化数据（文本）
监控粒度
宏观（如 CPU 使用率、接口成功率）
微观（如单条错误日志、用户操作轨迹）
适用场景
性能监控、故障预警、容量规划
故障根因定位、安全审计、用户行为分析
典型案例
服务器负载监控、数据库连接数监控
应用报错日志分析、黑客登录日志审计

什么是 SLA？监控如何支撑 SLA 达标？
参考答案：
SLA（服务等级协议）：企业与用户 / 客户约定的服务质量标准（如 “系统可用性≥99.99%”“故障修复时间≤4 小时”）；
监控支撑方式：
实时统计 SLA 核心指标（如可用性 = 正常运行时间 / 总时间）；
针对 SLA 指标设置告警（如可用性低于 99.99% 触发紧急告警）；
生成 SLA 报表（如每月 SLA 达标率、故障影响时长统计），用于复盘优化。
二、工具实操题（10 题）

Zabbix 的核心组件有哪些？Zabbix Proxy 的作用是什么？
参考答案：
核心组件：Zabbix Server（核心调度）、Zabbix Agent（客户端数据采集）、Zabbix Proxy（分布式采集代理）、Database（存储监控数据）、Web UI（可视化管理）；
Zabbix Proxy 的作用：
分担 Server 压力，采集分布式节点数据（如分支机构设备）；
解决跨网段监控问题（如防火墙限制 Server 直接访问客户端）；
本地缓存数据，网络中断时暂存，恢复后同步至 Server。

Zabbix 中 “监控项”“触发器”“告警媒介” 的关系是什么？
参考答案：
监控项：采集的具体指标（如system.cpu.util[all,avg1]监控 CPU 使用率）；
触发器：基于监控项设置的告警规则（如 CPU 使用率连续 5 分钟 > 80%）；
告警媒介：告警的推送渠道（如邮件、钉钉、电话）；
关系：监控项采集数据→触发触发器→通过告警媒介推送告警。

如何用 Zabbix 监控一台 Linux 服务器的 “磁盘空间”？步骤是什么？
参考答案：
客户端安装 Zabbix Agent2，配置zabbix_agent2.conf（指定 Server IP、Hostname）；
Zabbix Server 端添加主机（配置客户端 IP、关联模板）；
（可选）自定义监控项：键值vfs.fs.size[/,pfree]（监控根目录剩余空间占比）；
创建触发器：{主机名:vfs.fs.size[/,pfree].last()} 20（剩余空间 < 20% 触发告警）；
配置告警媒介：将触发器与钉钉 / 短信渠道关联；
验证：手动占用磁盘空间测试告警是否触发。

Prometheus 和 Grafana 的关系是什么？Prometheus 的 “时序数据” 指什么？
参考答案：
关系：Prometheus 负责数据采集与存储（时序数据），Grafana 负责数据可视化（绘制监控大屏、仪表盘），两者常搭配使用（Prometheus 采集 + Grafana 展示）；
时序数据：按时间顺序排列的指标数据（如每 10 秒采集一次 CPU 使用率，形成时间 – 数值的序列），支持按时间范围查询、趋势分析。

如何用 Prometheus 监控 Nginx 的 QPS 和错误率？
参考答案：
Nginx 配置：启用ngx_http_stub_status_module模块，暴露监控指标（如/nginx_status）；
安装 Nginx Exporter（Prometheus 的 Nginx 监控插件），配置 Nginx 状态页地址；
Prometheus 配置文件中添加 Exporter 目标（如- targets: [“192.168.1.100:9113”]）；
编写 PromQL 查询：
QPS：sum(rate(nginx_http_requests_total[5m])) by (host)；
错误率：sum(rate(nginx_http_requests_total{status=~“5…”}[5m])) / sum(rate(nginx_http_requests_total[5m])) * 100；
Grafana 添加 Prometheus 数据源，创建 QPS / 错误率仪表盘。

ELK Stack（Elasticsearch+Logstash+Kibana）在监控中的作用是什么？如何用 ELK 监控应用日志中的错误信息？
参考答案：
作用：日志集中收集、分析、可视化，用于故障根因定位、安全审计；
监控应用错误日志步骤：
应用配置：将日志输出为 JSON 格式（包含时间、级别、错误信息）；
Logstash：采集应用日志（通过 Filebeat 代理），过滤清洗数据（如提取错误级别、关键字）；
Elasticsearch：存储清洗后的日志数据，建立索引；
Kibana：创建可视化面板，筛选level: ERROR的日志，设置告警（如错误日志数 5 分钟内超 10 条触发告警）。

Zabbix 中 “自定义脚本监控项” 的配置步骤是什么？举例说明（如监控登录用户数）。
参考答案：
以监控 Linux 登录用户数（who | wc -l）为例：
客户端创建脚本：/etc/zabbix/scripts/check_login.sh，内容：
#!/bin/bash
who | wc -l

脚本授权：chmod +x check_login.sh && chown zabbix:zabbix check_login.sh；
编辑zabbix_agent2.conf，添加自定义监控项：
UserParameter=system.login.users,bash /etc/zabbix/scripts/check_login.sh

重启 Zabbix Agent2：systemctl restart zabbix-agent2；
Zabbix Server 端测试：zabbix_get -s 客户端IP -k “system.login.users”；
服务器端添加监控项（键值system.login.users）、触发器（如数值 > 3 触发告警）。
16. 如何排查 Zabbix Agent “监控数据采集失败” 的问题？
参考答案：
网络连通性：检查 Server 与 Agent 的 10050/10051 端口是否互通（telnet 客户端IP 10050）；
Agent 配置：确认zabbix_agent2.conf中Server参数包含 Zabbix Server IP；
权限问题：自定义脚本是否给 Zabbix 用户授权（如chown zabbix:zabbix）；
监控项配置：键值是否与 Agent 配置一致（如自定义监控项的UserParameter键值）；
日志排查：查看 Agent 日志（/var/log/zabbix/zabbix_agent2.log），是否有报错（如 “permission denied”）；
手动测试：用zabbix_get命令在 Server 端测试采集（如zabbix_get -s 客户端IP -k “system.uname”）。
17. Nagios 和 Zabbix 的核心区别是什么？如何选择？
参考答案：
维度
Nagios
Zabbix
核心优势
轻量、插件丰富、黑盒监控强
全栈监控、分布式部署、可视化强
适用场景
中小规模环境、简单监控（如设备存活）
大规模环境、复杂监控（如业务指标、工控设备）
学习成本
低
中高
二次开发
需自定义插件
支持自定义监控项、脚本、API 集成
典型用户
小型企业、个人运维
运营商、电力、金融等大型企业

选择建议：简单监控选 Nagios，复杂全栈监控选 Zabbix。
18. 如何用 Ansible 批量部署 Zabbix Agent？
参考答案：
控制节点配置 Ansible 主机清单（/etc/ansible/hosts），添加待部署 Agent 的节点；
编写 Ansible Playbook（zabbix_agent_deploy.yml）：

hosts: all
tasks:
name: 安装Zabbix Agent2
dnf: name=zabbix-agent2 state=presentname: 复制配置文件
template: src=zabbix_agent2.conf.j2 dest=/etc/zabbix/zabbix_agent2.confname: 启动Agent服务
service: name=zabbix-agent2 state=started enabled=yes

创建配置文件模板（zabbix_agent2.conf.j2），替换 Server 和 Hostname 为变量；
执行 Playbook：ansible-playbook zabbix_agent_deploy.yml；
验证：Zabbix Server 端批量添加主机，测试监控数据采集。
三、故障处理题（6 题）
19. 某电商平台促销期间，Zabbix 告警 “某应用服务器 CPU 使用率持续 95%”，如何排查和解决？
参考答案：
紧急响应：
查看该服务器的进程负载：top命令，排序 CPU 使用率（按P），定位高负载进程（如 Java 进程、数据库进程）；
临时缓解：若为非核心进程，暂时停止；若为核心进程，查看是否有内存泄漏（jstat分析 Java 进程），重启服务。
根因排查：
结合 Zabbix 关联指标：查看该服务器的网络带宽、磁盘 IO、应用接口响应时间，判断是否为流量突增、磁盘瓶颈导致 CPU 飙升；
日志分析：查看应用日志（如 Tomcat 日志），是否有频繁报错、死循环；
业务关联：确认促销活动是否导致该服务器的业务并发量突增（如商品详情页访问量暴涨）。
长期解决：
扩容：增加服务器 CPU 核心数，或扩容集群节点，通过负载均衡分担压力；
优化：优化高 CPU 占用的代码（如死循环、低效查询），数据库慢查询优化；
监控优化：给该服务器添加 “并发量”“接口 QPS” 监控项，提前预警流量突增。
20. Zabbix 告警 “数据库连接数满”，如何排查？
参考答案：
查看数据库连接数：
MySQL：show global status like ‘Threads_connected’;，对比max_connections配置；
Oracle：select count(*) from v$session;，查看活跃连接数。
定位连接来源：
MySQL：show processlist;，查看连接对应的 IP、用户、执行 SQL，判断是否为正常业务连接；
若存在大量空闲连接：检查应用是否未释放连接（如连接池配置不当）。
临时解决：
增加数据库最大连接数（如 MySQL 修改my.cnf的max_connections=2000，重启数据库）；
杀死长时间空闲的连接（如 MySQL 执行kill [进程ID]）。
长期解决：
优化应用连接池配置（如设置最大连接数、空闲连接超时时间）；
排查是否存在连接泄漏（如应用代码未