繼續分享最新的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
進行服務發現。 - 示例配置:
- Prometheus 通過 Kubernetes API 監控集群資源狀態(如 Pod、Deployment、Node 等),需配置
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
采集。 - 示例:
- 提供 Pod、Node 的資源使用指標(如 CPU/內存使用率),需通過
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
)將告警分發到不同接收者。
- 路由(Routes):根據標簽(如
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:
- 實踐案例:
- 場景:數據庫服務器 CPU 使用率持續 90%。
- 步驟:
- 通過
perf top
定位熱點函數。 - 優化 SQL 查詢(添加索引、減少全表掃描)。
- 調整 MySQL 配置(如
innodb_buffer_pool_size
)。
- 通過
- 驗證:對比調優前后的
sar
數據,確保性能提升。
- 自動化監控:
- 結合 Prometheus + Grafana 實時監控關鍵指標,設置告警閾值。
歡迎關注 ?
我們搞了一個免費的面試真題共享群,互通有無,一起刷題進步。
沒準能讓你能刷到自己意向公司的最新面試題呢。
感興趣的朋友們可以私信我,備注:面試群。