运维观测指标监控告警【免费下载链接】falcon-plusAn open-source and enterprise-level monitoring system.项目地址https://gitcode.com/gh_mirrors/fa/falcon-plus点击查看免费下载Open-Falconfalcon-plus是开源的企业级监控系统由 agent、transfer、graph、judge、alarm、hbs、api 等多个模块组成。本指南以仓库 docker/k8s-cluster/README.md 为纲结合 docker/k8s-cluster 目录下的全部支撑文件构建脚本、Dockerfile 模板、10 个模块的 Kubernetes 资源清单完整讲解如何把 open-falcon 以分布式方式部署到 Kubernetes 集群从源码编译出镜像、解析各模块的 Service/Deployment 清单到有状态组件 graph 的落地要点与配置持久化方案。读完本文你将掌握一套可复制的 open-falcon 容器化上 K8s 的完整操作路径。一、部署方案总览模块划分与端口规划原文档明确这是一套“分布式部署”方案open-falcon 的各个功能模块被拆分为独立的容器通过 K8s 的 ServiceClusterIP与 Deployment 组织在统一的open-falconnamespace 下。仓库 docker/k8s-cluster/modules 目录提供了 10 份 YAML覆盖监控系统全链路模块作用依据仓库源码目录推断Service 端口镜像falcon-agent宿主机/容器数据采集见 modules/agent1988/httpagent:v0.3falcon-api统一 API 入口见 modules/api8080/httpapi:v0.3falcon-hbs心跳服务与策略下发见 modules/hbs6030/rpc、6031/httphbs:v0.3falcon-judge告警判定见 modules/judge6080/rpc、6081/httpjudge:v0.3falcon-graph-01历史数据存储与查询见 modules/graph6070/rpc、6071/httpgraph:v0.3falcon-transfer数据汇聚转发见 modules/transfer6060/http、8433/rpctransfer:v0.3falcon-alarm告警事件消费与通知见 modules/alarm9912/httpalarm:v0.3falcon-nodata数据缺失检测见 modules/nodata6090/httpnodata:v0.3falcon-aggregator集群聚合计算见 modules/aggregator6055/httpaggregator:v0.3falcon-dashboard可视化面板由 falcon-dashboard.yaml 编排端口以该文件为准—dashboard:v0.3以 falcon-transfer.yaml 为例每个模块都由“Service Deployment”两段式清单组成Service 声明为type: ClusterIP并提供集群内稳定访问地址Deployment 的 selector 通过name: falcon-模块标签完成关联。这种“一个模块一个 Service/Deployment”的编排方式与 falcon-plus 各模块通过 RPC 相互调用的架构transfer→graph、judge→hbs、alarm→judge 等一一对应天然契合分布式部署语义。二、镜像构建从源码到可运行的容器镜像2.1 源码获取原文档给出的第一步是克隆源码仓库git clone https://gitcode.com/gh_mirrors/fa/falcon-plus.git cd falcon-plus2.2 init.sh 与 Makefile 的编译打包链路原文档提到的构建命令是./docker/k8s-cluster/build.sh但需要说明的是当前仓库的 docker/k8s-cluster 目录下实际提供的是 init.sh 与 Dockerfile.tpl 两个构建支撑文件并未包含 build.sh 本体。因此镜像构建的真实链路要从这两份文件还原init.sh 设计为在 Alpine 容器内执行脚本开头使用apk add#!/bin/sh apk add --no-cache ca-certificates git bash \ make all \ make pack4docker \ tar -zxf open-falcon-v*.tar.gz -C build \ rm open-falcon-v*.tar.gz其内部环节与仓库根目录 Makefile 中的目标一一对应make all编译全部模块的可执行文件Makefile 中go build -ldflags -X main.BinaryName$ ...输出到bin/模块/falcon-模块make pack4docker见 Makefile该目标会为每个模块创建out/模块/{bin,config,logs}目录执行cp ./config/模块.json ./out/模块/config/cfg.json将仓库 config 目录下的标准配置拷为各模块的cfg.json并把编译产物拷入bin目录此外做三个特殊处理——agent 模块额外复制modules/agent/public静态资源并建立public、plugin软链api 模块额外复制modules/api/datagraph 模块创建空的data目录。最后整体打包为open-falcon-vVERSION.tar.gzVERSION来自仓库根目录 VERSION 文件解压该 tar 包到build/目录作为后续 Docker 镜像的构建上下文。2.3 Dockerfile.tpl模块镜像模板Dockerfile.tpl 是一份带占位符的模板%%MODULE_NAME%%在构建每个模块镜像时被替换为对应模块名FROM alpine:3.7 LABEL maintainer tabspqq.com USER root ENV FALCON_DIR/open-falcon # agent RUN apk add --no-cache ca-certificates git curl # alarm ADD https://github.com/golang/go/raw/master/lib/time/zoneinfo.zip /usr/local/go/lib/time/zoneinfo.zip COPY build/%%MODULE_NAME%% ${FALCON_DIR}/%%MODULE_NAME%% WORKDIR ${FALCON_DIR} CMD [/open-falcon/%%MODULE_NAME%%/bin/falcon-%%MODULE_NAME%%, -c, /open-falcon/%%MODULE_NAME%%/config/cfg.json]几点值得展开基础镜像为alpine:3.7通过apk add --no-cache ca-certificates git curl补齐证书与工具其中ca-certificates是各模块发起 HTTPS/RPC 调用的必需依赖镜像内约定统一布局FALCON_DIR/open-falcon模块目录为/open-falcon/模块内含bin/falcon-模块与config/cfg.json容器启动命令固定为falcon-模块 -c /open-falcon/模块/config/cfg.json——这也解释了为什么 K8s 清单中要把配置目录单独挂载出来配置以文件形式外置容器内不内置任何环境定制alarm 模块额外通过ADD注入 Go 的时区数据库zoneinfo.zip保证告警时间计算跨时区正确。可以推断原文档所提的 build.sh 的职责应是先以含 Go 工具链的镜像运行 init.sh 完成编译打包再针对每个模块用 Dockerfile.tpl 渲染并执行docker build最终把镜像推送到私有仓库。读者在自建该脚本时只要按“init.sh 编译 → Dockerfile.tpl 渲染 → docker build → push”四步实现即可或直接用下面 2.4 的预构建镜像跳过此环节。三、Kubernetes 资源清单深入解析3.1 统一的清单骨架10 份 YAML 结构高度一致均以 falcon-hbs.yaml 为范式apiVersion: v1 kind: Service metadata: namespace: open-falcon name: falcon-hbs labels: app: open-falcon spec: type: ClusterIP ports: - name: rpc port: 6030 - name: http port: 6031 selector: name: falcon-hbs --- apiVersion: extensions/v1beta1 kind: Deployment metadata: namespace: open-falcon name: falcon-hbs labels: app: open-falcon spec: replicas: 1 template: metadata: labels: name: falcon-hbs spec: containers: - name: falcon-hbs image: registry.cn-hangzhou.aliyuncs.com/open-falcon/hbs:v0.3 imagePullPolicy: IfNotPresent ports: - containerPort: 6030 name: rpc protocol: TCP - containerPort: 6031 name: http protocol: TCP volumeMounts: - mountPath: /open-falcon/hbs/config name: falcon-hbs-config - mountPath: /etc/localtime name: tz-config volumes: - flexVolume: driver: alicloud/nas options: path: /open-falcon/falcon-hbs/config server: xxx.cn-hangzhou.nas.aliyuncs.com vers: 4.0 name: falcon-hbs-config - hostPath: path: /etc/localtime type: name: tz-config关键约定namespace全部资源统一置于open-falcon部署前需先创建该 namespaceService 类型全部为ClusterIP仅在集群内可见跨模块 RPC 通过 Service DNS 名如falcon-graph-01.open-falcon.svc互访对外暴露如 API 的 8080、dashboard 面板需另行叠加 Ingress 或改为 NodePort/LoadBalancer端口命名rpc/http 端口的 name 字段与容器端口一一对应便于 Service 到 Pod 的映射也提示了各模块“RPC 端口 HTTP 端口”的双端口惯例agent、api、alarm、nodata、aggregator 仅暴露 http。3.2 镜像来源策略原文档第 3 条注意点给出了两种镜像来源选择推荐自建镜像推私有仓库——通过构建脚本构建后推送镜像地址可在原文档所指的build.sh 中查看或修改直接使用预构建镜像——实际仓库中各 YAML 的image字段已写明具体地址例如registry.cn-hangzhou.aliyuncs.com/open-falcon/agent:v0.3registry.cn-hangzhou.aliyuncs.com/open-falcon/graph:v0.3registry.cn-hangzhou.aliyuncs.com/open-falcon/api:v0.3registry.cn-hangzhou.aliyuncs.com/open-falcon/transfer:v0.3所有模块镜像均带v0.3标签imagePullPolicy: IfNotPresent表示本地已有时不再拉取。生产环境建议将上述地址批量替换为自建私仓地址避免依赖外部仓库。3.3 配置持久化与数据卷设计每个 Deployment 都挂载两类卷详见 falcon-graph-01.yaml 等清单config 卷采用flexVolume驱动alicloud/nas将远端 NAS 目录/open-falcon/模块/config挂载到容器内/open-falcon/模块/configserver指向阿里云 NAS 挂载点示例为xxx.cn-hangzhou.nas.aliyuncs.comvers: 4.0指定 NFS 协议版本。这意味着各模块的 cfg.json 直接存放在 NAS 上Pod 重建后配置不丢失——这正是原文档第 2 条注意点“所有配置文件使用挂载目录的方式持久化”的落地形态tz-config 卷hostPath挂载宿主机/etc/localtime到容器同名路径保证容器与宿主机时区一致graph 的 data 卷graph 除 config 卷外还额外挂载了/open-falcon/graph/data对应 Makefile 中mkdir out/graph/data的约定用于持久化历史数据。3.4 有状态组件 graph 的特殊处理原文档第 1 条注意点专门强调了 graphgraph 为有状态组件部署方式为每个节点一个 Deployment同时 replica 设置为 1。对照 falcon-graph-01.yaml 可以看到落实细节命名带编号后缀falcon-graph-01暗示同一套方案下 graph 可拆为多个分片实例falcon-graph-02、03……每个分片独占一个 Deploymentreplicas: 1强制单副本——graph 负责数据落盘多副本并写会破坏一致性每个 graph 实例的 config 与 data 均挂载独立的 NAS 路径/open-falcon/falcon-graph/01/{config,data}分片数据物理隔离。从源码看graph 模块依赖本地 RRD 数据文件见 modules/graph/rrdtool 与 modules/graph/store并以分片方式水平扩展transfer 端通过一致性哈希将数据路由到不同 graph 实例见 modules/transfer/sender 的 node_rings 设计。因此“一实例一 Deployment、副本固定为 1、数据独立持久化”是保证历史数据正确性的必要条件。四、部署步骤从清单到运行综合上述文件一套完整部署流程如下创建 namespacekubectl create namespace open-falcon准备存储与配置在阿里云 NAS 上创建目录结构/open-falcon/模块/configgraph 另加/open-falcon/falcon-graph/01/data将仓库 config 下对应模块的 JSON 配置如 transfer.json、graph.json改名为cfg.json后放入各 NAS config 目录并按集群内 Service 名修正配置中的后端地址例如 graph 地址、transfer 地址等修改各 YAML 中flexVolume.options.server为实际 NAS 挂载点path与目录结构对齐若集群未安装阿里云 NAS flexVolume 插件需先安装否则 volumes 无法挂载。应用模块清单按依赖顺序先 hbs/graph/transfer 等基础模块再 judge/alarm/api/dashboardkubectl apply -f docker/k8s-cluster/modules/falcon-transfer.yaml kubectl apply -f docker/k8s-cluster/modules/falcon-graph-01.yaml kubectl apply -f docker/k8s-cluster/modules/falcon-hbs.yaml # 其余模块同理逐个 apply验证kubectl -n open-falcon get svc,deploy,pod各模块STATUS进入 Running 后可访问 api 的 8080 端口经 Ingress 或端口转发验证接口可用agent 部署在需要采集的节点上后可在其 1988 端口查看采集状态页。五、配置管理演进从目录挂载到 ConfigMap原文档第 2 条注意点明确给出了演进方向所有配置文件使用挂载目录的方式持久化可以改为 ConfigMap 管理配置。当前方案的 config 卷是“NAS 目录 flexVolume”形态其优点是配置与容器解耦、便于运维直接改文件缺点是依赖特定云厂商的 flexVolume 插件。若要改为原生 K8s 的 ConfigMap可做如下等价改造以 hbs 为例# 1. 用 ConfigMap 承载 cfg.json 内容 apiVersion: v1 kind: ConfigMap metadata: namespace: open-falcon name: falcon-hbs-config data: cfg.json: | { ...hbs 配置内容... } --- # 2. Deployment 中以 configMap 卷替换 flexVolume 卷 volumes: - name: falcon-hbs-config configMap: name: falcon-hbs-configConfigMap 方案的优势是配置随清单版本化、可审计、可回滚但注意 graph 的 data 卷仍必须保留持久化存储如 NAS/云盘/PVC因为那是真正的有状态数据不能用 ConfigMap 承载。六、注意事项与已知限制结合原文档的 3 条注意点与清单实际内容部署前还应关注以下边界API 版本兼容性全部 Deployment 使用apiVersion: extensions/v1beta1该版本在 Kubernetes 1.16 起被移除、1.9 起废弃。部署到现代集群1.16时需将 Deployment 段改为apps/v1字段结构基本一致仅 apiVersion 与部分字段变化否则kubectl apply会报未知 API 版本。存储插件依赖config/data 卷依赖alicloud/nasflexVolume 驱动与 NFS 4.0 协议非阿里云集群需替换为等价方案NFS 静态卷、CSI 驱动或 hostPath 的替代品。graph 扩容语义graph 每个分片一个 Deployment、副本固定 1扩容新分片时需要同步调整各模块配置中 graph 实例列表transfer 的 node_rings 与 api 的 graph 地址列表不可简单kubectl scale副本数。agent 的部署位置agent 承担宿主机指标采集见 modules/agent/funcs 的 cpu、mem、disk 等采集器若要采集 K8s 节点指标建议以 DaemonSet 形态部署到各节点而不是单一 Deployment 副本。dashboard 依赖外部组件falcon-dashboard 为可视化面板其清单由 falcon-dashboard.yaml 编排端口与配置以其文件内容为准同时整体方案还依赖外部 MySQL 与 Redis可参考仓库 docker/k8s-example 中的 mysql.yaml、redis.yaml 示例搭建。结语本方案把 open-falcon 的模块化架构原样映射到 Kubernetes无状态组件以标准 Deployment 承载、配置外置到 NAS、有状态组件 graph 以一实例一 Deployment 的方式落地并保持单副本。以 docker/k8s-cluster/README.md 为纲、以 docker/k8s-cluster/modules 的 10 份清单为模板再结合本指南的镜像构建链路与 ConfigMap 演进建议即可在自有集群上快速复现一套生产可用的 open-falcon 监控系统。赞分享运维观测指标监控告警【免费下载链接】falcon-plusAn open-source and enterprise-level monitoring system.项目地址https://gitcode.com/gh_mirrors/fa/falcon-plus点击查看免费下载相关推荐Plano 快速上手指南搭建 LLM 模型网关、Agent 编排与可观测性Plano 快速上手指南搭建 LLM 模型网关、Agent 编排与可观测性 Plano 是一个面向 Agentic 应用的 AI 原生代理服务器数据平面运维观测指标监控告警Open-Falcon falcon-plus 创建 HostGroup机器分组API 实战指南Open Falcon falcon plus 创建 HostGroup机器分组API 实战指南 导读 本文围绕 falcon plusOpen Falc运维观测指标监控告警Solid 表单组合利器深入解析 tanstack/solid-form 的 WithFormProps 与 withForm 高阶组件Solid 表单组合利器深入解析 tanstack/solid form 的 WithFormProps 与 withForm 高阶组件 在 TanStac运维观测指标监控告警上一篇CzkawkaKrokiet三步清理重复文件教程释放磁盘空间的完整指南下一篇告别手速焦虑B站会员购抢票终极指南5分钟快速上手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考