王中阳Go

第一次,站长亲自招 Gopher 了>>>

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

有疑问加站长微信联系(非本文作者))

618 次点击 ∙ 1 赞

上一篇:极客时间训练营-AI大模型应用开发实战营

下一篇:Springboot+ChatGLM+DeepSeek实战AI数字人面试官系统

prometheus kubernetes nginx 调优

• 编辑
• 预览