HarishHary/blink

# Blink Blink 是一个**事件驱动的检测引擎**。原始事件流经一系列 Kafka topic 链，每个 topic 都由一个应用单一转换的小型 Go microservice 消费，最终派发出告警。检测逻辑存在于 **plugins** 中——每个 plugin 都作为独立的子进程（通过 gRPC 使用 `hashicorp/go-plugin`）运行，因此单个有缺陷的规则不会搞垮整个 pipeline。 ## Pipeline ``` events → event_matcher pre-filter: which rules is each event eligible for? → rule_executor evaluate rule plugins, emit alerts → alert_merger dedupe/merge by merge_by_keys within a time window → rule_tuner adjust severity / confidence → alert_enricher add external context → alert_formatter shape for delivery → alert_dispatcher send (Slack, etc.) ``` ## 控制平面 一个独立的控制平面（`cmd/controller`）负责将每种 plugin 类型的 YAML 配置与后端存储进行协调，并将最终生效的期望状态发布为**按 ID 键控、经过日志压缩的 Kafka 快照**。每个 pipeline pod 都会消费其对应类型的快照，并协调其 plugin 子进程——没有任何 pod 会从本地磁盘读取 plugin 配置。 两个平面都运行着**相同的 reaction loop**：_source_ 组装出一个 `Snapshot` 并触发一个合并信号；与之并行运行的 _subscriber_ 则会重新读取最新的快照并重新同步。 ``` YAML edit -▶ LocalReader --elect--▶ PluginController --▶ ═══ Kafka snapshot topic ═══ (control plane) (writer, + DB) │ broadcast to every pod ▼ SnapshotReader --signal--▶ PluginExecutor --▶ spawn / kill subprocs (per pod) (subscriber) ``` `LocalReader:PluginController` 和 `SnapshotReader:PluginExecutor` 是一对孪生组件（共享同一个 `SnapshotSource` 接口）；每个 source 都有且仅有一个 subscriber，而“多读者”的横向扩展是通过跨 pod 的 Kafka 广播来实现的——而不是通过多个 subscriber。完整的代码流程与具体示例：**[docs/internals/reconcile-loop.md](docs/internals/reconcile-loop.md)**。 ## Plugins 共有五种 plugin 类型——`rules`、`matchers`、`tuning_rules`、`enrichments`、`formatters`——每种都在 `pkg//` 下定义并提供 Go SDK，同时在 `examples//` 下提供示例配置。Plugins 支持 `blue_green` / `canary` / `shadow` 发布模式。 ## 目录结构 | 路径 | 说明 | | -------------- | ------------------------------------------------------------------------------------ | | `cmd/` | 八个服务（七个 pipeline 阶段 + `controller`） | | `internal/` | Kafka broker、控制平面、plugin runtime、进程池、配置、backends | | `pkg/` | 领域类型（`events`、`alerts`、`scoring`）+ 各类型的 plugin SDK | | `deployments/` | Kubernetes Helm charts：Kubernetes 集群 + topic、Blink 服务以及 KEDA autoscaling | | `examples/` | 示例 plugin 配置 | | `docs/` | 架构与内部原理（见下文） | ## 文档 - **[`docs/internals/message-flow.md`](docs/internals/message-flow.md)** - 每次消息跳转的权威参考：schema、具体示例以及边缘情况。 - **[`docs/internals/performance.md`](docs/internals/performance.md)** - 扩展性：batching、进程池、partitions/pods、`log_type` 发布、autoscaling、DLQ 以及边缘情况。 - **[`docs/internals/partitioning.md`](docs/internals/partitioning.md)** - 三种“键”（Kafka 分区键 vs `PoolKey` vs 金丝雀哈希键）、实际示例以及合并的同地协同。 - **[`docs/internals/reconcile-loop.md`](docs/internals/reconcile-loop.md)** - subscribe → coalescing-signal → re-read → re-sync 循环，在两个平面上互为镜像（`LocalReader`→`PluginController` 和 `SnapshotReader`→`PluginExecutor`），包含代码流程与实际示例。 - [`docs/services/`](docs/services/) - 按服务划分的参考。[`docs/internals/`](docs/internals/) - plugin 系统内部原理。 ## 快速开始 - **[DEVELOPMENT.md](DEVELOPMENT.md)** - 前置条件、本地设置、常用命令。 - **[deployments/README.md](deployments/README.md)** - 在 Kubernetes 上运行（Podman/Minikube）。 - **[CONTRIBUTING.md](CONTRIBUTING.md)** - 如何参与贡献。 Kubernetes charts 共享 `deployments/helm/values.yaml`：`global.logTypes` 控制 按 log 类型划分的 matcher/executor 资源，而 `global.sharedStages` 定义了 共享的告警阶段 Deployment、topic、group、可选的 DLQ 以及可选的 scaler 名称。 `withDLQ` 和 `withScaler` 控制条件生成；在获得 runtime 支持之前，merger 和 dispatcher DLQ 将保持禁用状态。请参阅 [deployments/README.md](deployments/README.md) 获取完整的派生名称表。

标签：EVTX分析, Go语言, Kafka, Python工具, SonarQube插件, 事件驱动架构, 告警系统, 子域名突变, 日志审计, 检测引擎, 程序破解