继续分享最新的go面经。
今天分享的是组织内部的朋友在字节的go运维工程师岗位的云原生方向的面经,涉及Prometheus、Kubernetes、CI/CD、网络代理、MySQL主从、Redis哨兵、系统调优及基础命令行工具
等知识点,问题我都整理在下面了
面经详解
Prometheus 的信息采集原理?
回答思路:
数据模型:Prometheus 采用时间序列数据模型,每个数据点由以下部分组成:
- 度量名称(Metric Name):标识数据的类型(如
http_requests_total
)。 - 标签(Labels):键值对形式的元数据,用于唯一标识数据的来源和维度(如
job="api-server", instance="192.168.1.100:9090"
)。 - 时间戳(Timestamp):记录数据采集的时间。
- 数值(Value):具体指标值(如 CPU 使用率 75%)。
- 度量名称(Metric Name):标识数据的类型(如
数据采集:
- 拉取模式(Pull Model):Prometheus 定期主动从目标(Targets)拉取指标数据,默认周期为 1 分钟。
- 推送模式(Push Model):通过中间件(如 Pushgateway)将数据推送到 Prometheus,适用于短生命周期任务(如批处理作业)。
- Service Discovery:支持自动发现目标节点(如 Kubernetes 服务、Consul 注册中心),减少手动配置。
存储与查询:
- 数据存储为时间序列,按度量名称和标签分组,支持高效查询。
- PromQL:提供丰富的查询语言,支持聚合运算(如
avg()
,sum()
)、范围查询([5m]
)、条件判断(如> 90
)等。
优势与局限性:
- 优势:高可用、分布式、灵活的标签系统。
- 局限性:拉取模式可能因网络问题漏数据,存储成本较高。
Prometheus 采集K8S是哪个接口?
回答思路:
Kubernetes API Server:
- Prometheus 通过 Kubernetes API 监控集群资源状态(如 Pod、Deployment、Node 等),需配置
kubernetes_sd_config
进行服务发现。 示例配置:
scrape_configs: - job_name: 'kubernetes-apiservers' kubernetes_sd_configs: - role: endpoints relabel_configs: - action: keep regex: default source_labels: [__meta_kubernetes_namespace]
- Prometheus 通过 Kubernetes API 监控集群资源状态(如 Pod、Deployment、Node 等),需配置
Metrics Server:
- 提供 Pod、Node 的资源使用指标(如 CPU/内存使用率),需通过
kube-state-metrics
或cAdvisor
采集。 示例:
curl http://localhost:8080/api/v1/nodes/{node-name}/metrics
- 提供 Pod、Node 的资源使用指标(如 CPU/内存使用率),需通过
自定义接口:
- 应用需暴露
/metrics
端点,格式符合 Prometheus 文本格式(如通过prometheus-client-go
库实现)。
- 应用需暴露
注意事项:
- 需配置 RBAC 权限,确保 Prometheus 有权限访问 K8S API。
- 使用
kube-prometheus-stack
Helm Chart 可一键部署完整监控链。
Prometheus 的告警是怎么配置的?
回答思路:
告警规则(Alert Rules):
在
prometheus.yml
或独立的.rules
文件中定义规则,例如:groups: - name: example rules: - alert: HighCPUUsage expr: instance:node_cpu_usage:rate1m > 0.8 for: 5m labels: severity: warning annotations: summary: "Instance {{ $labels.instance }} CPU usage is high"
expr
:PromQL 表达式,定义触发条件。for
:告警持续时间(避免短暂波动触发)。labels
和annotations
:补充告警元数据和描述。
Alertmanager 配置:
路由(Routes):根据标签(如
severity
)将告警分发到不同接收者。route: group_by: ['alertname'] group_wait: 30s group_interval: 5m receiver: 'team-alerts' routes: - match_re: severity: critical receiver: 'oncall-team'
- 抑制(Inhibit):高优先级告警(如
InstanceDown
)可抑制低优先级告警(如HighCPUUsage
)。 - 接收器(Receivers):支持多种通知方式(如 Slack、PagerDuty、Email)。
实践建议:
- 避免“告警疲劳”:合理设置阈值和
for
参数。 - 验证告警:通过
fire-and-forget
模式测试配置。
- 避免“告警疲劳”:合理设置阈值和
Prometheus 的告警是基于哪个组件配置的?
回答思路:
核心组件:Alertmanager
功能:
- 接收 Prometheus 发送的告警事件。
- 根据配置路由规则将告警分发给接收者(如团队 Slack 频道)。
- 聚合相似告警,减少重复通知(如
group_by
)。 - 抑制冗余告警(如主节点宕机时抑制其下所有服务的告警)。
配置文件示例:
global: resolve_timeout: 5m route: receiver: 'team-email' group_wait: 30s receivers: - name: 'team-email' email_configs: - to: 'team@example.com'
Prometheus 集成:
在
prometheus.yml
中指定 Alertmanager 地址:alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093']
扩展能力:
- 支持与 Grafana、PagerDuty 等工具集成,实现更复杂的告警管理。
CI 流水线发现问题是怎么排查解决的?
回答思路:
分层排查法:
环境层:
- 检查流水线运行的环境(如 Docker 镜像、依赖版本、网络配置)。
- 使用
docker inspect
或kubectl describe pod
查看容器状态。
日志层:
- 定位到失败步骤的日志,关注错误代码、堆栈信息。
- 使用日志聚合工具(如 ELK、Splunk)快速筛选关键信息。
代码层:
- 复现问题:本地复现流水线环境,逐步调试代码。
- 单元测试:针对可疑代码添加测试用例。
配置层:
- 检查流水线 YAML 文件中的参数、路径、工具版本。
- 确认敏感信息(如 API 密钥)是否正确注入。
工具辅助:
- GitLab CI/CD:通过
echo
命令输出中间变量,或使用debug
模式。 - Jenkins:使用 Blue Ocean 插件可视化流水线状态。
- GitLab CI/CD:通过
预防措施:
- 增加流水线前置检查(如依赖库版本校验)。
- 实施变更管理流程,减少环境漂移。
访问服务出现 502 是什么问题?
回答思路:
常见原因及排查步骤:
反向代理问题:
- Nginx 配置错误:检查
proxy_pass
是否指向正确的后端服务地址。 - 超时设置:调整
proxy_read_timeout
或proxy_connect_timeout
。
- Nginx 配置错误:检查
后端服务问题:
- 服务未启动:检查进程状态(
ps aux | grep service_name
)。 - 负载过高:监控 CPU/内存使用率,优化代码或扩容。
- 服务未启动:检查进程状态(
网络问题:
- 防火墙/安全组:确认后端服务端口是否开放。
- DNS 解析:使用
dig
或nslookup
验证域名解析。
健康检查失败:
- 如果使用负载均衡(如 Kubernetes Ingress),检查健康检查配置是否合理。
示例排查流程:
- 访问日志:检查 Nginx 的
error.log
中的502
错误详情。 - 模拟请求:直接访问后端服务(如
curl http://backend:8080
)。 - 查看后端日志:检查服务端日志(如
tail -f /var/log/app.log
)。
- 访问日志:检查 Nginx 的
解决方案:
- 重启服务或代理。
- 调整超时参数或负载均衡策略。
- 优化后端服务性能(如增加缓存、分页查询)。
K8S service 的服务类型有几种?
回答思路:
ClusterIP:
- 默认类型,仅在集群内部通过虚拟 IP(VIP)访问。
- 适用场景:后端服务间通信(如数据库、API 服务)。
NodePort:
- 在每个 Node 的 IP 上开放一个端口(默认
30000-32767
),外部可通过NodeIP:NodePort
访问。 - 适用场景:开发/测试环境暴露服务,或需要快速访问。
- 在每个 Node 的 IP 上开放一个端口(默认
LoadBalancer:
- 在云平台(如 AWS、GCP)创建云负载均衡器,流量自动转发到 Service。
- 适用场景:生产环境的高可用服务暴露。
ExternalName:
- 通过 CNAME 将 Service 映射到外部域名(如
api.example.com
),常用于跨集群访问。
- 通过 CNAME 将 Service 映射到外部域名(如
高级场景:
- 头信息修改:通过
externalTrafficPolicy: Local
控制流量来源。 - Ingress 控制器:结合 Ingress 资源实现基于路径或域名的路由(如 Nginx Ingress)。
- 头信息修改:通过
选择建议:
- 生产环境优先使用 LoadBalancer 或 Ingress。
- 避免在生产环境使用 NodePort,因其端口冲突风险较高。
给文件的每一个前面增加head?
回答思路:
Vim 编辑器:
- 打开文件:
vim filename
。 - 进入命令模式,输入
:%s/^/head /g
(替换每一行开头)。 - 或使用可视模式:
ggVG:Ihead
(全局插入)。
- 打开文件:
sed 命令:
sed -i 's/^/head /' filename # 或批量处理多行: sed -i '1i\head' filename # 在文件开头插入(非每行)
awk 命令:
awk '{print "head " $0}' filename > newfile
注意事项:
-i
参数会直接修改原文件,建议先备份。- 若需保留原文件,可重定向输出:
awk ... > newfile
。
awk 提取数值为8的第二列的数量,分隔符为 | ,怎么提取?
回答思路:
基础命令:
awk -F '|' '$2 == 8 {count++} END {print count}' filename
-F '|'
:设置分隔符为|
。$2 == 8
:筛选第二列值为 8 的行。count++
:计数器自增。
扩展场景:
- 统计范围:
$2 > 5 && $2 < 10
统计第二列在 5~10 之间的行数。 多条件匹配:
awk -F '|' '$2 == 8 && $3 ~ /error/ {count++} END {print count}'
输出详细信息:
awk -F '|' '$2 == 8 {print $0}' filename > result.txt
- 统计范围:
性能优化:
- 处理大文件时,可结合
time
命令或parallel
加速。
- 处理大文件时,可结合
nginx 的负载均衡怎么配置?
回答思路:
基础配置步骤:
定义 upstream 组:
upstream backend { server backend1.example.com weight=3; server backend2.example.com; # 权重默认1 server backup.example.com backup; # 备用节点 }
配置 server 和 location:
server { listen 80; server_name example.com; location / { proxy_pass http://backend; proxy_next_upstream error timeout invalid_header http_500; # 失败重试策略 } }
负载均衡算法:
round_robin
(默认):轮询。ip_hash
:根据客户端 IP 分配,保持会话。least_conn
:最少连接数。
健康检查:
主动健康检查(需 Nginx Plus):
upstream backend { zone backend 64k; server backend1.example.com; health_check; }
- 被动健康检查:通过
proxy_next_upstream
规则剔除故障节点。
高级配置:
- 超时设置:
proxy_connect_timeout 5s;
。 - 会话保持:结合
ip_hash
或 Cookie。
- 超时设置:
验证与测试:
- 使用
curl -I http://example.com
检查响应头的X-Forwarded-For
。 - 模拟节点故障,观察流量切换是否正常。
- 使用
MySQL 主从架构和 redis哨兵 前端是用什么连接的服务,读取数据库中的数据,对数据进行一个应用的?
回答思路:
MySQL 主从架构:
连接方式:
- 前端应用通过主节点写入数据,通过从节点读取(读写分离)。
- 使用连接池(如 HikariCP)管理数据库连接。
注意事项:
- 从库延迟可能导致读写不一致,需通过
read_only
参数控制从库写入。 - 使用中间件(如 MyCat)实现自动路由。
- 从库延迟可能导致读写不一致,需通过
Redis 哨兵模式:
连接方式:
- 客户端连接哨兵集群(如通过 JedisSentinelPool),哨兵自动发现主节点。
高可用机制:
- 哨兵监控主节点,主节点故障时自动选举新主节点。
- 客户端通过哨兵获取最新主节点地址。
应用层设计:
- MySQL:业务逻辑中区分读写操作(如
@Transactional
注解控制)。 - Redis:使用连接池自动处理主从切换,避免手动干预。
- MySQL:业务逻辑中区分读写操作(如
linux 系统调优是怎么进行调优的,对应简历中的性能是怎么调优的?
回答思路:
性能监控工具:
资源监控:
top
/htop
:实时查看 CPU、内存、进程状态。vmstat
:监控内存、swap、IO 等。iostat
:分析磁盘 IO 性能。
- 网络监控:
netstat
,tcpdump
,iftop
。
调优方向:
CPU:
- 优化线程调度(如
nice
调整优先级)。 - 调整内核参数(如
vm.swappiness
控制 swap 使用)。
- 优化线程调度(如
内存:
- 增加
vm.max_map_count
(如 Elasticsearch 需要)。 - 使用
oom_score_adj
防止关键进程被 OOM Killer 终止。
- 增加
IO:
- 调整
read_ahead
缓冲区大小。 - 使用
noatime
挂载选项减少磁盘写入。
- 调整
网络:
- 调整
net.core.somaxconn
扩大连接队列。 - 启用
TCP BBR
拥塞控制算法。
- 调整
实践案例:
- 场景:数据库服务器 CPU 使用率持续 90%。
步骤:
- 通过
perf top
定位热点函数。 - 优化 SQL 查询(添加索引、减少全表扫描)。
- 调整 MySQL 配置(如
innodb_buffer_pool_size
)。
- 通过
- 验证:对比调优前后的
sar
数据,确保性能提升。
自动化监控:
- 结合 Prometheus + Grafana 实时监控关键指标,设置告警阈值。
欢迎关注 ❤
我们搞了一个免费的面试真题共享群,互通有无,一起刷题进步。
没准能让你能刷到自己意向公司的最新面试题呢。
感兴趣的朋友们可以加我微信:wangzhongyang1993,备注:面试群。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。