diff --git a/docs/whizard-docs/_category_.json b/docs/whizard-docs/_category_.json index 8cf96a6..8c323d5 100644 --- a/docs/whizard-docs/_category_.json +++ b/docs/whizard-docs/_category_.json @@ -1,5 +1,5 @@ { - "label": "Whizard Docs", + "label": "Whizard", "position": 7, "link": { "type": "generated-index" diff --git a/docs/whizard-docs/getting-started/architecture.md b/docs/whizard-docs/getting-started/architecture.md index a306699..9d2181b 100644 --- a/docs/whizard-docs/getting-started/architecture.md +++ b/docs/whizard-docs/getting-started/architecture.md @@ -5,3 +5,28 @@ description: Whizard 架构设计 # Whizard 架构 +## 架构 + +- 全部组件通过 CRD 定义 +- 引入租户体系，便于租户隔离；并可通过 Gateway/Agent Proxy 机制保证租户写入数据安全与隔离 +- 引入各组件的动态伸缩机制：Ingester, Store, Ruler, Compactor +- 引入分片机制：全局的 Ruler 可根据规则组进行分片，均衡负载 +- 引入基于租户的数据生命周期管理机制，租户删除后将删除磁盘及对象存储上的遗留数据。 +- 查询优化：近期数据查询磁盘（36h），长期数据可查对象存储 +- 没有对象存储也可以仅利用本地磁盘存储数据 + +![whizard_arch](./img/whizard_arch.png) + + +## Whizard CRDs + +- Service：定义一个 Whizard 服务及该服务所需的租户元信息、对应的长期存储及组件配置等 +- Tenant：定义一个使用 Whzard 服务的租户，包括租户 ID 及分配给该租户的 Ruler, Ingester, Compactor；集成到 KubeSphere 租户对应于集群 +- Gateway：接收各租户 (whizard-agent-proxy) remote write 写入数据的网关，可定义用于安全通信的证书 +- Storage：定义 Prometheus 长期存储需要的对象存储及租户长期数据管理相关信息（Block 生命周期管理） +- Query & QueryFrontEnd：用户查询所有 metrics 的统一接口 +- Router：根据租户标签分发写入的 Metrics 数据到相应 Ingester +- Ingester：接收一个或多个租户的写入数据，每个租户一个 tsdb（没有数据抓取能力的 Prometheus）；可上传落盘 block 到对象存储 Whizard 新增根据租户数量自动伸缩 Ingester 实例的功能（默认每个 Ingester 处理 3 个租户的数据）；以及已删除租户的本地磁盘数据清理的功能 +- Ruler：根据 remote write 过来的原始数据计算 recording rule 生成 metrics，计算 Alert rule 发出告警, Whizard 新增为每个租户分配独立的 Ruler 的功能；以及全局 Ruler 可将 RuleGroup 在多个副本间进行分配以均衡 Rule 计算工作负载的问题 +- Compactor：用于存放在对象存储的 block 的压缩和降采样。Whizard 新增根据租户数量自动伸缩 Compactor 实例的功能（默认每个 Compactor 处理 10 个租户的数据）；以及已删除租户的对象存储数据清理的功能 +- Store：Query & QueryFrontEnd， Ruler 等组件查询对象存储上长期数据的接口 diff --git a/docs/whizard-docs/getting-started/img/whizard_arch.png b/docs/whizard-docs/getting-started/img/whizard_arch.png new file mode 100644 index 0000000..73e5de3 Binary files /dev/null and b/docs/whizard-docs/getting-started/img/whizard_arch.png differ diff --git a/docs/whizard-docs/getting-started/storage.md b/docs/whizard-docs/getting-started/storage.md index 404b91e..3069994 100644 --- a/docs/whizard-docs/getting-started/storage.md +++ b/docs/whizard-docs/getting-started/storage.md @@ -45,10 +45,10 @@ spec: bucket: "xxxxxxxxxx" endpoint: "s3.pek3b.qingstor.com:443" accessKey: - name: storage-secret + name: storage-remote-secret key: accessKey secretKey: - name: storage-secret + name: storage-remote-secret key: secretKey EOF ``` diff --git a/docs/whizard-docs/getting-started/whizard-alerting.md b/docs/whizard-docs/getting-started/whizard-alerting.md deleted file mode 100644 index f35b1b6..0000000 --- a/docs/whizard-docs/getting-started/whizard-alerting.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -sidebar_position: 2 -description: Whizard 告警简介与演进计划 ---- -# Whizard 告警 - -## 1. Whizard 对开源社区告警方案的增强 - -- 对告警规则更高维度、更细粒度的管理: - 从用户权限和告警规则的生效范围以规则组为单位定义了以下三个 CRD，以便于实现多集群、多租户、多层级的告警功能： - - GlobalRuleGroup：对应的实例可以配置对所有集群或若干个指定的集群生效，平台管理员角色的用户可以进行这类规则组的管理。 - - ClusterRuleGroup: 仅对其实例所在的集群生效，集群管理员角色的用户可以为所管理的特定集群配置这类规则组进行告警。 - - RuleGroup: 仅对其实例所在的项目生效，项目下的成员可以管理该类规则组。 - - 所有规则组产生的告警消息除了告警目标的标签，还通过集群、项目、层级等标签来丰富和细化，以期提供更加精准定位告警源的信息。 - - **Whizard 告警规则定义与 Prometheus 社区告警规则定义对比** - - | | GlobalRuleGroup/ClusterRuleGroup/RuleGroup | PrometheusRule | - | ---------- | ---------------------------- | ------------------------ | - | 配置粒度 | 以单个规则组为配置单位，可以精细控制 | 每个实例包含多个规则组，不易定位 | - | 并发性 | 支持多个规则组并发更新 | 并发修改多个规则组容易冲突 | - | 多集群 | 根据资源层级和配置自动控制生效集群 | 不支持| - | 多租户 | 根据资源层级和位置自动注入权限过滤条件 | 不支持| - - > GlobalRuleGroup/ClusterRuleGroup/RuleGroup 还提供了与 PrometheusRule 的兼容性支持。 - -- 分片机制应对高并发大规模数据集告警 - 通过分片机制，Whizard Ruler 可以提高告警方面的扩展性和性能，并允许处理大规模数据集； -- 跨集群告警 - Whizard Ruler 允许跨多个集群对告警规则进行集中管理和配置。这意味着您可以使用单个Ruler实例来管理和触发多个集群中的告警，而无需为每个集群配置独立的告警规则。这样可以简化告警配置和管理的工作流程； -- 高可用性 - Whizard Ruler支持高可用性配置，通过部署多个 Ruler 实例和使用负载均衡器，可以确保告警系统的高可靠性和容错能力。如果一个 Ruler 实例发生故障，其他实例可以接管其功能，从而避免单点故障； -- 数据持久化： - Whizard Ruler 可将告警规则(Alerting Rule)和数据预处理规则(Recording Rule) 的计算结果分租户（集群）持久化到相应租户的长期存储系统中（如对象存储）。这使得告警数据的长期保存成为可能，您可以对历史告警进行回顾和分析 - -## 2. Whizard 与 ThanosRuler（Prometheus-Operator） 的对比 - -| | WhizardRuler | ThanosRuler | -| ---------- | ---------------------------- | ------------------------ | -| 跨集群告警 | 天然支持 | 可实现，依赖手动繁琐配置 | -| 高可用性 | 健壮 | 健壮 | -| 分片能力 | 支持 | 不支持 | -| 定制程度 | 与 KubeSphere 告警有深度定制 | 依赖手动配置 | -| 灵活程度 | 当前稍弱，功能演进中 | 良好 | -| 数据持久化 | 天然支持 | 额外配置存储 | - - diff --git a/docs/whizard-docs/intro.md b/docs/whizard-docs/intro.md index 09964a3..dae51c0 100644 --- a/docs/whizard-docs/intro.md +++ b/docs/whizard-docs/intro.md @@ -7,19 +7,31 @@ description: Whizard is a Prometheus Long-Term Storage powered by Thanos 简短说明 Whizard 是什么，不是什么。 -Whizard 是一个基于 Thanos 的 operator，专为多租户的 Prometheus 长期存储而设计。它通过定义 Thanos 相关组件的配置，并抽象出服务、存储和租户等自定义资源定义（CRD），实现了开箱即用的体验。 +Whizard 是高可用、可扩展、可存储与查询海量监控数据、易运维、安全的 Prometheus 长期存储方案，提供 Thanos 及相关监控组件的 Kubernetes 原生部署和管理。 -Whizard 在 Thanos 之上，增强并简化 Thanos 多租户部署和管理。 -## 为什么选择 Whizard？ +## 功能亮点 + +- 云原生化部署与运维：所有组件均支持以 CRD 的方式定义与维护，更易于配置与运维。包括 Thanos 的 Router, Ingester, Compactor, Store, Query, QueryFrontend, Ruler 等组件以及 Whizard 引入的 Service, Tenant, Storage 等。 + +- 基于租户的自动水平扩展机制：基于 CPU 与 Memory 的 HPA 对于稳定性要求更高的企业级有状态工作负载并不是最好的选择，为此 Whizard 创造性地引入了基于租户的工作负载水平伸缩机制。Ingester，Compactor，Ruler 等均支持随着租户的创建与删除进行水平伸缩，保证租户工作负载稳定运行的同时，提供了租户级别的水平扩展与资源回收机制。 + +- 适配 K8s 多集群管理：为了对 K8s 多集群监控告警提供更好的支持，Whizard 的维护者开发了 whizard-adapter ，可根据 K8s/KubeSphere 集群的创建与删除自动创建或删除 Whizard 的租户，进而触发 Thanos 有状态工作负载的自动水平伸缩。 + +- 规则计算更好的扩展性：Thanos 原生的 Ruler 的水平扩展性并不好，无法满足海量 K8s 集群(租户)的 Alerting Rules 与 Recording Rules 的计算需求。为此 Whizard 的维护者为每个租户引入了专属的 Ruler，其可随着租户的生命周期自动创建与删除；除了租户专属的 Ruler， Whizard 的维护者还引入了全局 Ruler 的分片机制，用于满足跨海量集群(租户)的全局规则(Alerting rules or Recording Rules)计算需求; 此外 Thanos Ruler 目前尚不支持将计算后的各租户的 recording rules 分别写入各自租户的 Ingester，Whizard 的维护者为此也做了额外的支持。 + +- 更细粒度的规则管理：目前社区流行用 PrometheusRule 来管理 Prometheus recording rules 及 alerting rules，这种方式存在的问题是 PrometheusRule 里存在属于多个规则组的多条规则，粒度过大，不宜并发编辑与维护。为了解决这个问题，Whizard 维护者引入了更细粒度的 RuleGroup 的 CRD 用于管理属于一个规则组内的所有规则；此外还引入了3-tiers 的 RuleGroup 管理机制，RuleGroup 用于管理某一 namespace 下的规则组；ClusterRuleGroup 用于管理某一集群范围内的集群规则组；GlobalRuleGroup 用于管理扩跨多集群范围的全局规则组；在做到更细粒度规则管理的同时，满足了企业用户对不同权限范围的规则进行单独管理的需求。 + +- 支持对象存储网关 Store 的按时间分片查询：Thanos 通过将 Prometheus 的数据写入对象存储并支持从对象存储查询海量的监控数据，如果查询的时间范围过大，会导致 Store 占用资源过多，为止 Whizard 的维护者为 Store 加入了按时间分片查询的机制，用户可以根据要查询的时间段分别创建不同的 Store CRD。 + +- 引入 Gateway 及 Agent Proxy 以对数据的写入与读取进行更好的控制：客户端如 Prometheus Agent 或 Prometheus 无需直接与 Gateway 交互，通过 Whizard Agent Proxy 即可代理数据写入与查询请求至 Whizard Gateway，Whizard Gateway 进而可根据租户的权限放行或拒绝查询或写入请求。 + +- 支持企业级的安全需求：企业用户通常对安全性有更高的需求。Whizard 除了支持组件间更方便的配置 tls 之外，还将 Thanos 的 WebUI 通过 Whizard Gateway 暴露出来并支持 Basic Auth 与 OAuth2-Proxy 两种认证方式，企业用户可以更安全的访问 Thanos 的 WebUI. + +- 更方便的 2-Tiers 组件配置：Whizard 支持 Service 与 Comopnents 两级组件配置，通用的配置可放在全局的 Servce 里做统一配置，各租户的所有组件共用；特殊的定制化配置可放在单独的 Component 里做个性化的定制。 -- **多租户支持**：Whizard 专为多租户环境设计，使不同的租户可以共享相同的基础设施而互不干扰。 -- **自动化管理**：通过 operator 模式，Whizard 自动化了 Thanos 组件的部署、扩展和运维，减少了手动配置和管理的复杂度。 -- **开箱即用**：Whizard 定义了清晰的 CRD，使用户可以快速上手和使用，无需深入了解底层的 Thanos 配置细节。 -- **自动扩缩容**：Whizard 可以依据租户数量自动调整组件的副本数，确保资源的高效利用。 -- **可扩展性**：它利用 Kubernetes 的原生扩展能力和 Thanos 的强大功能，提供了灵活和可扩展的长时间存储解决方案。 ## 接下来做什么？ -- 参阅入门指南 — [立即开始](https://whizardtelemetry.github.io/docs/whizard-docs/getting-started/)！ -- 了解 [Whizard 的概念](https://whizardtelemetry.github.io/docs/whizard-docs/concepts/)。 +- 参阅入门指南 — [立即开始](https://whizardtelemetry.github.io/docs/category/%E5%BC%80%E5%A7%8B%E4%B8%8A%E6%89%8B)！ +- 了解 [Whizard 的概念](https://whizardtelemetry.github.io/docs/category/%E6%A6%82%E5%BF%B5/)。