可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载Pixie 在仓库中开源了其全部 PxLPixie Language脚本它们既是可直接在集群上运行的观测预设也是学习 PxL 脚本语言的最佳范例。本文以仓库中自动生成的 src/pxl_scripts/README.md 为主干完整梳理四个脚本目录下的全部脚本清单并结合manifest.yaml、.pxl源码、vis.json可视化配置以及 Makefile / Bazel 打包链路讲解如何理解、运行、打包乃至编写自己的 PxL 脚本。读完本文你将掌握 Pixie 脚本仓库的整体地图、单个脚本的三件套组成、eBPF 内核级追踪脚本的实现模式以及从本地开发到 bundle 产物验证的完整工作流。1. 仓库定位开源在仓库中的 PxL 脚本集src/pxl_scripts/README.md 的定位非常明确Pixie 将其全部脚本开源作为使用 PxL 语言编写脚本的示例。PxL 是 Pixie 自有的查询脚本语言用于在集群上声明式地定义数据采集、转换与聚合逻辑这些脚本既可以通过pxCLI 直接执行也可以在 Pixie UI 中作为Live View实时视图渲染为表格、时间序列与图表。需要注意该 README 并非手写维护文件首行即注明The text in this file is automatically generated by the update_readme.py script因此脚本清单始终与仓库实际目录保持同步。对应的生成器是 update_readme.py维护者只需在脚本目录内执行make update_readme即可重新生成详见第 7 节。2. 目录结构与单个脚本的三件套组成脚本仓库顶层分为四个脚本目录这一划分在 Makefile 的dirs : bpftrace px pxbeta sotw中有明确体现目录定位脚本数量按 README 清单统计bpftrace基于 eBPF/bpftrace 的内核级追踪脚本安全能力检查、TCP 丢包、OOM 等10px面向应用与集群的可观测性主目录HTTP/SQL/网络/资源/火焰图等 Live View67pxbeta实验性/预览脚本PII 出口、service 端点视图、VFS 追踪等4sotw按需state-of-the-worldDNS 查询脚本2合计 83 个脚本且每个脚本目录都由固定三件套构成。以 px/pod 为例manifest.yaml脚本元数据包含short与long两段描述README 中的每行简介即取自long字段pod.pxlPxL 语言编写的实际脚本逻辑vis.jsonLive View 的可视化定义输入变量、全局函数与图表布局。bpftrace 目录下的脚本略有差异例如 bpftrace/tcp_drops 由data.pxlmanifest.yamlvis.json组成其中数据源不是普通的 PxL 表查询而是通过pxtrace.TraceProgram内嵌 bpftrace 程序动态注册内核探针。3. 脚本全清单README 核心内容完整继承以下清单完整覆盖 src/pxl_scripts/README.md 中列出的全部脚本描述与仓库保持一致的语义并附带仓库内相对路径便于逐一深入。3.1 bpftrace内核级 eBPF 追踪脚本10 个脚本功能capable追踪内核cap_capable()函数的调用即安全能力检查dc_snoop追踪目录项缓存dcache的查找exec_snoop追踪系统 exec 事件md_flush在 md 驱动层追踪 flush 操作并打印细节nap_time通过nanosleep(2)系统调用追踪应用睡眠oom_kill追踪 Linux 内存溢出OOM杀手每次 OOM 以一行输出基本信息socket_size展示 socket I/O 请求的信息与大小统计sync_snoop追踪文件系统 sync 事件tcp_drops展示集群中的 TCP 丢包计数tcp_retransmits展示集群中的 TCP 重传计数3.2 px应用与集群可观测性脚本67 个集群 / 节点 / 命名空间 / 工作负载视图脚本功能cluster列出当前集群可用的命名空间与节点namespaces列出集群命名空间及其 Pod/Service 数量以及各命名空间的高层资源消耗namespace给定命名空间的顶层汇总Pod、Service 列表与服务拓扑图nodes逐节点汇总进程与网络统计CPU、内存、网络流量并列出窗口期内的 Podnode单个节点的进程与网络统计汇总含窗口期内该节点的 Pod 列表pods给定命名空间中 Pixie 监控的 Pod 列表含应用指标延迟、错误率、RPS与资源使用CPU、写、读pod单个 Pod 的概览应用指标与资源使用services命名空间中各 Service 的请求统计概览service单个 Service 的请求统计概览agent_status获取所有 Pixie AgentPEM/采集器的运行状态agent_status_diagnostics对 AgentPEM/采集器状态执行诊断网络与连接脚本功能network_stats获取网络统计时间序列net_flow_graph指定命名空间中 k8s Pod 的所有出站连接映射inbound_conns列出源自集群外端点的连接outbound_conns列出指向集群外端点的连接ip展示集群到指定 IP 地址的流量汇总dns_data展示集群中的 DNS 流量样本dns_flow_graph集群 DNS 请求概览含延迟统计dns_query_summary按解析名称与成功率分组的命名空间内 Pod 的 DNS 查询概览HTTP 与请求链路脚本功能http_data展示集群中最新的 HTTP 消息http_data_filtered按 Service、Pod、请求路径与响应状态码过滤的 HTTP 请求样本http_post_requests展示集群中方法为 POST 的 HTTP 请求样本http_request_stats按 Service 聚合的 HTTP 请求统计http_trace_id展示集群中带 trace ID 的 HTTP 请求可配置承载 trace ID 的请求头并按 trace ID 过滤largest_http_request按传入的过滤条件计算最大的 HTTP 请求most_http_data找出特定 Pod 上传输 HTTP 数据最多的端点可取消注释按 Service/端点对汇总slow_http_requests按 Service 展示慢请求样本pod_edge_stats获取 Pod 相对另一 Service 的延迟、错误率与吞吐可编辑 requestor 过滤器并以三条时间序列图展示service_edge_stats获取 Service 相对另一 Service 的延迟、错误率与吞吐三条时间序列图展示数据库与消息队列协议脚本功能mysql_data展示集群中最新的 MySQL 消息mysql_flow_graph集群 MySQL 消息拓扑图含延迟统计mysql_stats实时计算 Pod 的 MySQL 请求延迟、错误率与吞吐pgsql_data展示集群中最新的 PostgreSQL 消息pgsql_flow_graph集群 PostgreSQL 消息拓扑图含延迟统计pgsql_stats实时计算 Pod 的 PostgreSQL 请求延迟、错误率与吞吐cql_data展示集群中的 CQLCassandra请求样本cql_flow_graph集群 Cassandra 消息拓扑图含延迟统计cql_stats实时计算 Pod 的 CQLCassandra请求延迟、错误率与吞吐redis_data展示集群中的 Redis 消息样本redis_flow_graph集群 Redis 消息拓扑图含延迟统计redis_stats实时计算 Pod 的 Redis 请求延迟、错误率与吞吐mongodb_data展示集群中最新的 MongoDB 消息sql_queries实时计算每条归一化 SQL 查询的延迟、错误率与吞吐仅支持 PostgreSQL 与 MySQLsql_query实时计算给定归一化 SQL 查询的每个参数集的延迟、错误率与吞吐仅支持 PostgreSQL 与 MySQLamqp_data展示集群中的 AMQP 消息样本kafka_data展示集群中的 Kafka 消息样本kafka_overviewKafka 集群概览kafka_consumer_rebalancing可视化最近的 Kafka 消费者再平衡事件及延迟kafka_producer_consumer_latency展示指定 Topic 的生产者-消费者延迟大于 0 表示消费者落后于生产者nats_data展示集群中最新的 NATS 消息mux_data展示集群中最新的 Mux 流量性能、资源与火焰图脚本功能perf_flamegraph展示堆栈采样定位应用耗时位置differential_flamegraph差分 CPU 火焰图用于对比不同部署、不同容器实例间的代码路径变化jvm_data集群上 Java 进程的 JVM 统计jvm_stats按 Pod 返回 JVM 统计可按节点过滤pid_memory_usage获取 k8s 集群中所有进程的虚拟内存使用与平均内存pod_memory_usage获取 k8s 集群中所有进程的虚拟内存使用与平均内存Pod 视角pod_lifetime_resourcePod 全生命周期内的总资源使用service_resource_usage按 Service 获取平均 Pod CPU、Pod 内存、HTTP 吞吐与延迟collect_agent_heaps用于调试 Kelvin 与 PEM 内存占用的脚本系统信息、调试与内部指标脚本功能funcs列出 Pixie 中所有可用的函数schemas获取系统中所有表的 schemaupids展示给定命名空间中运行的 UPID 列表tracepoint_status返回集群上正在运行的 tracepoint 信息stirling_errors展示 Stirling 各组件中的错误以及 eBPF 探针的部署状态pixie_quality_metrics对 Pixie 采集器数据进行采样的质量指标3.3 pxbeta实验性脚本4 个脚本功能pii_cluster_egress展示集群流向外部端点、包含 PII 的流量汇总service_endpoint单个 Service 的单个端点请求统计概览service_endpointsService 各端点的请求统计概览vfs_snoop追踪文件写入与删除3.4 sotw按需 DNS 查询脚本2 个脚本功能dns_external_fqdn_list在指定时间窗内从集群全部 DNS 流量中列出外部完全限定域名FQDNdns_queries_filtered按指定查询名过滤并列出所有 DNS 查询4. 源码级剖析一个典型 PxL 脚本的三件套以 px/pod 为例看单个脚本如何从元数据、代码到可视化配置协同工作。manifest.yaml提供了脚本的元数据README 生成的描述即取自long字段manifest.yamlshort: Pod Overview long: - Overview of a specific Pod monitored by Pixie with its high level application metrics (latency, error-rate rps) and resource usage (cpu, writes, reads).脚本本体 pod.pxl 展示了 PxL 的典型写法脚本头部的 docstring 与manifest.yaml描述呼应随后定义可调参数例如window_ns px.DurationNanos(10 * ns_per_s)决定time_列的聚合窗口filter_unresolved_inbound、filter_health_checks、filter_ready_checks三个布尔开关分别控制是否过滤掉无法解析来源 IP 的请求、健康检查与就绪检查流量。脚本主体按功能拆分为containers(start_time, pod)、node(start_time, pod)等函数例如df px.DataFrame(tableprocess_stats, start_timestart_time) df df[df.ctx[pod] pod] df.name df.ctx[container_name] df.id df.ctx[container_id] df df.groupby([name, id]).agg() df.status px.container_id_to_status(df.id)这段代码展示了 PxL 的核心数据模型通过px.DataFrame声明式地引用 Pixie 采集的表如process_stats用df.ctx[pod]读取上下文字段pod、container 等 k8s 元数据随行注入再经groupby(...).agg()聚合并用px.container_id_to_status这样的内置函数做语义增强。可视化侧由 vis.json 定义variables声明 Live View 的输入参数例如start_time类型PX_STRING默认值-5m表示当前时间往前 5 分钟与pod类型PX_POD格式ns/pod_nameglobalFuncs则把.pxl中定义的函数如inbound_latency_timeseries绑定为图表数据源。这种元数据 逻辑 可视化分离的结构是仓库内所有 Live View 脚本的统一范式。5. 源码级剖析eBPF 内核追踪脚本的探针注册模式bpftrace 目录下的脚本展示了 PxL 脚本与 eBPF 的深度集成。以 bpftrace/tcp_drops/data.pxl 为例它同时定义了两个pxtrace.TraceProgrampre_519_program针对内核5.19使用kprobe:tcp_drop探针max_kernel5.18post_519_program针对内核5.19改用tracepoint:skb:kfree_skb并依据SKB_DROP_REASON_*过滤真实丢包min_kernel5.19。脚本注释明确说明了原因较老内核中kprobe:tcp_drop在新内核版本被移除因此必须按内核版本选择探针实现。程序体内通过 bpftrace 语法读取struct sock的地址族、源/目的地址与端口并利用tcp_states[...]映射表把skc_state数值翻译成可读的 TCP 状态ESTABLISHED、SYN_SENT、TIME_WAIT 等。随后在 PxL 侧完成动态注册与数据消费pxtrace.UpsertTracepoint(tcp_drop_tracer, table_name, [pre_519_program, post_519_program], pxtrace.kprobe(), 10m) df px.DataFrame(tabletable_name) df.src px.pod_id_to_pod_name(px.ip_to_pod_id(df.src_ip)) df.dst px.nslookup(df.dst_ip) df df.groupby([src, dst]).agg(drops(src, px.count))UpsertTracepoint以 10 分钟 TTL 注册 tracepoint内核版本会自动匹配两个程序之一输出行写入tcp_drop_table后PxL 脚本用ip_to_pod_id/pod_id_to_pod_name把 IP 反解为 Pod 名、用nslookup解析目标域名最后groupby统计各连接对的丢包数。这正是README 一行简介背后是内核探针 语言层管道的典型样本。6. 打包、验证与分发bundle 产物链路脚本要交给pxCLI 或 UI 使用需要被打包成 bundle。这一链路由 Makefile 与 BUILD.bazel 协同完成。Makefile 的核心目标是生成bundle-oss.json以及其 gzip 压缩版bundle-oss.json.gz命令为px create-bundle --search_path $(PWD) \ --base bpftrace --base px --base pxbeta --base sotw \ -o $(PWD)/bundle-oss.json gzip -c bundle-oss.json bundle-oss.json.gzdirs : bpftrace px pxbeta sotw决定了打包范围PATH_PREFIX用于在 Bazel 场景下把脚本放到正确位置。EXECUTABLES ? px允许通过环境变量指定px二进制路径。在 Bazel 侧BUILD.bazel 定义了preset_queriesfilegroup收集全部**/*.pxl、**/*.json、**/*.yaml排除bundle-oss.json作为脚本原料script_bundlegenrule调用//src/pixie_cli:px执行make bundle-oss.json产出bundle-oss.jsonscript_bundle_testsh_test调用 test_script_bundle.sh 与yq校验产物——检查 bundle 文件存在并断言.scripts | keys | length大于 0即bundle 中必须包含脚本防止空包。pxCLI 对应的实现位于 src/pixie_cli入口 px.gocreate-bundle是其子命令之一。7. README 的自动生成机制README 之所以能始终与目录保持同步靠的是 update_readme.py。其工作逻辑如下递归扫描脚本目录下所有**/manifest.yaml跳过路径中含private的脚本读取每个 manifest 的long字段作为描述yaml.safe_load(...).get(long).strip()按目录名排序生成形如- folder/script: desc的列表行与固定头部说明文字 运行make update_readme更新本 README一起写入README.md。生成器接受两个可选参数脚本目录路径与 GitHub URL默认https://github.com/pixie-io/pixie/tree/main/src/pxl_scripts。因此在仓库内更新脚本后执行cd src/pxl_scripts make update_readme即可重新生成 README其中make update_readme目标实际执行./update_readme.py . github_url。这也解释了为什么第 3 节清单中每个脚本都能与 manifest 的long描述一一对应。8. 本地开发工作流热更新与浏览器调试针对脚本开发仓库提供了make dev对应 watch.sh的本地开发循环启动 cors_http_server.py——一个在 8000 端口、为所有响应附加Access-Control-Allow-Origin: *的静态文件服务器用于跨域托管bundle-oss.json在 Chrome 控制台执行localStorage.setItem(px-custom-bundle-paths, [http://127.0.0.1:8000/bundle-oss.json])让 Pixie UI 从本地 bundle 加载脚本脚本每秒钟执行一次make -s bundle-oss.json实现改脚本 → 自动重打包 → UI 刷新可见的热循环。退出时脚本会提示清理localStorage.clear(px-custom-bundle-paths)。这套工作流把新增/修改 PxL 脚本 → 重新生成 bundle → UI 即时预览的迭代成本降到最低适合在引入新 Live View 时使用。9. 小结src/pxl_scripts目录本质上是 Pixie 可观测性能力的官方示例库4 个目录、83 个脚本横跨内核追踪bpftrace、应用协议HTTP/SQL/消息队列、网络拓扑、资源画像与内部诊断全部以manifest.yaml *.pxl vis.json的统一结构组织Makefile 与 BUILD.bazel 提供了从源码到bundle-oss.json的打包与校验链路update_readme.py 保证清单文档自动同步watch.sh 则支撑起本地开发的即时预览。无论你是想直接复用这些预设脚本还是基于它们学习 PxL 语言并编写自己的可观测性脚本这份仓库地图与打包流程都能作为起点。赞分享可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载相关推荐bpftrace 官方工具集全解析38 个随包发布的 eBPF 可观测性脚本实战指南bpftrace 官方工具集全解析38 个随包发布的 eBPF 可观测性脚本实战指南 导读 本文以仓库 tools/README.md https://lin文档教程前端clawhub 可观测性实践Axiom REST API 能力全景与 axiom-sre 脚本封装解析clawhub 可观测性实践Axiom REST API 能力全景与 axiom sre 脚本封装解析 本文以 clawhub 仓库中 axiom sre h后端前端AI 技能AI 插件搜索引擎DeepTutor完整上手指南3步搭建你的专属AI学习助手从新手到高手全攻略DeepTutor完整上手指南3步搭建你的专属AI学习助手从新手到高手全攻略 想象一下有这样一位老师它记得你上周卡壳的题目知道你笔记里反复出现的概念人工智能AI 应用AI Agent多智能体RAG教育后端前端上一篇用 Python 与 Plotly 实现单样本、双样本 T 检验t-Test完整实战指南下一篇7大场景彻底解决终端工具痛点electerm跨平台管理神器全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考