从零构建可交付AI工程基座：系统稳定性与可观测性实践

1. 这不是调包是亲手搭起AI工程的骨架“AI Engineering from Scratch”——看到这个标题很多人第一反应是又要从零写Transformer不完全不是。我做AI工程落地超过八年带过二十多个工业级项目从智能客服引擎到制药分子生成平台真正让我反复踩坑、也反复验证有效的“从零开始”从来不是重造算法轮子而是从零构建一个能稳定交付、可维护、可演进的AI系统工程基座。它不依赖某个明星框架的黑盒封装不靠魔改几个config就宣称“全栈AI”而是像盖一栋楼地基怎么打数据管道、承重墙怎么立模型服务架构、水电怎么布监控告警与可观测性、门窗怎么装API网关与权限控制——每一处都得亲手选材、测算、校准、加固。核心关键词“AI Engineering”和“from scratch”在这里不是修辞是方法论锚点。AI Engineering 指的是把AI当作一个需要版本管理、CI/CD、SLO保障、故障回滚能力的软件工程对象而非一次性的Jupyter Notebook实验from scratch 则意味着拒绝“pip install xxx copy-paste demo”式启动而是从Linux内核参数、Docker镜像分层、Kubernetes资源配额这些底层开始推演设计。它适合三类人一是刚从算法岗转工程岗的同事急需补上生产环境那堵看不见的墙二是技术负责人正为团队模型上线周期长达3周、线上OOM频发、AB测试无法归因而头疼三是独立开发者想用最小成本跑通一个端到端可商用的AI服务而不是在Colab里调通一个demo就止步。我去年帮一家区域银行重构其反欺诈模型服务时就是彻底执行了这套“from scratch”路径。他们原有方案是算法同学本地训练好模型导出ONNX运维手动拷贝到服务器用Flask简单封装成API没有日志结构化、没有请求采样、没有延迟熔断。结果一次促销活动期间QPS涨了4倍服务直接雪崩排查花了17小时——最后发现是Python GIL锁死内存泄漏叠加而监控面板上只显示“503 Service Unavailable”。我们花6周时间从内核vm.swappiness调优开始一层层重建用Rust重写预处理流水线、用Triton部署多GPU推理、用OpenTelemetry统一埋点、用PrometheusGrafana搭建SLO看板。上线后P99延迟从2.3秒压到380msSLO达标率从62%提升至99.95%。这不是炫技是让AI真正成为业务可信赖的基础设施。下面我就把这整套骨架拆开揉碎一砖一瓦讲清楚。2. 整体设计逻辑为什么必须放弃“一键部署”幻觉2.1 从三个真实故障倒推架构设计原则所有“from scratch”的起点不是画架构图而是复盘故障。我在过去三年记录的137个AI服务线上事故中前三大根因高度一致数据漂移未感知占比31%某推荐系统在双十一大促期间CTR骤降40%查了一天日志才发现上游数仓ETL任务失败特征生成停摆2小时但服务无任何告警继续用过期特征打分资源争抢不可控占比28%同一台GPU服务器上部署了3个模型服务A服务突发流量导致显存占满B、C服务全部OOM退出但K8s只重启Pod未隔离资源故障扩散版本混乱难回滚占比22%算法同学提交了v2.1模型但运维部署时误用了v2.0的预处理代码输入格式错位输出全是NaN而日志里没有任何版本标识定位耗时5小时。这三个问题恰恰暴露了“一键部署”工具链的根本缺陷它们默认假设环境纯净、依赖稳定、变更受控——而现实中的生产环境永远是混沌的。因此“from scratch”的设计哲学第一条就是主动拥抱不确定性把防御机制刻进每一层。比如数据层我们不追求“实时流式处理”的高大上而是坚持“双通道”设计主通道走KafkaSpark Streaming保证吞吐旁路通道用Filebeat监听特征存储目录变更一旦检测到文件mtime异常如ETL中断立即触发告警并切换到备用特征快照。这个设计增加不了性能但让“数据漂移”从“事后追查”变成“事中拦截”。再如资源层我们放弃K8s原生的resources.limits粗粒度控制转而采用NVIDIA DCGM cgroups v2深度绑定为每个模型服务分配独立的GPU MIG实例若硬件支持或通过nvidia-smi -c 3设置计算模式并用systemd-run --scope -p MemoryLimit4G硬限制内存。实测下来当A服务显存爆满时B服务完全不受影响因为它们根本不在同一个GPU上下文里。版本管理更是贯穿始终。我们规定任何可执行单元模型、预处理脚本、后处理逻辑必须携带SHA256哈希值且该哈希必须嵌入HTTP响应头X-Model-Hash和Prometheus指标标签model_hash中。这样当监控发现延迟飙升运维只需查rate(http_request_duration_seconds_sum{model_hashxxx}[5m])就能精准定位是哪个版本引入的问题回滚不再是“猜版本号”而是git checkout对应commit后重新build镜像。2.2 四层解耦让每个模块都能独立演进“from scratch”最忌讳的就是“大单体”。我见过太多团队把数据清洗、模型推理、结果缓存、AB分流全塞进一个Flask应用里结果改个缓存策略就得全量回归测试。我们采用严格四层解耦接入层Ingress Layer仅负责TLS终止、WAF规则、请求限流用Envoy实现令牌桶不做任何业务逻辑编排层Orchestration Layer用Tempo非Jaeger做分布式追踪用Argo Workflows调度离线任务但绝不参与在线推理——这是关键分界线服务层Serving Layer每个模型独立部署为gRPC服务强制要求实现HealthCheck和GetModelInfo接口返回当前加载的模型路径、哈希、输入输出schema数据层Data Layer分为热数据Redis Cluster存用户实时行为、温数据MinIO存特征快照、冷数据S3存原始日志三者物理隔离访问协议不同。这种解耦带来两个直接好处一是升级模型时只需滚动更新服务层Pod接入层和编排层完全不动二是当某模型因数据问题失效编排层可自动降级到规则引擎而不会拖垮整个API网关。去年我们替换一个OCR模型时从灰度发布到全量切换业务方完全无感因为所有路由、鉴权、限流逻辑都在接入层完成服务层只是“插拔式”更换。2.3 成本与效能的硬约束为什么不用最新GPU、不追最热框架很多团队一上来就买A100、上PyTorch 2.0、搞FP16混合精度结果发现80%的请求根本用不到GPU算力。我们在设计之初就设下两条铁律算力匹配律模型FLOPs必须≤目标GPU峰值算力的60%。例如一个BERT-base模型在A10上理论推理吞吐是1200 QPS但我们只按720 QPS设计预留30%余量应对特征维度波动和网络抖动框架收敛律只选用已发布稳定版≥6个月的框架核心组件。比如Triton我们用23.04版2023年4月发布而非最新的24.07ONNX Runtime用1.162023年10月发布而非1.18。理由很简单新版本可能修复了你没遇到的bug但也可能引入你马上会踩的坑。我们曾因升级Triton到23.07导致INT8量化模型精度掉点0.3%回滚耗时2天——而老版本虽少两个feature但文档齐全、社区案例多、问题可预期。这种“保守主义”不是拒绝创新而是把创新成本显性化。我们专门设立“沙盒集群”所有新框架、新硬件都在这里跑3个月压力测试模拟百万级QPS、注入随机网络延迟、强制GPU降频达标后才准入生产。这看似慢实则快——避免了线上救火的隐性成本。3. 核心细节拆解从内核参数到HTTP头的全链路控制3.1 Linux内核调优让AI服务不再被系统“背刺”AI服务对OS层的敏感度远超普通Web服务。一个没调优的Ubuntu 22.04默认配置会让你的TensorRT模型推理延迟波动高达±40%。我们从五个关键参数入手vm.swappiness1AI服务内存压力大但绝不能让内核轻易swap到磁盘。设为1表示“只在绝对必要时swap”避免GPU显存映射页被换出net.core.somaxconn65535解决高并发下“Connection refused”问题。默认值128在QPS500时就会丢连接fs.file-max2097152单机最大文件句柄数。一个gRPC服务常驻连接日志文件临时文件轻松突破10万kernel.pid_max4194304避免fork炸弹或高并发创建进程时PID耗尽。默认32768对多Worker服务远远不够vm.dirty_ratio15控制脏页写回时机。设为15%而非默认30%防止批量写特征文件时触发同步刷盘卡住主线程。这些参数不是凭空设定。我们用stress-ng --vm 4 --vm-bytes 2G --timeout 60s模拟内存压力同时用perf record -e syscalls:sys_enter_write -a sleep 30抓取write系统调用观察vm.dirty_ratio变化对write()延迟的影响。实测发现当dirty_ratio从30%降到15%P99 write延迟从12ms降至3ms这对实时特征写入至关重要。提示所有内核参数必须写入/etc/sysctl.d/99-ai-engineering.conf而非临时sysctl -w。否则容器重启后失效。我们用Ansible playbook统一推送确保集群一致性。3.2 Docker镜像分层如何让镜像体积减少60%、启动快3倍一个典型的PyTorchTransformers镜像动辄3GB拉取耗时、存储成本、安全扫描都成问题。我们的分层策略是“三层四阶段”层级内容构建命令示例复用率Base LayerUbuntu 22.04 CUDA 11.8 cuDNN 8.6FROM nvidia/cuda:11.8.0-devel-ubuntu22.0490%半年一更Runtime LayerPython 3.10 PyTorch 2.0.1 Triton 23.04RUN pip install torch2.0.1cu118 ...70%季度一更App Layer模型权重 预处理代码 gRPC服务框架COPY model/ /app/model/COPY src/ /app/src/10%每次发布关键技巧在于Runtime Layer必须用--no-cache-dir和--find-links指向内部PyPI镜像避免pip每次重新解析依赖树App Layer的模型文件用COPY --frombuilder多阶段构建先在builder容器里用aws s3 cp下载再COPY --frombuilder复制不把S3凭证塞进最终镜像。我们还强制要求所有.so动态库用strip --strip-unneeded瘦身Python字节码用python -m compileall -b -f预编译.pyc文件保留但删除.py源码用find /app -name *.py -delete。最终一个含BERT-large的镜像从3.2GB压到1.2GBdocker pull时间从2分17秒降至28秒docker run启动时间从11秒降至3.5秒——这对蓝绿部署的RTO恢复时间目标提升巨大。3.3 gRPC服务契约定义比实现更重要很多团队把gRPC当HTTP用只定义一个Predict方法结果后期扩展AB测试、多模型路由时痛苦不堪。我们强制采用“四接口契约”service ModelService { // 1. 健康检查供K8s liveness probe rpc HealthCheck(HealthCheckRequest) returns (HealthCheckResponse); // 2. 元信息查询供监控和调试 rpc GetModelInfo(GetModelInfoRequest) returns (GetModelInfoResponse); // 3. 主推理接口支持流式和批式 rpc Predict(PredictRequest) returns (PredictResponse); rpc PredictStream(stream PredictRequest) returns (stream PredictResponse); // 4. 特征诊断接口专用于数据漂移分析 rpc DiagnoseFeatures(DiagnoseFeaturesRequest) returns (DiagnoseFeaturesResponse); }其中DiagnoseFeatures是杀手级设计。它接收原始输入如用户点击序列返回该输入经预处理后的特征向量、各特征统计值均值、方差、缺失率、与训练集分布的KL散度。运维可在Prometheus里直接画model_feature_kl_divergence{featureuser_age}曲线一旦KL0.3自动触发告警。这比等线上指标下跌后再排查提前了至少2小时。注意所有proto文件必须用protoc-gen-validate插件生成校验代码PredictRequest里每个字段都加[(validate.rules).float.gt 0]等约束。我们曾因一个confidence_threshold字段未校验被恶意请求传入负数导致模型返回全0而服务层毫无感知。3.4 HTTP网关集成让AI服务天然支持Web生态尽管核心是gRPC但前端、移动端、第三方系统仍需HTTP。我们不用gRPC-Gateway那种自动生成的胶水层而是手写轻量级转换器原因有三一是gRPC-Gateway的JSON映射规则复杂易出错二是它无法处理gRPC流式响应到HTTP Server-Sent Events的转换三是它把所有错误都转成500丢失了gRPC的丰富状态码。我们的转换器只有200行Go代码核心逻辑是将HTTP POST/v1/predict的JSON body用jsoniter.Unmarshal解析再用protojson.Unmarshal转成gRPC request调用gRPC client捕获status.Code映射为HTTP状态码OK→200,INVALID_ARGUMENT→400,NOT_FOUND→404,RESOURCE_EXHAUSTED→429对于流式请求HTTP响应头设Content-Type: text/event-stream每收到一个gRPC流消息就写data: {json}\n\n。最关键的是错误透传当gRPC返回status.Error(codes.InvalidArgument, feature age out of range [0,120])HTTP响应Body就是{error: feature age out of range [0,120], code: 400}前端可直接提取error字段做用户提示无需二次解析。4. 实操全流程从零构建一个可上线的文本分类服务4.1 环境准备最小可行集群的搭建我们不假定你有K8s集群。最小可行环境只需一台32GB内存、2×RTX 4090的物理机或云服务器用Docker Compose编排# docker-compose.yml version: 3.8 services: # 接入层Envoy代理 envoy: image: envoyproxy/envoy:v1.26-latest volumes: - ./envoy.yaml:/etc/envoy/envoy.yaml ports: - 8080:8080 - 9901:9901 # Admin interface # 服务层文本分类模型 text-classifier: build: ./text-classifier environment: - MODEL_PATH/models/bert-base-chinese-finetuned - GPU_DEVICE0 deploy: resources: limits: memory: 12G devices: - driver: nvidia count: 1 capabilities: [gpu] volumes: - ./models:/models:ro # 数据层MinIO对象存储存特征快照 minio: image: minio/minio:latest command: server /data --console-address :9001 environment: - MINIO_ROOT_USERminioadmin - MINIO_ROOT_PASSWORDminioadmin ports: - 9000:9000 - 9001:9001 volumes: - ./minio-data:/data注意text-classifier的deploy.resources配置devices字段明确指定使用1块GPU避免容器启动时抢占全部GPU。我们实测过若不加此限制Docker会默认把所有GPU设备挂载进去即使你只用1块nvidia-smi仍显示显存被占满。4.2 模型服务开发Triton 自定义Backend的组合拳Triton虽好但对中文分词、特殊tokenization支持弱。我们的方案是Triton作为推理引擎预处理/后处理用Python Backend自定义。目录结构text-classifier/ ├── config.pbtxt # Triton模型配置 ├── 1/ # 版本目录 │ ├── model.py # 自定义Python Backend │ └── model.onnx # ONNX格式模型 └── preprocess/ # 预处理代码独立于Triton ├── tokenizer.py └── feature_engineer.pyconfig.pbtxt关键配置name: text_classifier platform: onnxruntime_onnx max_batch_size: 32 input [ { name: input_ids data_type: TYPE_INT64 dims: [ -1, 512 ] } ] output [ { name: logits data_type: TYPE_FP32 dims: [ -1, 3 ] # 3分类 } ] # 启用Python Backend做前后处理 dynamic_batching [ { max_queue_delay_microseconds: 10000 } ]model.py核心逻辑import numpy as np import json from transformers import BertTokenizer from preprocess.tokenizer import load_tokenizer class TextClassifier: def __init__(self, model_path): self.tokenizer load_tokenizer(model_path) # 加载本地tokenizer def execute(self, requests): responses [] for request in requests: # 从request获取原始文本 input_text request.input(text).as_numpy()[0].decode(utf-8) # 自定义分词绕过Triton的局限 inputs self.tokenizer( input_text, truncationTrue, paddingmax_length, max_length512, return_tensorsnp ) # 构造Triton输入 input_ids inputs[input_ids].astype(np.int64) attention_mask inputs[attention_mask].astype(np.int64) # 调用Triton推理 result self.triton_client.infer( model_nametext_classifier, inputs[infer_input(input_ids, input_ids), infer_input(attention_mask, attention_mask)] ) # 后处理Softmax label mapping logits result.as_numpy(logits)[0] probs softmax(logits) label_id np.argmax(probs) label_name [positive, neutral, negative][label_id] # 构造响应 response pb_utils.InferenceResponse( output_tensors[ pb_utils.Tensor(label, np.array([label_name], dtypeobject)), pb_utils.Tensor(confidence, np.array([probs[label_id]], dtypenp.float32)) ] ) responses.append(response) return responses这个设计让Triton专注算力密集的矩阵运算而把NLP领域复杂的文本处理交给更灵活的Python。实测下来相比纯Python服务QPS从180提升到850P99延迟从120ms降至45ms。4.3 监控告警体系用OpenTelemetry统一观测我们不用Prometheus直接抓取Triton指标它暴露的指标太粗而是用OpenTelemetry SDK在服务层埋点# 在model.py的execute方法中 from opentelemetry import trace from opentelemetry.exporter.prometheus import PrometheusMetricReader from opentelemetry.sdk.metrics import MeterProvider # 初始化Meter reader PrometheusMetricReader() provider MeterProvider(metric_readers[reader]) meter provider.get_meter(text-classifier) # 定义指标 request_count meter.create_counter( http.request.count, descriptionTotal number of requests ) inference_latency meter.create_histogram( inference.latency, descriptionInference latency in milliseconds ) def execute(self, requests): start_time time.time() try: # ... 推理逻辑 ... request_count.add(1, {model: bert-base-chinese, status: success}) except Exception as e: request_count.add(1, {model: bert-base-chinese, status: error}) raise finally: latency_ms (time.time() - start_time) * 1000 inference_latency.record(latency_ms, {model: bert-base-chinese})Prometheus配置抓取/metrics端点Grafana看板包含三个核心SLO仪表盘可用性Availability1 - rate(http_request_duration_seconds_count{code~5..}[1h]) / rate(http_request_duration_seconds_count[1h])目标99.95%延迟Latencyhistogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1h]))目标100ms质量Qualityrate(model_prediction_error_count{error_typedata_drift}[1h])目标0.1%当model_prediction_error_count突增看板自动关联feature_kl_divergence指标 pinpoint到具体哪个特征漂移——这才是真正的可观测性不是堆砌图表。4.4 CI/CD流水线GitOps驱动的模型发布我们用GitHub Actions Argo CD实现GitOps# .github/workflows/deploy.yml name: Deploy Model on: push: branches: [main] paths: - models/** - src/** jobs: build-and-push: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Build and push Docker image uses: docker/build-push-actionv5 with: push: true tags: ${{ secrets.REGISTRY }}/text-classifier:${{ github.sha }} cache-from: typeregistry,ref${{ secrets.REGISTRY }}/text-classifier:latest cache-to: typeregistry,ref${{ secrets.REGISTRY }}/text-classifier:latest,modemax deploy-to-cluster: needs: build-and-push runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Deploy with Argo CD uses: argoproj-labs/argocd-actionv2 with: argocd_url: ${{ secrets.ARGOCD_URL }} argocd_username: ${{ secrets.ARGOCD_USERNAME }} argocd_password: ${{ secrets.ARGOCD_PASSWORD }} application: text-classifier sync_option: --prune --force sync_policy: automated关键点在于sync_option: --prune --force它确保K8s集群状态与Git仓库完全一致删掉Git里没有的旧Pod强制更新所有资源。我们曾因手动kubectl edit修改了Deployment副本数导致Git状态与实际不符Argo CD一直报OutOfSync直到执行prune才恢复。这强迫团队所有变更必须走Git杜绝“线下操作”。5. 常见问题与实战排障那些文档里不会写的坑5.1 GPU显存“神秘增长”不是内存泄漏是CUDA上下文残留现象服务运行24小时后nvidia-smi显示显存占用从1.2GB涨到3.8GB但torch.cuda.memory_allocated()只显示1.5GB重启Pod后回落。根因PyTorch的CUDA上下文在多线程环境下未正确清理。当一个Worker线程异常退出其持有的CUDA context未释放显存被标记为“used but not allocated”。解决方案在服务启动时强制设置CUDA_LAUNCH_BLOCKING1仅调试用并添加显式context清理import torch import gc def cleanup_cuda(): if torch.cuda.is_available(): torch.cuda.empty_cache() # 清空缓存 gc.collect() # 强制Python垃圾回收 # 关键重置CUDA状态 torch.cuda.reset_peak_memory_stats() torch.cuda.synchronize() # 在每个推理请求结束后调用 cleanup_cuda()更彻底的方案是用multiprocessing替代threading。每个推理请求在一个独立进程中执行进程退出时操作系统自动回收所有GPU资源。虽然进程创建开销略大但杜绝了context残留是我们生产环境的标配。5.2 Triton模型加载失败90%是因为ONNX的opset版本不兼容现象Triton日志报Failed to load model text_classifier due to error: onnxruntime::OnnxRuntimeException: Non-zero status code returned while running Node: Gather_123 ...。根因ONNX模型导出时用了opset_version15但Triton 23.04内置的ONNX Runtime只支持到opset 14。排查步骤用onnx.shape_inference.infer_shapes(model)检查模型shape是否完整用onnx.checker.check_model(model)验证模型有效性用onnx.version_converter.convert_version(model, 14)降级opset。我们固化了一个检查脚本#!/bin/bash # check-onnx.sh onnx-checker $1 || exit 1 opset$(python -c import onnx; monnx.load($1); print(m.opset_import[0].version)) if [ $opset -gt 14 ]; then echo OPSET $opset 14, converting to 14... python -c import onnx from onnx import version_converter m onnx.load($1) m_converted version_converter.convert_version(m, 14) onnx.save(m_converted, $1.v14.onnx) fi5.3 gRPC连接“假死”TCP Keepalive没配防火墙悄悄断连现象服务运行正常但客户端偶尔报StatusCode.UNAVAILABLE: failed to connect to all addresses重启客户端即恢复。根因云服务商的SLB负载均衡器默认60秒无数据交互就断开TCP连接而gRPC长连接未启用Keepalive。解决方案在客户端和服务端都配置Keepalive# 客户端 channel grpc.insecure_channel( localhost:50051, options[ (grpc.keepalive_time_ms, 30000), # 每30秒发一次keepalive (grpc.keepalive_timeout_ms, 10000), # 10秒超时 (grpc.keepalive_permit_without_calls, 1), # 即使无调用也发送 ] ) # 服务端Triton配置 # config.pbtxt 中添加 parameters [ { key: grpc_keepalive_time_ms value: 30000 } ]实测下来配置后连接断开率从每小时3.2次降至0.01次。5.4 特征漂移告警“狼来了”阈值设置不当导致噪音现象feature_kl_divergence每天凌晨3点固定报警持续10分钟但业务无异常。根因凌晨是数仓ETL窗口期特征计算用的是上一小时快照而实时流数据仍在写入造成瞬时分布偏移。解决方案动态阈值 时间窗口过滤。我们用Prometheus的avg_over_time函数计算7天历史KL散度的P95值作为基线# 告警规则 - alert: FeatureDriftHigh expr: | avg_over_time(model_feature_kl_divergence[7d]) * 2 model_feature_kl_divergence and ignoring(job) hour() ! 3 # 过滤凌晨3点 for: 5m labels: severity: warning同时在DiagnoseFeatures接口里加入ignore_outliers: bool参数对离群值做Winsorize处理避免单条异常数据拉高KL值。实操心得所有告警必须附带“一键诊断”链接。点击告警自动跳转到Grafana看板预加载model_feature_kl_divergence{featureuser_age}[2h]和feature_missing_rate{featureuser_age}[2h]对比图。运维不用切屏、不用查日志30秒内定位是数据缺失还是分布偏移。6. 我的体会from scratch不是重复造轮子是夺回控制权做完这个项目我最大的体会是“from scratch”这个词被严重误解了。它不是让你从汇编开始写CUDA kernel也不是拒绝所有开源工具。它的本质是夺回对AI系统每一个决策点的控制权——当Triton升级导致精度下降你能立刻回滚到已验证版本当特征存储格式变更你能用旁路通道无缝切换当线上出现诡异延迟你能从/proc/pid/stack里看到真实的内核栈而不是对着黑盒日志干瞪眼。这种控制权带来的不是开发速度的提升而是故障恢复速度的指数级提升。我们团队现在平均MTTR平均修复时间是11分钟其中8分钟花在定位3分钟花在执行。而之前用“一键部署”方案时MTTR是4.7小时。差距不在技术多先进而在你是否真的理解每一层发生了什么。最后分享一个小技巧每周五下午留出1小时随机挑一个生产Pod执行kubectl exec -it pod -- sh然后手动跑一遍curl -X POST http://localhost:8000/v1/predict -d {text:hello}。不是为了测试功能而是感受这个服务真实的呼吸节奏——网络延迟、磁盘IO、CPU调度。你会惊讶地发现很多“性能问题”其实源于你对生产环境的陌生感。真正的工程能力永远生长在你亲手触摸过的每一行日志、每一个top输出、每一次strace跟踪里。