事件墙系统简介
用一条时间线并排看变更和多路告警，便于对照发布与告警、支撑复盘；变更与告警事实亦可作为智能分析与根因讨论的锚点。
线上出事时，我们通常要同时搞清楚两件事：哪儿不健康（可以看北极星、灭火图），以及这段时间线上到底发生了什么——尤其是发布、配管、扩缩容这类变更，再配上夜莺、北极星、灭火图等各路告警，是不是在时间上凑在一起。很多团队的经验是：先对着时间线把变更看一眼，往往比闷头查半天日志更省时间。
事件墙就做这一件事：把多类关键事件收进一页里，横轴是时间，不同类型可以占不同「行」或区域，一眼做对照，不用在好几个系统里翻来翻去。
适合哪些场景
1. 出事时做变更对照
把故障发生时刻前后拉出来，看 K8s、Jenkins、自建变更通道等有没有条形或色块落在同一个时段。若对上，先考虑回滚、止血，再慢慢查根因。
2. 多路告警一起看
同一时间窗里，灭火图告警、北极星告警、传统监控告警等并排出现，更容易判断是「一条线连锁」还是「互不相关」。
3. 事后复盘、日常盘点
按业务、集群、命名空间等你关心的维度，回顾某段时间内改过什么、报过什么，给发布规范、容量和风险治理当依据。
相关概念
工作空间
事件墙的视图保存在您当前选中的工作空间之中：在哪个空间里创建与保存，便在哪个空间里查看和调整。若在多个团队协作使用 Flashcat，排障时请确认顶部或入口处的工作空间与目标环境一致，否则可能找不到视图，或误以为事件没有接入。
事件源
所谓事件源，指的是在 Flashcat 数据集成里为「事件／告警类」或「事件／变更类」配好的数据通道（例如某条告警接入、某集群的变更订阅等）。这类接入本身不挂在某个工作空间名下；运维上通常由平台统一维护。您在不同工作空间里分别新建事件墙视图时，都可以按需选用同一个已存在的事件源——各空间保存的是自己的视图与展示方式，而不是把数据源「复制」一份到空间里。
视图
指一页已保存的配置：要展示哪些类型的事件、默认打开时看多长时间、用时间条并排（甘特风格）还是表格等。固定几页常用视图，可减少每次现配的工作量。
每一条「时间条带」（展示项）
一页中可以有多行时间条，例如一行看 Kubernetes 变更、一行看灭火图告警、一行看夜莺告警。配置每一行时需要选择：是按某一类事件汇总多个接入，还是只看某一个指定接入（范围更窄）；以及按何种维度分行（如命名空间、业务线、告警规则名等——以当前界面中实际可选项为准）。
时间线上的合并粒度
线条过密时难以阅读，一般可在配置中把相近时间上的多条记录合并成块（粒度可按分钟级、十分钟级、小时级等调整，以阅读是否清晰为准）。太细则满屏碎条，太粗则可能看不出先后次序。
和北极星、灭火图怎么配合
常见顺序是：北极星或告警发现业务异常 → 灭火图缩到具体模块或实例 → 打开事件墙对齐时间，看异常抬升前后相关的模块或实例有没有变更、告警浪是否一致。
灭火图里可以配置下钻路径到事件墙，这条路径是故障定位分析的关键路径之一。
事件墙与智能化能力的关系
事件墙的价值，首先在于把时间线上可查、可追溯的事实摆在一起：什么时间发生了哪类变更、哪些告警在什么时段集中出现。这些内容本身并不等同于「根因结论」，但却是讨论与推断时最稳妥的出发点。
在实践中，常与智能化能力配合的方式包括：
与灭火图智能诊断等能力对照
当对异常卡片进行智能分析时，将同一时间段的事件墙数据一并取出，核查该时段的关键事件和相关性，将非常有利于判别异常的直接或关联诱因。
平台内置的 FlashAI
FlashAI 可帮助理解视图配置项的含义，或在新建视图时给出「通常建议并排展示的几类事件」等参考。也可以直接对某个时间段内的事件进行进一步的分析和统计，输出报表或报告。
平台上一般能接到哪些事件（举例）
- 变更侧：Kubernetes 资源变更、Jenkins 流水线、Jira 工单、企业自定义上报的变更等。
- 告警侧：灭火图卡片告警、北极星指标告警、夜莺 / Flashcat 告警、部分云监控告警等。
产品架构示意图
