继续分享最新的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%）。
• 数据采集：
  • 拉取模式（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]  

• Metrics Server：
  • 提供 Pod、Node 的资源使用指标（如 CPU/内存使用率），需通过 kube-state-metrics 或 cAdvisor 采集。
  • 示例：

    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 文件中定义规则，例如：

    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
  • 功能：
    1. 接收 Prometheus 发送的告警事件。
    2. 根据配置路由规则将告警分发给接收者（如团队 Slack 频道）。
    3. 聚合相似告警，减少重复通知（如 group_by）。
    4. 抑制冗余告警（如主节点宕机时抑制其下所有服务的告警）。
  • 配置文件示例：

    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 流水线发现问题是怎么排查解决的？

回答思路：

• 分层排查法：
  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 命令：

  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 的负载均衡怎么配置？

回答思路：

• 基础配置步骤：
  1. 定义 upstream 组：

     upstream backend {  
       server backend1.example.com weight=3;  
       server backend2.example.com;  # 权重默认1  
       server backup.example.com backup;  # 备用节点  
     }  

2. 配置 server 和 location：

     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）：

    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 实时监控关键指标，设置告警阈值。

---

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以私信我，备注：面试群。