phpcms建设网站做网站不赚钱

phpcms建设网站,做网站不赚钱,阿里巴巴国际站入驻,门户网站网站建设前言 三年前第一次听说eBPF#xff0c;觉得这玩意离我太远——内核开发#xff1f;那是神仙干的事。 直到前段时间排查一个诡异的网络延迟问题#xff0c;传统工具都定位不到根因#xff0c;同事甩给我一个bpftrace脚本#xff0c;几秒钟就抓到了问题。那一刻我才意识到觉得这玩意离我太远——内核开发那是神仙干的事。直到前段时间排查一个诡异的网络延迟问题传统工具都定位不到根因同事甩给我一个bpftrace脚本几秒钟就抓到了问题。那一刻我才意识到eBPF已经不是什么高深莫测的东西而是实打实能解决问题的生产力工具。这篇文章是我学习和使用eBPF的一些记录不讲太多底层原理主要聊聊怎么用它解决实际问题。eBPF是什么简单说eBPFextended Berkeley Packet Filter让你可以在内核里安全地运行自定义程序而不需要修改内核源码或加载内核模块。传统的做法要观测内核行为要么改内核重新编译要么写个内核模块。两个方案都很重风险也大。eBPF相当于在内核里开了个沙盒你的程序在里面跑既能访问内核数据又不会把系统搞崩。能干什么网络高性能负载均衡、DDoS防护、流量过滤安全系统调用审计、入侵检测、容器安全观测性能分析、延迟追踪、资源监控调试内核函数追踪、用户态程序分析Cloudflare用eBPF扛DDoSFacebook用它做负载均衡Cilium用它搞容器网络。这东西已经在生产环境大规模使用了。环境准备eBPF需要内核版本支持最低4.x建议5.x以上。Ubuntu 20.04/22.04都没问题。# 检查内核版本uname-r# 5.15.0-91-generic# 安装BCC工具集最常用的eBPF工具集aptupdateaptinstall-y bpfcc-tools linux-headers-$(uname-r)# 安装bpftrace高级追踪语言aptinstall-y bpftrace# 验证安装bpftrace --version# bpftrace v0.14.0实战一追踪系统调用延迟前几天遇到一个问题某个Java服务响应变慢但CPU、内存、IO看着都正常。用bpftrace追踪一下read系统调用的延迟分布# 追踪read调用延迟按进程名过滤bpftrace -e tracepoint:syscalls:sys_enter_read /comm java/ { start[tid] nsecs; } tracepoint:syscalls:sys_exit_read /comm java start[tid]/ { usecs hist((nsecs - start[tid]) / 1000); delete(start[tid]); } 输出usecs: [0] 156 | | [1] 489 || [2, 4) 234 | | [4, 8) 67 | | [8, 16) 23 | | [16, 32) 12 | | [32, 64) 8 | | [64, 128) 3 | | [128, 256) 156 | | -- 异常128-256微秒这个区间的调用数量异常偏多正常应该是单峰分布。进一步追踪发现是读取某个配置文件时文件系统有锁竞争。这种问题用传统工具strace会拖慢进程太多很难快速定位eBPF几乎零开销。实战二网络延迟分析生产环境有台机器TCP延迟偶发飙高网络组说线路没问题。用tcpretrans追踪重传# BCC工具追踪TCP重传/usr/share/bcc/tools/tcpretrans# 输出TIME PID IP LADDR:LPORT TRADDR:RPORT STATE14:23:150410.0.1.5:443 R10.0.2.8:52341 ESTABLISHED14:23:150410.0.1.5:443 R10.0.2.8:52341 ESTABLISHED14:23:160410.0.1.5:443 R10.0.2.8:52341 ESTABLISHED同一个连接连续重传问题缩小到10.0.2.x这个网段。最后查出来是那个机房的交换机有问题。更进一步看TCP连接延迟分布# 追踪TCP连接建立延迟/usr/share/bcc/tools/tcpconnlat# 输出PID COMM IP SADDR DADDR DPORT LAT(ms)1892curl410.0.1.510.0.2.8443245.121893curl410.0.1.510.0.2.8443312.451894curl410.0.1.510.0.3.94431.23对比很明显连10.0.2网段延迟高了两个数量级。实战三进程级资源监控有个容器CPU用量一直很高但top里看不出哪个函数在消耗。用profile工具# CPU采样火焰图数据/usr/share/bcc/tools/profile -p$(pgrep -f myapp)-f30profile.out# 生成火焰图需要安装FlameGraphgitclone https://github.com/brendangregg/FlameGraph ./FlameGraph/flamegraph.pl profile.outcpu.svg火焰图一目了然发现某个JSON解析函数占了40%的CPU。原来是每次请求都在重复解析同一个大配置文件加个缓存解决。实战四自定义追踪点有时候需要追踪特定的内核函数。比如想知道文件打开操作的分布bpftrace -e kprobe:do_sys_openat2 { files[str(arg1)] count(); } interval:s:5 { print(files); clear(files); } 输出每5秒打印一次文件打开统计files[/etc/ld.so.cache]: 234 files[/lib/x86_64-linux-gnu/libc.so.6]: 156 files[/proc/self/status]: 89 files[/app/config.json]: 67 ...这种方式对排查到底谁在频繁读写某个文件特别有用。写个简单的eBPF程序BCC提供Python接口写起来比较方便。追踪所有的execve调用新进程启动#!/usr/bin/env python3frombccimportBPF# eBPF程序C语言prog #include linux/sched.h struct data_t { u32 pid; char comm[TASK_COMM_LEN]; }; BPF_PERF_OUTPUT(events); int trace_execve(struct pt_regs *ctx) { struct data_t data {}; data.pid bpf_get_current_pid_tgid() 32; bpf_get_current_comm(data.comm, sizeof(data.comm)); events.perf_submit(ctx, data, sizeof(data)); return 0; } bBPF(textprog)b.attach_kprobe(event__x64_sys_execve,fn_nametrace_execve)print(追踪新进程启动CtrlC退出...)defprint_event(cpu,data,size):eventb[events].event(data)print(fPID:{event.pid}, COMM:{event.comm.decode()})b[events].open_perf_buffer(print_event)whileTrue:b.perf_buffer_poll()运行效果追踪新进程启动CtrlC退出... PID: 12345, COMM: bash PID: 12346, COMM: ls PID: 12347, COMM: grep这对安全审计很有价值——谁在服务器上执行了什么命令一清二楚。生产环境使用建议性能开销eBPF的开销很低但不是零。几个原则过滤要前置在eBPF程序里做过滤而不是全量采集再在用户态过滤采样而非全量profile用采样不要每个事件都追踪控制输出频率用interval聚合不要每个事件都输出常用工具速查# 性能分析profile# CPU火焰图offcputime# Off-CPU时间分析runqlat# 运行队列延迟# 网络tcplife# TCP连接生命周期tcpretrans# TCP重传追踪tcpconnlat# TCP连接延迟# 磁盘IObiolatency# 块设备IO延迟biosnoop# 块设备IO追踪ext4slower# ext4慢操作# 内存memleak# 内存泄漏检测cachestat# 缓存命中率# 系统调用execsnoop# 进程启动追踪opensnoop# 文件打开追踪多机器批量排查遇到跨多台服务器的问题时需要同时在多个节点运行eBPF工具做对比分析。这种场景下我会用星空组网先把各个网段的机器串起来统一管理后再批量跑诊断脚本比逐台SSH效率高很多。进阶学习资源《BPF Performance Tools》by Brendan Gregg - 这本书是圣经级别的bcc官方仓库github.com/iovisor/bcc - 大量现成工具和示例bpftrace参考github.com/iovisor/bpftrace - 追踪语言文档Cilium eBPF教程docs.cilium.io - 网络方向的最佳实践总结eBPF不再是内核黑客的专属玩具。对于运维和后端开发来说它是一个威力巨大的问题排查工具低开销生产环境可用高精度内核级别的观测能力灵活可以自定义追踪逻辑安全内核保证程序不会搞崩系统从BCC工具集入手遇到问题先试试现成工具熟练后再尝试写自定义追踪程序。这个学习路径比较平滑。说实话用惯了eBPF再回头看传统的排查手段会觉得效率差太多。推荐每个做服务端的同学都了解一下。