2026/9/18 7:22:15
FEATURED · 精选文章 
Fleet 3.12.0 版本解析主机查询归属可视化、按需 Refetch 主机详情与 Redis 实时查询结果复制【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet导读Fleet 3.12.0 是开源设备管理平台 Fleet 在 2021 年 5 月发布的一个里程碑版本围绕 osquery 主机管理的日常痛点带来了三项核心增强在主机详情页直接查看该主机上调度了哪些 pack 内查询、查询的执行频率与最近运行时间通过 Refetch 按钮按需向指定主机请求最新详情数据以及来自社区的多项实用贡献Google Cloud Pub/Sub 日志字段复制、Redis 实时查询结果复制、服务端 HTTP keep-alive 开关。读完本文你将理解这些功能在 Fleet 当前仓库中的对应实现路径、相关配置项及其适用场景可直接对照源码验证并落地到自己的部署中。版本概览3.12 带来了什么根据仓库中的发布文章 articles/fleet-3.12.0.mdFleet 3.12.0 于 2021-05-20 发布对应文档 meta 中的publishedOn字段其亮点集中在主机查询归属可视化在 UI 中查看每个主机上实际调度运行了哪些 pack 查询以及各查询的调度频率和最近一次运行时间帮助管理员确认 osquery 查询是否真正覆盖目标设备Refetch 主机详情在 Host details 页面点击按钮向指定主机按需请求一份最新数据确保看到的不是过期的缓存三项社区贡献Google Cloud Pub/Sub 属性复制、Redis 实时查询结果复制、服务端 HTTP keep-alive 开关。下面逐项展开并结合当前仓库源码给出实现层面的印证。查看主机上调度了哪些查询Which queries apply to a host为什么需要查询归属视图在 osquery 管理实践中查询通常组织在pack中pack 再按 label、platform 等条件定向到一批主机。查询收集的数据是告警、性能仪表盘以及 Incident Response 场景历史数据的来源因此管理员非常需要确认某个查询是否真的成功配置并运行在目标设备上。Fleet 3.12.0 在主机详情页展示了该主机被调度运行的所有查询包括查询名称来自哪个 pack该查询的调度频率interval该查询在设备上的最近一次运行时间。底层实现scheduled_query_stats这一 UI 能力背后是 Fleet 对查询运行统计的采集与聚合。在当前仓库中主机详情的查询统计来源于scheduled_query_stats表表结构与聚合逻辑位于 server/datastore/mysql/aggregated_stats.go例如按scheduled_query_id汇总执行次数SELECT coalesce(sum(executions), 0) FROM scheduled_query_stats WHERE scheduled_query_id?主机详情页加载调度查询统计的入口在 server/datastore/mysql/hosts.goloadHostScheduledQueryStatsDB它从scheduled_query_stats表中按host_id分组读取每个scheduled_query_id的统计该统计采集默认开启对应配置项app.enable_scheduled_query_stats默认值为true定义于 server/config/config.go。从源码结构看Fleet 通过 osquery 的scheduled_query_stats上报机制逐主机积累执行计数、系统时间/用户时间与执行次数再在主机详情接口中按查询聚合展示这正是哪个查询跑在哪个设备上、多久跑一次、上次何时运行这一视图的数据来源。对于监控 osquery 部署健康度的管理员而言这个视图是排查查询未生效类问题的第一入口。Refetch 主机详情按需获取权威数据功能动机主机详情host vitals页面承载了设备的关键信息。如果数据长时间未更新管理员基于过期数据做决策是有风险的。3.12.0 新增的 Refetch 能力允许在 Host details 页面点击按钮主动请求指定主机重新上报最新数据。API 与调用链该功能对应的 REST 端点为POST /api/v1/fleet/hosts/:id/refetch登记于 server/api_endpoints/api_endpoints.yml。端点到存储层的完整调用链如下refetchHostEndpoint解析请求并调用svc.RefetchHost见 server/service/hosts.goService.RefetchHost先做鉴权非设备 token/设备 URL 认证的请求需要ActionList与ActionRead权限observer 角色即可执行 refetch源码注释明确说明使用ActionRead而非ActionWrite是为了允许观察者刷新主机见 server/service/hosts.go随后调用svc.ds.UpdateHostRefetchRequested(ctx, id, true)落库存储层实现为一条 UPDATE 语句UPDATE hosts SET refetch_requested ? WHERE id ?见 server/datastore/mysql/hosts.go。refetch_requested标记置位后主机在下一次 osquery checkin 时即可感知服务器请求了刷新从而重新上报详情数据。值得一提的细节是新注册的主机在创建时总是以refetch_requested true写入见 server/datastore/mysql/hosts.go保证新设备上线后会尽快完成首次完整详情采集。iOS/iPadOS 的差异化处理从源码看Fleet 对 iOS/iPadOS 主机的 refetch 有专门分支server/service/hosts.go 及后续逻辑这类设备没有 Fleet Desktop无法走设备 token 认证路径因此服务端会读取已发送的 MDM 命令GetHostMDMCommands据此决定是否补发 App 信息、DeviceInformation、证书等 MDM 指令来完成按需刷新。相关测试覆盖见 server/service/hosts_test.goTestRefetchHostIOSTracksBeforeEnqueue。社区贡献三项实用增强将日志字段复制进 Google Cloud Pub/Sub attributes感谢社区成员 Michael Samuel 的贡献对应上游 PR #712Fleet 写入 Google Cloud Pub/Sub 时可以将日志字段复制到 Pub/Sub 消息的 attributes 中从而让用户直接利用这些值编写 Pub/Sub 的订阅过滤器subscription filters。这对于基于订阅过滤做分流、告警或路由的部署非常实用。redis_duplicate_results将实时查询结果复制到额外 Redis 频道社区成员 Josh Brower 的贡献上游 PR #762为 Redis 后端增加了实时查询结果的复制能力。当配置redis_duplicate_results true时所有实时查询结果会被额外发布到一个独立的 Redis Pub/Sub 频道供独立的消费者订阅。配置与实现层面当前仓库中可以看到完整的落点配置项定义RedisConfig.DuplicateResultsYAML 键为duplicate_results见 server/config/config.go命令行/环境变量开关redis.duplicate_results默认值为false帮助信息为 Duplicate Live Query results to another Redis channelserver/config/config.go核心实现redisQueryResults.WriteResult先把结果序列化为 JSON 发布到频道results_campaign_id当检测到该频道有订阅者且duplicateResults为真时再以best-effort方式向固定频道LQDuplicate额外PUBLISH一份同样的 JSON见 server/pubsub/redis_query_results.go。从实现可以推断这一机制的价值在于解耦查询结果投递与额外消费主频道仍服务于 Fleet 自身上层的实时查询结果汇流而LQDuplicate可作为可插拔的数据出口供日志采集、流处理或监控系统独立订阅且复制失败不会影响主路径源码注释明确 Ignore errors, duplicate result publishing is on a best-effort basis。server.keepalive控制服务端 HTTP keep-alive社区成员 Joseph Macaulay 的贡献上游 PR #741增加了对服务端 HTTP keep-alive 属性的控制。在部分大规模部署中关闭 keep-alive 有助于减少堆积的 TCP 连接数。当前仓库中对应实现配置项定义ServerConfig.KeepaliveYAML 键为keepalive见 server/config/config.go开关与默认值server.keepalive默认值为true帮助信息为 Controls whether HTTP keep-alives are enabled.server/config/config.go。需要说明的是该配置项控制的是 Fleet 服务器对外 HTTP 服务的连接复用行为与应用层 osquery TLS 通信逻辑相互独立默认开启以保持通常情况下的连接复用效率仅在出现大量空闲 TCP 连接时建议按需关闭并观察效果。升级到 3.12.0发布文章提供了完整的变更摘要与发布二进制信息。在仓库内各版本的变更记录可对照根目录的 CHANGELOG.md 查看部署与更新方式如 Docker Compose、Kubernetes、Linux 包管理等可参考 docs 目录下对应部署方案文档以及仓库根目录的 README.md 中关于构建与运行 Fleet 的说明。升级前建议关注与当前主版本之间的破坏性变更并先在预发环境验证 osquery 客户端兼容性3.12.0 中新增的redis_duplicate_results默认关闭与server.keepalive默认开启均为可选配置不修改任何既有默认行为升级路径相对平滑。小结Fleet 3.12.0 的三项核心能力在今天看来依然构成 osquery 设备管理的基础体验查询归属视图让哪些查询跑在哪些设备上变得可审计Refetch让管理员能按需拿到权威的主机状态而三项社区贡献则分别强化了日志出口的过滤能力Pub/Sub attributes、数据分发的可扩展性RedisLQDuplicate频道与连接管理keep-alive 开关。如果你想深入验证上述实现可以直接从 server/service/hosts.go、server/pubsub/redis_query_results.go 和 server/config/config.go 三个入口开始阅读源码。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Fleet 3.12.0 版本解析：主机查询归属可视化、按需 Refetch 主机详情与 Redis 实时查询结果复制
Fleet 3.12.0 版本解析主机查询归属可视化、按需 Refetch 主机详情与 Redis 实时查询结果复制【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet导读Fleet 3.12.0 是开源设备管理平台 Fleet 在 2021 年 5 月发布的一个里程碑版本围绕 osquery 主机管理的日常痛点带来了三项核心增强在主机详情页直接查看该主机上调度了哪些 pack 内查询、查询的执行频率与最近运行时间通过 Refetch 按钮按需向指定主机请求最新详情数据以及来自社区的多项实用贡献Google Cloud Pub/Sub 日志字段复制、Redis 实时查询结果复制、服务端 HTTP keep-alive 开关。读完本文你将理解这些功能在 Fleet 当前仓库中的对应实现路径、相关配置项及其适用场景可直接对照源码验证并落地到自己的部署中。版本概览3.12 带来了什么根据仓库中的发布文章 articles/fleet-3.12.0.mdFleet 3.12.0 于 2021-05-20 发布对应文档 meta 中的publishedOn字段其亮点集中在主机查询归属可视化在 UI 中查看每个主机上实际调度运行了哪些 pack 查询以及各查询的调度频率和最近一次运行时间帮助管理员确认 osquery 查询是否真正覆盖目标设备Refetch 主机详情在 Host details 页面点击按钮向指定主机按需请求一份最新数据确保看到的不是过期的缓存三项社区贡献Google Cloud Pub/Sub 属性复制、Redis 实时查询结果复制、服务端 HTTP keep-alive 开关。下面逐项展开并结合当前仓库源码给出实现层面的印证。查看主机上调度了哪些查询Which queries apply to a host为什么需要查询归属视图在 osquery 管理实践中查询通常组织在pack中pack 再按 label、platform 等条件定向到一批主机。查询收集的数据是告警、性能仪表盘以及 Incident Response 场景历史数据的来源因此管理员非常需要确认某个查询是否真的成功配置并运行在目标设备上。Fleet 3.12.0 在主机详情页展示了该主机被调度运行的所有查询包括查询名称来自哪个 pack该查询的调度频率interval该查询在设备上的最近一次运行时间。底层实现scheduled_query_stats这一 UI 能力背后是 Fleet 对查询运行统计的采集与聚合。在当前仓库中主机详情的查询统计来源于scheduled_query_stats表表结构与聚合逻辑位于 server/datastore/mysql/aggregated_stats.go例如按scheduled_query_id汇总执行次数SELECT coalesce(sum(executions), 0) FROM scheduled_query_stats WHERE scheduled_query_id?主机详情页加载调度查询统计的入口在 server/datastore/mysql/hosts.goloadHostScheduledQueryStatsDB它从scheduled_query_stats表中按host_id分组读取每个scheduled_query_id的统计该统计采集默认开启对应配置项app.enable_scheduled_query_stats默认值为true定义于 server/config/config.go。从源码结构看Fleet 通过 osquery 的scheduled_query_stats上报机制逐主机积累执行计数、系统时间/用户时间与执行次数再在主机详情接口中按查询聚合展示这正是哪个查询跑在哪个设备上、多久跑一次、上次何时运行这一视图的数据来源。对于监控 osquery 部署健康度的管理员而言这个视图是排查查询未生效类问题的第一入口。Refetch 主机详情按需获取权威数据功能动机主机详情host vitals页面承载了设备的关键信息。如果数据长时间未更新管理员基于过期数据做决策是有风险的。3.12.0 新增的 Refetch 能力允许在 Host details 页面点击按钮主动请求指定主机重新上报最新数据。API 与调用链该功能对应的 REST 端点为POST /api/v1/fleet/hosts/:id/refetch登记于 server/api_endpoints/api_endpoints.yml。端点到存储层的完整调用链如下refetchHostEndpoint解析请求并调用svc.RefetchHost见 server/service/hosts.goService.RefetchHost先做鉴权非设备 token/设备 URL 认证的请求需要ActionList与ActionRead权限observer 角色即可执行 refetch源码注释明确说明使用ActionRead而非ActionWrite是为了允许观察者刷新主机见 server/service/hosts.go随后调用svc.ds.UpdateHostRefetchRequested(ctx, id, true)落库存储层实现为一条 UPDATE 语句UPDATE hosts SET refetch_requested ? WHERE id ?见 server/datastore/mysql/hosts.go。refetch_requested标记置位后主机在下一次 osquery checkin 时即可感知服务器请求了刷新从而重新上报详情数据。值得一提的细节是新注册的主机在创建时总是以refetch_requested true写入见 server/datastore/mysql/hosts.go保证新设备上线后会尽快完成首次完整详情采集。iOS/iPadOS 的差异化处理从源码看Fleet 对 iOS/iPadOS 主机的 refetch 有专门分支server/service/hosts.go 及后续逻辑这类设备没有 Fleet Desktop无法走设备 token 认证路径因此服务端会读取已发送的 MDM 命令GetHostMDMCommands据此决定是否补发 App 信息、DeviceInformation、证书等 MDM 指令来完成按需刷新。相关测试覆盖见 server/service/hosts_test.goTestRefetchHostIOSTracksBeforeEnqueue。社区贡献三项实用增强将日志字段复制进 Google Cloud Pub/Sub attributes感谢社区成员 Michael Samuel 的贡献对应上游 PR #712Fleet 写入 Google Cloud Pub/Sub 时可以将日志字段复制到 Pub/Sub 消息的 attributes 中从而让用户直接利用这些值编写 Pub/Sub 的订阅过滤器subscription filters。这对于基于订阅过滤做分流、告警或路由的部署非常实用。redis_duplicate_results将实时查询结果复制到额外 Redis 频道社区成员 Josh Brower 的贡献上游 PR #762为 Redis 后端增加了实时查询结果的复制能力。当配置redis_duplicate_results true时所有实时查询结果会被额外发布到一个独立的 Redis Pub/Sub 频道供独立的消费者订阅。配置与实现层面当前仓库中可以看到完整的落点配置项定义RedisConfig.DuplicateResultsYAML 键为duplicate_results见 server/config/config.go命令行/环境变量开关redis.duplicate_results默认值为false帮助信息为 Duplicate Live Query results to another Redis channelserver/config/config.go核心实现redisQueryResults.WriteResult先把结果序列化为 JSON 发布到频道results_campaign_id当检测到该频道有订阅者且duplicateResults为真时再以best-effort方式向固定频道LQDuplicate额外PUBLISH一份同样的 JSON见 server/pubsub/redis_query_results.go。从实现可以推断这一机制的价值在于解耦查询结果投递与额外消费主频道仍服务于 Fleet 自身上层的实时查询结果汇流而LQDuplicate可作为可插拔的数据出口供日志采集、流处理或监控系统独立订阅且复制失败不会影响主路径源码注释明确 Ignore errors, duplicate result publishing is on a best-effort basis。server.keepalive控制服务端 HTTP keep-alive社区成员 Joseph Macaulay 的贡献上游 PR #741增加了对服务端 HTTP keep-alive 属性的控制。在部分大规模部署中关闭 keep-alive 有助于减少堆积的 TCP 连接数。当前仓库中对应实现配置项定义ServerConfig.KeepaliveYAML 键为keepalive见 server/config/config.go开关与默认值server.keepalive默认值为true帮助信息为 Controls whether HTTP keep-alives are enabled.server/config/config.go。需要说明的是该配置项控制的是 Fleet 服务器对外 HTTP 服务的连接复用行为与应用层 osquery TLS 通信逻辑相互独立默认开启以保持通常情况下的连接复用效率仅在出现大量空闲 TCP 连接时建议按需关闭并观察效果。升级到 3.12.0发布文章提供了完整的变更摘要与发布二进制信息。在仓库内各版本的变更记录可对照根目录的 CHANGELOG.md 查看部署与更新方式如 Docker Compose、Kubernetes、Linux 包管理等可参考 docs 目录下对应部署方案文档以及仓库根目录的 README.md 中关于构建与运行 Fleet 的说明。升级前建议关注与当前主版本之间的破坏性变更并先在预发环境验证 osquery 客户端兼容性3.12.0 中新增的redis_duplicate_results默认关闭与server.keepalive默认开启均为可选配置不修改任何既有默认行为升级路径相对平滑。小结Fleet 3.12.0 的三项核心能力在今天看来依然构成 osquery 设备管理的基础体验查询归属视图让哪些查询跑在哪些设备上变得可审计Refetch让管理员能按需拿到权威的主机状态而三项社区贡献则分别强化了日志出口的过滤能力Pub/Sub attributes、数据分发的可扩展性RedisLQDuplicate频道与连接管理keep-alive 开关。如果你想深入验证上述实现可以直接从 server/service/hosts.go、server/pubsub/redis_query_results.go 和 server/config/config.go 三个入口开始阅读源码。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ` 类型推断)
