Fleet 项目解读：基于 osquery 的开放式设备管理与安全运维平台

项目地址：https://github.com/fleetdm/fleet

GitHub Stars：截至 2026 年 8 月约 6800

当前版本：fleet-v4.90.1

关键词：Fleet、osquery、Orbit、Fleet Desktop、设备管理、MDM、终端安全、软件部署、补丁管理、GitOps、实时查询、漏洞管理、开源运维

一、为什么企业需要统一的设备管理与安全运维平台

企业中的计算机、服务器、云主机、容器和移动设备，通常分散在不同的网络、办公地点和云平台中。设备数量增加后，仅依靠人工登录、脚本和零散的安全工具，很难持续掌握完整的设备状态。

运维和安全团队经常需要回答以下问题：

• 当前有哪些设备正在使用，分别运行什么操作系统和版本
• 某个软件安装在哪些设备上，是否存在未授权或高风险版本
• 哪些终端缺少安全补丁或不符合组织基线
• 某台设备当前是否在线，最近一次汇报状态是什么时候
• 某个用户、标签或设备组是否满足指定的安全策略
• 发生安全事件时，如何快速收集终端上的进程、文件、网络和系统信息
• 如何向大量设备发布脚本、软件、配置和系统更新
• 如何让设备管理过程可以被 API、Git 和自动化流水线持续维护

传统的设备管理方式通常将资产清单、终端脚本、补丁平台、MDM、漏洞平台和安全查询系统分开建设。不同系统之间的数据格式、设备标识和权限模型不一致，容易出现重复维护和信息不同步。

Fleet 的目标，是为 IT 和安全团队提供一个统一的设备管理平台。它使用 osquery 将操作系统中的硬件、软件、安全和运行状态转换成可查询的数据，再通过 Fleet Server、Web 界面、API、策略、软件管理和自动化能力对这些设备进行集中管理。

二、Fleet 是什么

Fleet 是一个面向 IT 和安全团队的开放式设备管理平台，主要用于管理大量计算机和其他计算资源。官方项目将其描述为适合 API、GitOps、Webhook、YAML 和人工操作的开源平台。

Fleet 可以同时承担设备可见性、终端管理和安全运维等多类职责：

• 通过 Agent 获取硬件、操作系统、软件、用户、进程和网络信息
• 使用 SQL 查询检查设备当前状态
• 创建定期运行的查询，持续收集设备数据
• 使用策略判断设备是否符合安全或配置要求
• 通过标签将设备划分为不同的管理范围
• 管理软件安装、软件更新和补丁任务
• 向设备下发脚本和自动化操作
• 为 macOS、Windows、Linux 及其他支持的平台提供设备管理能力
• 通过 MDM 管理部分 Apple 和 Windows 设备配置
• 通过 API、YAML、Webhook 和 fleetctl 接入自动化流程

Fleet 的核心不是单纯的资产清单，也不是只面向某一个操作系统的 MDM 产品。它将操作系统数据采集、设备管理、安全策略和自动化运维放到同一个控制面中。

项目建立在多个开源组件之上，其中最重要的是 osquery。Fleet 负责设备注册、配置编排、查询调度、数据存储和管理界面，osquery 负责将设备信息以关系型表的形式暴露出来。

Fleet 仓库的免费版本采用 MIT 许可证。仓库同时包含商业版本相关内容，企业在进行二次开发、功能集成或发布时，应结合仓库中的许可证文件和具体使用范围进行确认。

三、Fleet 的整体架构与工作方式

Fleet 的工作方式可以分成设备端、控制面和数据存储三个部分。

管理员 / 安全人员 / 自动化系统
              |
       Web UI / REST API / fleetctl
              |
              v
          Fleet Server
              |
    +---------+----------+
    |                    |
    v                    v
  MySQL                Redis
网络状态、设备、       缓存、队列、
查询、策略和配置       临时状态和锁
    |
    v
Fleet Agent / Orbit / Fleet Desktop
    |
    +-- osquery：查询设备信息
    +-- 软件、脚本和配置任务
    +-- MDM 或系统管理接口
    v
Windows / macOS / Linux / 移动设备 / 云资源

设备端 Agent 持续与 Fleet Server 通信，注册设备、汇报状态、接收配置和执行任务。Fleet Server 负责将管理员配置转换为设备可以执行的查询、策略、软件或脚本任务。

一个典型的设备管理流程如下：

设备安装 Fleet Agent
          |
          v
设备注册到 Fleet Server
          |
          v
匹配团队、标签和管理策略
          |
          +-- 下发 osquery 配置
          +-- 下发策略和定期查询
          +-- 下发软件或脚本任务
          +-- 下发 MDM 配置
          |
          v
设备执行任务并返回结果
          |
          v
Fleet 保存结果并生成状态、日志和告警

Fleet 既可以通过图形界面进行管理，也可以通过 API、YAML 文件和命令行工具进行配置。这样可以把设备管理从一次性的控制台操作，扩展为可以审查、版本化和自动执行的基础设施配置。

四、Fleet 的核心组件

1. Fleet Server

Fleet Server 是平台的核心服务端，负责处理 Web 请求、Agent 通信、设备注册、查询调度、策略管理、软件任务、用户和团队等功能。

管理员通过 Fleet Server 管理设备和配置，设备端 Agent 也通过 Fleet Server 获取需要执行的任务和管理信息。

2. Fleet Agent

Fleet Agent 运行在被管理设备上，负责与 Fleet Server 建立连接，并执行设备信息采集、查询、策略检查、软件任务和脚本任务。

Agent 是设备进入 Fleet 管理范围的基础。没有 Agent，Fleet 通常无法持续获得设备的系统信息，也不能向设备下发大部分终端任务。

3. Orbit

Orbit 是 Fleet 使用的设备端 Agent 组件，负责管理 osquery 进程以及部分设备管理任务。它可以让 Fleet 以统一的方式安装、配置和控制设备端的查询能力。

通过 Orbit，Fleet 可以将 osquery 的查询能力接入设备生命周期管理中，减少管理员在每台设备上单独维护 osquery 配置的工作。

4. osquery

osquery 将操作系统信息抽象成类似数据库表的结构。管理员可以使用 SQL 查询硬件、软件、用户、进程、服务、网络连接、文件和安全配置等数据。

例如，设备上的 CPU、内存、磁盘、登录用户和运行进程可以被当作不同的数据表进行查询。Fleet 负责集中管理这些查询，并将查询结果用于资产可见性、策略判断、故障诊断和安全调查。

5. Fleet Desktop

Fleet Desktop 是面向终端用户的设备端界面组件，用于展示设备管理状态或提供部分用户可见的设备管理功能。它可以作为 Fleet 与终端用户之间的交互入口，帮助用户了解设备是否受管理、是否存在待处理任务或是否需要采取操作。

具体显示内容和行为取决于平台、Fleet 版本以及管理员启用的功能。部署时需要根据终端用户体验和组织策略决定是否启用。

6. MySQL 和 Redis

MySQL 用于保存 Fleet 的核心业务数据，例如组织、团队、用户、主机、标签、查询、策略、软件和管理配置等。

Redis 可以用于缓存、队列、锁和临时状态。大规模环境中，数据库连接数、查询写入量、Redis 可用性和后台任务处理能力都会影响 Fleet 的整体性能。

7. 对象存储

部分软件安装包、文件采集结果或其他较大对象可以使用对象存储保存。生产环境需要根据实际启用的功能规划 S3 兼容对象存储、访问权限、生命周期和备份策略。

五、Fleet 如何通过 osquery 管理设备

1. 将设备信息转换为可查询数据

传统资产管理往往依赖 Agent 自定义上报字段，查询能力受限于预先设计的数据结构。osquery 的特点是将操作系统中的多种对象暴露为关系型表，管理员可以使用 SQL 组合多个数据源进行分析。

可以查询的数据类型包括：

• 操作系统名称、版本和内核信息
• 主机名、硬件型号、处理器、内存和磁盘
• 已安装软件及其版本
• 本地用户、登录记录和用户组
• 运行进程、系统服务和启动项
• 网络接口、监听端口和网络连接
• 文件、目录和文件哈希
• 防火墙、磁盘加密和安全配置
• 浏览器、证书和系统扩展等平台信息

2. 实时查询与定期查询

Fleet 支持对设备执行实时查询，也可以配置定期查询。

实时查询适合临时调查和故障诊断，例如确认一批设备上是否存在某个进程、软件版本或配置项。定期查询适合持续采集和趋势分析，例如每天检查磁盘加密状态、操作系统版本或指定软件的安装情况。

一个简化的查询链路如下：

管理员编写 SQL 查询
          |
          v
Fleet Server 选择目标设备
          |
          v
Agent / osquery 执行查询
          |
          v
返回设备数据和执行状态
          |
          v
Fleet 保存、展示或发送结果

3. 查询结果的安全性和隐私

osquery 可以查询的信息范围较广。组织在设计查询时，应明确哪些数据确实用于设备管理和安全调查，避免无边界地收集与工作无关的个人信息。

Fleet 官方强调其目标是让用户能够了解 Agent 的工作方式和组织收集的数据。实际部署时，仍然需要制定查询审批、数据保留、访问授权和隐私告知机制。

六、Fleet 的标签、团队、策略与查询模型

Fleet 通过标签、团队、查询和策略将大量设备组织起来。

1. Labels

Label 可以根据设备属性或查询结果筛选目标设备，例如操作系统、部门、环境、地域、设备用途和业务系统。

标签可以作为软件、策略、查询、脚本和配置文件的目标范围。相比逐台选择设备，基于标签的管理方式更适合设备数量不断变化的组织。

2. Teams

Team 可以将用户、设备、查询、策略和软件配置组织在相对独立的管理范围内。不同团队可以对应不同部门、环境、客户或业务单元。

团队模型可以帮助管理员实现以下目标：

• 将开发、测试和生产设备分开管理
• 让不同运维团队只管理各自负责的设备
• 为不同团队配置不同的查询和策略
• 将软件部署范围限制在指定团队
• 让多租户或多部门场景拥有更清晰的权限边界

3. Policies

Policy 用于判断设备是否满足指定条件。策略通常由 SQL 查询表达，Fleet 根据查询结果判断设备通过或不通过。

策略可以用于检查：

• 操作系统版本是否满足最低要求
• 磁盘加密是否已开启
• 防火墙是否正在运行
• 指定软件是否已安装
• 是否存在不应运行的进程或服务
• 是否满足组织定义的配置基线

策略不只是静态报表，它可以成为软件部署、自动化响应和合规检查的触发条件。使用时需要明确失败状态的处理方式，避免策略数量过多导致管理人员无法区分真正重要的问题。

4. Queries

Query 用于执行 SQL 并采集设备数据。查询可以用于实时诊断、定期数据采集、策略判断和安全调查。

标签、团队、策略和查询之间的关系，可以简化表示为：

设备属性 / 查询结果
          |
          v
        Label
          |
          +-- 选择目标设备
          |
          +-- 分配 Query
          +-- 应用 Policy
          +-- 部署 Software
          +-- 执行 Script
          v
    设备状态与管理结果

七、Fleet 的软件、补丁和配置管理

1. 软件目录与安装

Fleet 可以管理软件目录和设备上的软件安装任务。管理员可以根据操作系统、团队或标签选择目标设备，并通过 Fleet 维护的软件、安装包或自定义安装方式执行部署。

软件管理的常见场景包括：

• 安装企业标准软件
• 向指定设备发布浏览器、办公软件或开发工具
• 删除不允许使用的软件
• 向测试设备先发布新版本
• 统计软件安装成功、失败和等待中的设备
• 让终端用户通过自助方式安装授权软件

2. 补丁和操作系统更新

Fleet 可以用于管理部分操作系统更新和软件更新流程。管理员可以根据设备版本、标签和团队安排更新任务，并观察任务是否成功执行。

补丁管理不能只看“是否发起了更新”，还需要关注下载失败、磁盘空间不足、设备离线、重启要求、版本兼容性和用户工作时间等情况。

3. 配置文件与 MDM

Fleet 支持面向部分平台的移动设备管理和配置文件管理，尤其适合需要集中管理 Apple 设备配置的组织。根据版本和平台能力，也可以管理 Windows 等设备的部分配置。

配置文件可以用于下发系统设置、网络配置、安全要求和设备管理参数。实际使用时需要区分：

• 哪些配置由 Fleet 负责
• 哪些配置由操作系统原生 MDM 负责
• 哪些配置由本地脚本或其他管理系统负责
• 配置冲突时以哪个系统为准

4. 软件和补丁任务的状态跟踪

软件和补丁任务通常不是立即完成的。设备可能处于等待下载、等待执行、执行中、成功、失败或需要重试等状态。

生产环境需要针对任务失败建立处理流程，而不是只关注成功数量。安装包来源、签名校验、版本回滚和失败后的清理，也应纳入软件生命周期管理。

八、Fleet 的脚本、自动化与安全响应

Fleet 支持向目标设备执行脚本和自动化任务，可以用于修复配置、收集诊断信息和执行标准化操作。

常见的自动化场景包括：

• 修复特定系统配置
• 清理临时文件或无效软件
• 收集故障诊断信息
• 检查并修复安全基线
• 触发操作系统内置的更新命令
• 进行设备初始化和环境准备
• 对策略失败设备执行补救操作

脚本能力带来了较高的运维效率，也带来了较大的权限风险。脚本发布前应经过审核、测试和版本管理，并限制脚本可以访问的资源和执行范围。

一条典型的策略响应流程如下：

定期查询设备状态
          |
          v
Policy 判断是否符合要求
          |
      +---+---+
      |       |
      v       v
    通过    不通过
      |       |
      v       v
  记录状态  通知或触发自动化
                  |
                  v
          执行脚本 / 软件任务
                  |
                  v
             再次检查结果

Fleet 可以与安全平台、工单系统和消息系统集成，但自动化响应应设置明确的触发条件和审批边界。高风险操作不宜仅凭单个查询结果自动执行。

九、Fleet 支持的平台与管理场景

Fleet 官方 README 列出的平台和资源范围比较广，包括：

• Linux 各主要发行版
• macOS
• Windows
• ChromeOS
• iOS 和 Android 设备
• AWS、Google Cloud 和 Azure 云资源
• 数据中心设备
• Kubernetes 等容器环境
• 基于 Linux 的物联网设备

不同平台支持的管理能力并不完全相同。osquery 查询、软件部署、脚本执行、MDM 配置和系统更新，都会受到操作系统权限模型和平台接口的影响。

1. Linux 设备

Fleet 对 Linux 提供较完整的可见性能力，可以收集发行版、内核、软件包、服务、进程、用户和网络信息。Linux 设备常见于服务器、云主机、容器节点和开发环境。

2. macOS 设备

macOS 设备可以通过 osquery 获取系统和安全信息，并结合 Apple MDM、配置文件、软件和系统更新能力进行管理。

3. Windows 设备

Windows 设备可以纳入硬件、软件、用户、进程、服务和安全配置查询，也可以根据 Fleet 版本和授权能力使用配置文件、软件、脚本和系统管理功能。

4. 移动设备

iOS、iPadOS 和 Android 设备的管理方式与桌面系统不同，很多能力依赖操作系统提供的 MDM 或企业设备管理接口。组织需要根据设备归属、BYOD 政策和隐私要求确定管理范围。

5. 云资源和容器

Fleet 可以将云环境、数据中心、容器和 Linux 设备纳入更统一的查询和管理视图。对于短生命周期容器，需要特别考虑设备注册时机、数据保留时间和资源标识变化。

十、Fleet 的 GitOps、API、Webhook 与 fleetctl

Fleet 的一个明显特点是将设备管理配置设计成可以被 API 和 GitOps 管理的对象。

1. YAML 配置

管理员可以使用 YAML 描述查询、策略、标签、软件和其他配置，再通过命令行或自动化流水线导入 Fleet。

YAML 配置的价值包括：

• 配置可以进入 Git 仓库
• 变更可以通过 Pull Request 审核
• 不同环境可以使用不同配置文件
• 可以保留历史版本和回滚记录
• 新环境可以通过自动化重复部署

2. REST API

Fleet REST API 可以用于设备查询、标签管理、策略配置、软件任务、用户管理和其他平台操作。外部系统可以通过 API 读取设备状态或触发标准化流程。

API 集成需要设计令牌权限、调用频率、失败重试和审计记录。不要将高权限 API Token 固定写入脚本、镜像或公开仓库。

3. Webhook 和事件驱动

Fleet 可以通过 Webhook 将设备状态、策略结果、软件任务或其他事件发送给外部系统。事件驱动方式适合连接工单、消息通知、SIEM、安全编排和自动化平台。

4. fleetctl

fleetctl 是 Fleet 的命令行工具，可以用于登录 Fleet、管理配置、导入 YAML、执行查询和完成自动化操作。

一个典型的 GitOps 流程如下：

Git 仓库
   |
   | Pull Request 审核
   v
CI/CD 流水线
   |
   | fleetctl / REST API
   v
Fleet Server
   |
   +-- 更新 Labels、Queries 和 Policies
   +-- 更新 Software 和 Scripts
   +-- 更新 MDM 配置
   v
目标设备执行新配置

GitOps 不会自动解决配置设计问题。组织仍然需要区分开发、测试和生产范围，并通过标签、团队和审批流程避免错误配置影响全部设备。

十一、Fleet 适合落地的运维方向

1. 终端资产与软件可见性

Fleet 可以持续收集终端硬件、操作系统、软件、用户、服务和网络信息，帮助运维团队建立比人工表格更及时的设备视图。

2. 安全基线与合规检查

通过 SQL 查询和 Policy，可以检查设备是否启用磁盘加密、防火墙、屏幕锁定和指定安全配置，也可以发现不符合组织要求的软件和系统版本。

Fleet 官方 README 提供面向 macOS 和 Windows 的 CIS Benchmark 能力说明。使用基线时，需要根据企业自身风险和业务要求进行裁剪，不能机械地将所有检查项都设为阻断条件。

3. 远程故障诊断

当终端出现异常时，安全或运维人员可以通过实时查询了解进程、服务、磁盘、网络连接、用户和系统配置，减少逐台登录设备收集信息的时间。

4. 软件标准化与批量发布

Fleet 可以根据标签、团队和操作系统向目标设备发布软件、脚本和配置，适合建设标准软件目录、分批发布和版本验证流程。

5. 补丁与操作系统更新管理

通过软件管理、策略检查和设备状态跟踪，Fleet 可以辅助组织推进补丁和操作系统更新。对于大量设备，应先在测试标签范围内验证，再逐步扩大部署范围。

6. 安全事件调查

发生安全事件时，可以使用查询收集设备上的进程、用户、文件、网络连接和系统配置数据，并按照标签和团队快速缩小调查范围。

7. 服务器与云主机管理

Fleet 可以将 Linux 服务器、云主机、数据中心设备和部分容器环境纳入统一的设备可见性和策略体系，适合混合基础设施场景。

8. 自动化设备管理

通过 GitOps、API、Webhook 和 fleetctl，可以把设备管理纳入持续交付和自动化运维流程，减少重复的控制台操作。

十二、Fleet 的部署方式与基础要求

Fleet 是使用 Go 开发的服务端平台，官方仓库包含服务端、客户端、前端、命令行工具、Terraform 相关内容和测试代码。生产部署可以根据规模和组织习惯选择官方发布包、容器或云平台部署方式。

Fleet 的典型服务端依赖包括：

• Fleet Server
• MySQL 数据库
• Redis
• 可选的 S3 兼容对象存储
• TLS 证书和稳定的 DNS 名称
• 与设备端 Agent 通信的网络入口
• 邮件、身份提供商和外部集成服务

一个简化的生产部署结构如下：

管理员和设备
      |
      | HTTPS / Agent API
      v
负载均衡 / 反向代理
      |
      v
Fleet Server 集群
   |          |
   v          v
 MySQL      Redis
   |
   v
备份、监控和审计系统

可选：S3 兼容对象存储
用于文件、安装包或较大对象

部署时需要根据设备数量、查询频率、软件包大小、并发任务和历史数据保留时间规划资源。Fleet 的性能不仅取决于 Fleet Server 实例数量，也取决于 MySQL 写入、查询结果规模、Redis 队列和对象存储带宽。

十三、使用 Fleet 时需要关注的问题

1. Agent 分发与设备生命周期

Fleet 的管理能力依赖设备端 Agent。组织需要规划 Agent 的分发、升级、卸载、设备重装、主机名变化、设备转部门和设备报废流程。

如果设备离线、Agent 被停止或证书失效，Fleet 中可能仍然保留旧设备记录。需要根据最后汇报时间、设备状态和资产流程定期清理或标记这些设备。

2. 查询量和数据写入压力

查询频率越高、目标设备越多、返回列越多，Fleet Server 和 MySQL 承担的压力越大。查询设计应尽量只返回必要字段，避免高频采集不需要长期保存的大量数据。

3. 权限和团队边界

Fleet 中包含设备信息、软件、用户、进程、网络和安全配置。需要根据运维、安全、人力资源和部门管理职责设计用户角色、团队范围和 API Token 权限。

4. osquery 查询权限

部分 osquery 表需要较高的系统权限，部分查询可能接触敏感信息。组织应建立查询审批、敏感字段控制和结果访问审计机制，并向终端用户说明采集范围。

5. 软件部署的失败处理

软件安装可能因为设备离线、安装包损坏、权限不足、磁盘空间不足或版本冲突而失败。软件目录需要包含版本、校验、依赖、卸载、回滚和失败重试策略。

6. 脚本执行风险

脚本可以执行高权限操作。脚本必须经过代码审查和测试，并限制目标设备、执行时间和运行账户。涉及删除文件、修改安全策略或重启设备的操作，应设置更严格的审批和审计。

7. MDM 和其他管理系统冲突

同一台设备可能同时受到 Fleet、操作系统 MDM、域策略、配置管理工具和安全产品的管理。多个系统对同一配置项同时写入时，可能产生相互覆盖或状态反复变化。

上线前需要明确各系统的责任边界，避免同一配置由多个平台重复控制。

8. 数据保留与隐私保护

Fleet 采集的数据可能包含设备名称、用户、进程、文件、网络连接和软件信息。需要制定数据最小化、保留期限、访问审计、脱敏和删除流程。

9. 高可用和灾备

生产环境需要考虑 Fleet Server、MySQL、Redis、对象存储、DNS、证书和消息投递的可用性。数据库和对象存储备份必须定期验证恢复，而不是只确认备份任务执行成功。

10. 版本升级和开源许可

Fleet 更新可能涉及 Agent、服务端、数据库结构、前端和软件目录变化。升级前应确认版本兼容性、插件或集成影响和回滚方案，同时阅读仓库中的许可证和商业功能说明。

十四、Fleet 的能力边界

Fleet 是设备管理和安全运维平台，但不应被理解为可以替代所有 IT 和安全系统的万能工具。

Fleet 擅长以下工作：

• 统一查看设备、硬件、软件和操作系统信息
• 通过 SQL 查询和策略检查设备状态
• 进行软件、脚本、补丁和部分 MDM 管理
• 以标签和团队为基础管理设备范围
• 通过 API、GitOps、Webhook 和命令行工具自动化操作
• 为终端调查和配置合规提供数据支持

以下能力通常仍需要结合其他系统：

• 完整的网络流量监控和网络性能管理
• 完整的 EDR、杀毒和安全运营响应
• 企业 ERP、采购、财务和资产折旧管理
• 全面的 IT 服务台、工单和知识库流程
• 专业的备份、灾备和应用发布平台
• 所有操作系统上的完全一致的 MDM 能力
• 不经过设计就能自动完成的漏洞修复和安全响应

Fleet 的价值更接近“设备事实数据、管理任务和安全策略的统一控制面”。它可以成为 IT 和安全团队的核心平台之一，但实际效果取决于 Agent 覆盖率、查询设计、数据治理、权限模型和周边系统集成。

十五、Fleet 适合哪些组织

比较适合的情况

• 需要统一管理大量 Windows、macOS 和 Linux 设备
• 希望同时获得设备可见性、软件管理和安全策略能力
• 需要使用 SQL 查询终端状态和安全配置
• 希望将设备管理配置纳入 GitOps 或持续交付流程
• 需要通过 API、Webhook 或 fleetctl 自动化管理
• 同时管理办公终端、服务器、云主机、容器或移动设备
• 已经有安全、运维或平台团队负责 Agent 和服务端维护
• 重视开源透明度、数据可见性和自定义集成能力

需要谨慎评估的情况

• 只需要简单的硬件资产台账，不需要终端持续管理
• 只需要单一操作系统的深度 MDM 能力
• 没有人员维护 Agent、查询、软件包和权限策略
• 期望平台自动解决所有 EDR、补丁、漏洞和工单问题
• 设备网络长期无法访问 Fleet Server
• 没有准备数据库、Redis、对象存储、备份和升级方案
• 组织尚未确定终端数据采集范围和用户隐私要求

十六、总结

Fleet 的核心价值，可以概括为以下几点：

• 使用 osquery 将操作系统数据转换为可查询的设备信息
• 通过 Fleet Server 统一管理设备、查询、策略、软件和脚本
• 通过 Orbit 和 Agent 将管理能力下发到 Windows、macOS、Linux 及其他设备
• 通过 Labels 和 Teams 管理大量设备的范围和权限
• 通过 Policies 持续检查设备是否符合安全和配置要求
• 通过软件、补丁、脚本和 MDM 能力执行设备维护任务
• 通过 GitOps、REST API、Webhook 和 fleetctl 接入自动化流程
• 将 IT 运维和安全调查建立在持续更新的设备事实数据之上

Fleet 不只是一个 osquery 的 Web 管理界面，也不只是一个终端资产清单。它在 osquery 数据采集能力的基础上，增加了设备注册、配置分发、软件管理、策略检查、脚本自动化、MDM 和 GitOps 能力。

对于需要管理大量异构设备的 IT 和安全团队，Fleet 可以提供统一的设备控制面。真正落地时，建议从设备可见性和基础查询开始，再逐步引入策略、软件、补丁、脚本、MDM 和自动化，避免一开始配置过多功能导致权限、数据和任务管理失控。

参考资料

1. Fleet GitHub 主项目
2. Fleet 官方文档
3. Fleet 架构文档
4. Fleet YAML 配置文档
5. Fleet fleetctl 命令行工具下载
6. Fleet Live Queries 与查询数据说明
7. Fleet Policies
8. Fleet Software Management
9. Fleet Scripts
10. Fleet CIS Benchmarks
11. Fleet API Documentation
12. Fleet GitHub Releases
13. Fleet v4.90.1 Release
14. osquery GitHub 主项目
15. Fleet LICENSE

本文用于项目认知和应用方向分析。具体部署时，需要结合设备规模、操作系统类型、Agent 覆盖范围、查询频率、软件包管理、数据库性能、权限模型、数据隐私和安全运营流程进行验证。