尧图网站建设 
Fleet 4.9.0 发布解读实时查询结果分页、策略 YAML 文档支持与 MySQL 性能优化【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet2022 年的首个 Fleet 版本带来了三件值得关注的事一是围绕 UI 加载体验、MySQL 数据库与后台任务做了大量看不见的性能优化二是实时查询live query结果支持分页浏览UI 可以顺畅承载 1,000 条以上的结果三是支持通过policyYAML 文档配合fleetctl apply批量下发策略让组织的策略管理可以正式纳入 GitOps 工作流。本文将围绕这三个重点结合当前开源仓库中的源码实现逐项拆解 4.9.0 的功能细节与底层原理。完整变更列表可查阅本仓库 CHANGELOG.md更新步骤参见仓库内 upgrade guide。Feature highlights本次发布的三大看点Fleet 4.9.0 的核心更新可以概括为以下三点性能改进贯穿前后端优化了 UI 的加载状态与延迟并对 MySQL 数据库做了性能优化同时清理了后台任务与存储层的冗余负担分页化的实时查询结果实时查询结果支持分页导航Fleet UI 可以处理 1,000 条结果而不再卡顿策略 YAML 文档支持新增policyYAML 文档类型配合fleetctl apply即可将组织策略纳入 GitOps 管理。下面逐一深入。分页化实时查询结果千条结果不再一屏到底实时查询live query是 Fleet 的核心能力之一向所有在线主机广播 SQL 查询然后实时回收各主机返回的osquery结果。在 4.9.0 之前当结果数量超过千条时UI 一次性渲染全部结果既慢又难用。4.9.0 引入了分页导航用户可以像翻页一样在数千条结果中穿梭这是一个小但高价值的 UI 改进。从源码看实时查询结果的数据模型在 server/fleet/campaigns.go 中定义QueryResult单台主机的查询结果包含host_id主机 ID、rows查询返回的行每行为map[string]string以及可选的error字段QueryCampaignResult一次实时查询战役campaign的完整结果集合其中Results是[]QueryResultQueryID标识对应的查询。结果的分发通过 WebSocket 流式推送完成接口声明在 server/fleet/service.go// StreamCampaignResults streams updates with query results and expected host totals over the provided websocket. StreamCampaignResults(ctx context.Context, conn *websocket.Conn, campaignID uint)对应的服务层实现位于 server/service/endpoint_campaigns.go当客户端发起实时查询后服务端通过该端点持续将增量结果推送给 UI再由前端按页渲染。可以推断分页化正是建立在这条流式推送通道之上后端持续累积结果前端按页拉取展示从而将单次渲染的 DOM 规模限制在可控范围内。策略 YAML 文档支持用 fleetctl apply 驱动 GitOps 策略管理这是 4.9.0 引入的一项关键能力用户可以在 YAML 文档中以声明式方式描述策略并通过fleetctl apply一次性写入 Fleet从而让策略像基础设施一样代码化管理。对于已经采用 GitOps 实践的组织策略的变更、评审、回滚从此都有了版本化载体。policy YAML 文档的字段4.9.0 中policyYAML 文档允许用户为每条策略指定四个核心字段name策略名称唯一标识同名策略不允许重复query策略对应的 osquery SQL 查询description策略描述说明该策略的检查目的resolution策略失败时的解决建议展示给主机用户。一个典型的policy文档形如kind: policy apiVersion: v1 name: Detect processes with Log4j running query: SELECT * FROM processes WHERE name LIKE %log4j%; description: Detects active processes running with Log4j. resolution: Update or patch the Log4j library used by the process.随后在命令行中执行fleetctl apply -f policies.ymlFleet 会解析该文档将其中定义的策略批量应用到 Fleet 实例。策略名在全局或同一团队内必须唯一——这一点由服务端强校验详见下文因此该文档也是组织内策略的事实来源source of truth非常适合放入 Git 仓库进行版本管理。源码视角PolicySpec 与 ApplyPolicySpecs 的完整调用链策略 YAML 文档对应的数据模型是PolicySpec定义在 server/fleet/policies.go。从 4.9.0 起步的name、query、description、resolution四个字段如今已扩展为完整的声明式描述核心字段及含义如下字段JSON 键说明Namename策略名称唯一标识Queryquery策略的 osquery SQL 查询Descriptiondescription策略描述Resolutionresolution策略失败时的修复建议Teamteam所属团队名称空表示全局策略Platformplatform目标平台逗号分隔空表示所有平台Criticalcritical标记为高影响策略premium 功能LabelsIncludeAny等labels_include_any等策略的标签范围限定premium 功能fleetctl apply在客户端侧的入口是Client.ApplyPolicies位于 server/service/client_policies.go它将规格封装为ApplyPolicySpecsRequest后发往服务端func (c *Client) ApplyPolicies(specs []*fleet.PolicySpec) error { req : fleet.ApplyPolicySpecsRequest{Specs: specs} // ... }请求结构体定义在 server/fleet/api_policies.go服务端入口applyPolicySpecsEndpoint在 server/service/global_policies.go 中把请求转交给svc.ApplyPolicySpecs。Service.ApplyPolicySpecsserver/service/global_policies.go是策略批量下发的主流程它依次完成鉴权调用checkPolicySpecAuthorization校验当前用户是否有权写入全局或对应团队的策略字段校验对每条策略执行policy.Verify()并拦截不合法组合例如全局策略绑定配置描述文件、脚本等团队策略专属能力重复名校验调用FirstDuplicatePolicySpecNameserver/fleet/policies.go按团队维度检查策略名是否重复重复即返回 duplicate policy names not allowed 错误落库调用数据层ds.ApplyPolicySpecs完成最终写入。数据层的实现位于 server/datastore/mysql/policies.go可以看到它先将规格按团队分组、解析团队 ID再批量写入策略表。其中两处细节值得注意策略名会经过 Unicode NFC 规范化norm.NFC.String确保不同编码写法下的同名策略被正确识别规格在数据层同样会校验全局策略不得携带配置描述文件ProfileUUID或脚本ScriptID与上层校验形成双保险。对应的测试用例位于 server/service/global_policies_test.goTestApplyPolicySpecsReturnsErrorOnDuplicatePolicyNamesInSpecs专门验证了重复策略名会被拒绝server/service/client_test.go 则用多组GitOpsPolicySpec场景覆盖了策略文档的各种字段组合可作为编写合法策略 YAML 的参考。与 GitOps 工作流的配合策略 YAML 文档让 Fleet 的 GitOps 能力从配置、查询扩展到了策略。将策略文档纳入 Git 仓库后团队可以在 PR 中评审策略变更通过 CI 执行fleetctl apply应用任何错误下发都可以通过 Git 历史回滚。仓库中 docs/Configuration/yaml-files.md 对各类 YAML 文档的写法有系统说明其中也包含了策略依赖的团队与team_settings配置示例可搭配阅读。性能改进一次深入底层的大扫除4.9.0 在性能上的投入覆盖了异步处理、数据访问层、数据库关系、日志与前端渲染等多个维度逐条拆解如下重构异步主机处理避免 Redis SCAN 键异步主机任务原先依赖 RedisSCAN遍历键在主机规模增大时开销明显4.9.0 改写了处理逻辑减少了对键扫描的依赖降低了大规模场景下的 Redis 压力收敛 Datastore API 的无效数据加载审计并收紧了 osquery 主机相关数据访问接口避免每次轮询拉取不必要的数据减轻 MySQL 与网络传输负担审计数据库关系精简清理逻辑排查并移除了尽可能多的数据库关系清理cleanup步骤减少不必要的写操作与锁竞争移除 Orbit 中未使用的 BadgerDBOrbit 客户端内的 Badger 嵌入式数据库实际未被使用且偶尔给 Windows 用户带来困扰本版本将其移除简化了客户端依赖测试矩阵引入 MySQL:8确保单元测试通过 MySQL 8 镜像并在 CI 中新增 GitHub Action让每个 PR 都以 MySQL:8 跑一遍测试提前暴露数据库兼容性问题osquery 日志可插拔化面向 Windows新增配置选项支持将 osquery 日志写入文件并对直接落盘日志做轮转Windows 用户不再受限于原有日志通道每主机 jitter 抖动改进优化了主机上报时间的随机抖动算法避免大量主机同时连入造成惊群式请求峰值前端健壮性与加载体验改进非 JSON 错误响应处理、清理页面级组件中不必要的状态重断言、优化 Manage policies 页面在高主机量下的加载状态、改善 Hosts 页空状态提示并统一了 UI 各处内边距、间距与对齐pixel peeping。错误修复与兼容性细节除性能与功能外4.9.0 还修复了一批影响日常使用的问题查询或策略 ID 不存在时现在正确返回404而非 500Team Observers 获取全局策略列表时不再收到403修复匿名使用统计中numLabels上报不准确的问题修复部分 UI 页面加载时对同一端点发起多次请求的问题fleetctl preview中fleetctl.exe preview --orbit-channel edge启动 Linux 容器可正常构建fleetctl preview中实时查询结果过滤恢复正常浏览器扩展在软件清单software inventory中的展示恢复正常UI 可正确识别 Detect active processes with Log4j running 查询的兼容性。升级到 4.9.0如需升级请按照仓库内 upgrade guide 的说明执行更新。升级前建议先阅读 CHANGELOG.md 确认与自身上下游的兼容性并在预发环境完成回归验证尤其关注策略 YAML 文档、实时查询分页与 MySQL 相关配置。小结Fleet 4.9.0 是 2022 年的开门之作实时查询结果分页解决了大规模主机场景下的前端瓶颈policyYAML 文档配合fleetctl apply把策略管理正式带入了 GitOps 时代其核心数据模型PolicySpec与服务端ApplyPolicySpecs流程在后续版本中持续演进成为 Fleet 声明式管理的重要基石而贯穿前后端、数据库与客户端的性能优化则为后续版本在大规模部署下的稳定性打下了基础。对于正在评估或使用 Fleet 的团队将策略文档化并纳入版本管理是本次升级中最值得立即落地的实践。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Fleet 4.9.0 发布解读：实时查询结果分页、策略 YAML 文档支持与 MySQL 性能优化
Fleet 4.9.0 发布解读实时查询结果分页、策略 YAML 文档支持与 MySQL 性能优化【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet2022 年的首个 Fleet 版本带来了三件值得关注的事一是围绕 UI 加载体验、MySQL 数据库与后台任务做了大量看不见的性能优化二是实时查询live query结果支持分页浏览UI 可以顺畅承载 1,000 条以上的结果三是支持通过policyYAML 文档配合fleetctl apply批量下发策略让组织的策略管理可以正式纳入 GitOps 工作流。本文将围绕这三个重点结合当前开源仓库中的源码实现逐项拆解 4.9.0 的功能细节与底层原理。完整变更列表可查阅本仓库 CHANGELOG.md更新步骤参见仓库内 upgrade guide。Feature highlights本次发布的三大看点Fleet 4.9.0 的核心更新可以概括为以下三点性能改进贯穿前后端优化了 UI 的加载状态与延迟并对 MySQL 数据库做了性能优化同时清理了后台任务与存储层的冗余负担分页化的实时查询结果实时查询结果支持分页导航Fleet UI 可以处理 1,000 条结果而不再卡顿策略 YAML 文档支持新增policyYAML 文档类型配合fleetctl apply即可将组织策略纳入 GitOps 管理。下面逐一深入。分页化实时查询结果千条结果不再一屏到底实时查询live query是 Fleet 的核心能力之一向所有在线主机广播 SQL 查询然后实时回收各主机返回的osquery结果。在 4.9.0 之前当结果数量超过千条时UI 一次性渲染全部结果既慢又难用。4.9.0 引入了分页导航用户可以像翻页一样在数千条结果中穿梭这是一个小但高价值的 UI 改进。从源码看实时查询结果的数据模型在 server/fleet/campaigns.go 中定义QueryResult单台主机的查询结果包含host_id主机 ID、rows查询返回的行每行为map[string]string以及可选的error字段QueryCampaignResult一次实时查询战役campaign的完整结果集合其中Results是[]QueryResultQueryID标识对应的查询。结果的分发通过 WebSocket 流式推送完成接口声明在 server/fleet/service.go// StreamCampaignResults streams updates with query results and expected host totals over the provided websocket. StreamCampaignResults(ctx context.Context, conn *websocket.Conn, campaignID uint)对应的服务层实现位于 server/service/endpoint_campaigns.go当客户端发起实时查询后服务端通过该端点持续将增量结果推送给 UI再由前端按页渲染。可以推断分页化正是建立在这条流式推送通道之上后端持续累积结果前端按页拉取展示从而将单次渲染的 DOM 规模限制在可控范围内。策略 YAML 文档支持用 fleetctl apply 驱动 GitOps 策略管理这是 4.9.0 引入的一项关键能力用户可以在 YAML 文档中以声明式方式描述策略并通过fleetctl apply一次性写入 Fleet从而让策略像基础设施一样代码化管理。对于已经采用 GitOps 实践的组织策略的变更、评审、回滚从此都有了版本化载体。policy YAML 文档的字段4.9.0 中policyYAML 文档允许用户为每条策略指定四个核心字段name策略名称唯一标识同名策略不允许重复query策略对应的 osquery SQL 查询description策略描述说明该策略的检查目的resolution策略失败时的解决建议展示给主机用户。一个典型的policy文档形如kind: policy apiVersion: v1 name: Detect processes with Log4j running query: SELECT * FROM processes WHERE name LIKE %log4j%; description: Detects active processes running with Log4j. resolution: Update or patch the Log4j library used by the process.随后在命令行中执行fleetctl apply -f policies.ymlFleet 会解析该文档将其中定义的策略批量应用到 Fleet 实例。策略名在全局或同一团队内必须唯一——这一点由服务端强校验详见下文因此该文档也是组织内策略的事实来源source of truth非常适合放入 Git 仓库进行版本管理。源码视角PolicySpec 与 ApplyPolicySpecs 的完整调用链策略 YAML 文档对应的数据模型是PolicySpec定义在 server/fleet/policies.go。从 4.9.0 起步的name、query、description、resolution四个字段如今已扩展为完整的声明式描述核心字段及含义如下字段JSON 键说明Namename策略名称唯一标识Queryquery策略的 osquery SQL 查询Descriptiondescription策略描述Resolutionresolution策略失败时的修复建议Teamteam所属团队名称空表示全局策略Platformplatform目标平台逗号分隔空表示所有平台Criticalcritical标记为高影响策略premium 功能LabelsIncludeAny等labels_include_any等策略的标签范围限定premium 功能fleetctl apply在客户端侧的入口是Client.ApplyPolicies位于 server/service/client_policies.go它将规格封装为ApplyPolicySpecsRequest后发往服务端func (c *Client) ApplyPolicies(specs []*fleet.PolicySpec) error { req : fleet.ApplyPolicySpecsRequest{Specs: specs} // ... }请求结构体定义在 server/fleet/api_policies.go服务端入口applyPolicySpecsEndpoint在 server/service/global_policies.go 中把请求转交给svc.ApplyPolicySpecs。Service.ApplyPolicySpecsserver/service/global_policies.go是策略批量下发的主流程它依次完成鉴权调用checkPolicySpecAuthorization校验当前用户是否有权写入全局或对应团队的策略字段校验对每条策略执行policy.Verify()并拦截不合法组合例如全局策略绑定配置描述文件、脚本等团队策略专属能力重复名校验调用FirstDuplicatePolicySpecNameserver/fleet/policies.go按团队维度检查策略名是否重复重复即返回 duplicate policy names not allowed 错误落库调用数据层ds.ApplyPolicySpecs完成最终写入。数据层的实现位于 server/datastore/mysql/policies.go可以看到它先将规格按团队分组、解析团队 ID再批量写入策略表。其中两处细节值得注意策略名会经过 Unicode NFC 规范化norm.NFC.String确保不同编码写法下的同名策略被正确识别规格在数据层同样会校验全局策略不得携带配置描述文件ProfileUUID或脚本ScriptID与上层校验形成双保险。对应的测试用例位于 server/service/global_policies_test.goTestApplyPolicySpecsReturnsErrorOnDuplicatePolicyNamesInSpecs专门验证了重复策略名会被拒绝server/service/client_test.go 则用多组GitOpsPolicySpec场景覆盖了策略文档的各种字段组合可作为编写合法策略 YAML 的参考。与 GitOps 工作流的配合策略 YAML 文档让 Fleet 的 GitOps 能力从配置、查询扩展到了策略。将策略文档纳入 Git 仓库后团队可以在 PR 中评审策略变更通过 CI 执行fleetctl apply应用任何错误下发都可以通过 Git 历史回滚。仓库中 docs/Configuration/yaml-files.md 对各类 YAML 文档的写法有系统说明其中也包含了策略依赖的团队与team_settings配置示例可搭配阅读。性能改进一次深入底层的大扫除4.9.0 在性能上的投入覆盖了异步处理、数据访问层、数据库关系、日志与前端渲染等多个维度逐条拆解如下重构异步主机处理避免 Redis SCAN 键异步主机任务原先依赖 RedisSCAN遍历键在主机规模增大时开销明显4.9.0 改写了处理逻辑减少了对键扫描的依赖降低了大规模场景下的 Redis 压力收敛 Datastore API 的无效数据加载审计并收紧了 osquery 主机相关数据访问接口避免每次轮询拉取不必要的数据减轻 MySQL 与网络传输负担审计数据库关系精简清理逻辑排查并移除了尽可能多的数据库关系清理cleanup步骤减少不必要的写操作与锁竞争移除 Orbit 中未使用的 BadgerDBOrbit 客户端内的 Badger 嵌入式数据库实际未被使用且偶尔给 Windows 用户带来困扰本版本将其移除简化了客户端依赖测试矩阵引入 MySQL:8确保单元测试通过 MySQL 8 镜像并在 CI 中新增 GitHub Action让每个 PR 都以 MySQL:8 跑一遍测试提前暴露数据库兼容性问题osquery 日志可插拔化面向 Windows新增配置选项支持将 osquery 日志写入文件并对直接落盘日志做轮转Windows 用户不再受限于原有日志通道每主机 jitter 抖动改进优化了主机上报时间的随机抖动算法避免大量主机同时连入造成惊群式请求峰值前端健壮性与加载体验改进非 JSON 错误响应处理、清理页面级组件中不必要的状态重断言、优化 Manage policies 页面在高主机量下的加载状态、改善 Hosts 页空状态提示并统一了 UI 各处内边距、间距与对齐pixel peeping。错误修复与兼容性细节除性能与功能外4.9.0 还修复了一批影响日常使用的问题查询或策略 ID 不存在时现在正确返回404而非 500Team Observers 获取全局策略列表时不再收到403修复匿名使用统计中numLabels上报不准确的问题修复部分 UI 页面加载时对同一端点发起多次请求的问题fleetctl preview中fleetctl.exe preview --orbit-channel edge启动 Linux 容器可正常构建fleetctl preview中实时查询结果过滤恢复正常浏览器扩展在软件清单software inventory中的展示恢复正常UI 可正确识别 Detect active processes with Log4j running 查询的兼容性。升级到 4.9.0如需升级请按照仓库内 upgrade guide 的说明执行更新。升级前建议先阅读 CHANGELOG.md 确认与自身上下游的兼容性并在预发环境完成回归验证尤其关注策略 YAML 文档、实时查询分页与 MySQL 相关配置。小结Fleet 4.9.0 是 2022 年的开门之作实时查询结果分页解决了大规模主机场景下的前端瓶颈policyYAML 文档配合fleetctl apply把策略管理正式带入了 GitOps 时代其核心数据模型PolicySpec与服务端ApplyPolicySpecs流程在后续版本中持续演进成为 Fleet 声明式管理的重要基石而贯穿前后端、数据库与客户端的性能优化则为后续版本在大规模部署下的稳定性打下了基础。对于正在评估或使用 Fleet 的团队将策略文档化并纳入版本管理是本次升级中最值得立即落地的实践。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考