update image in introduction

Author: UlricQin

content/en/docs/prologue/introduction.md

@@ -27,15 +27,17 @@ Any issues or PRs are welcome!
 
 Many users have already collected metrics and log data themselves. In this case, they can integrate their storage repositories (like VictoriaMetrics, Elasticsearch, etc.) as data sources in Nightingale. Users can then configure alert rules and notification rules in Nightingale to generate and dispatch alert events.
 
-<img src="/img/prologue/intro/product-arch.png" alt="Nightingale Product Architecture" />
+<img src="/img/global/arch-bg.png" alt="Nightingale Product Architecture" class="homepage-banner-light">
+<img src="/img/global/arch-bg-dark.png" alt="Nightingale Product Architecture" class="homepage-banner-dark">
 
 Nightingale itself does not provide data collection capabilities. We recommend using [Categraf](https://github.com/flashcatcloud/categraf) as a collector, which can seamlessly integrate with Nightingale.
 
 [Categraf](https://github.com/flashcatcloud/categraf) can collect monitoring data from operating systems, network devices, middleware, and databases. It pushes this data to Nightingale (via Prometheus Remote Write protocol), which then forwards the data to time-series databases (like Prometheus, VictoriaMetrics, etc.) and provides alerting and visualization capabilities.
 
 For specific edge data centers, where the network link to the central Nightingale server is poor, Nightingale also provides a design for edge data center alerting engine deployment. In this mode, even if the edge and central networks are disconnected, alerting functionality remains unaffected.
 
-<img src="/img/prologue/intro/edge-arch.png" alt="Nightingale Edge Architecture" />
+<img src="/img/prologue/intro/edge-light.png" alt="Nightingale Edge Architecture" class="homepage-banner-light">
+<img src="/img/prologue/intro/edge-dark.png" alt="Nightingale Edge Architecture" class="homepage-banner-dark">
 
 > In the above diagram, the network link between data center A and the central data center is good, so the alerting engine is handled by the central Nightingale process. For data center B, where the network link to the central data center is poor, we deploy `n9e-edge` as the alerting engine to handle data source alerting functionality locally.
 

content/zh/docs/prologue/introduction.md

@@ -27,15 +27,17 @@ toc: true
 
 当用户已具备指标和日志数据采集能力时，可将现有存储系统（如 VictoriaMetrics、ElasticSearch 等）作为数据源接入夜莺，在夜莺中配置告警规则和通知规则，实现告警事件的生成和分发。**这种模式下，夜莺不采集数据、不存储数据，仅作为告警引擎**。
 
-<img src="/img/prologue/intro/product-arch.png" alt="夜莺产品架构图"/>
+<img src="/img/global/arch-bg.png" alt="夜莺产品架构图" class="homepage-banner-light">
+<img src="/img/global/arch-bg-dark.png" alt="夜莺产品架构图" class="homepage-banner-dark">
 
 如果您尚未采集监控数据，也可以使用 [Categraf](https://github.com/flashcatcloud/categraf) 作为采集器，Categraf 可以与夜莺丝滑对接。
 
 Categraf 支持采集操作系统、网络设备、各类中间件和数据库的监控数据，通过 Remote Write 协议将数据推送至夜莺。这种模式下，夜莺仍然不存储监控数据，而是充当数据转发网关，将监控数据做一些处理然后转存至时序数据库（如 Prometheus、VictoriaMetrics 等）。
 
 对于网络链路不稳定的边缘机房场景，为提升告警可用性，夜莺提供边缘机房告警引擎下沉部署模式。在此模式下，即使边缘机房与中心机房网络中断，告警功能仍可正常运行（具体可参考架构设计章节）。
 
-<img src="/img/prologue/intro/edge-arch.png" alt="夜莺边缘架构"/>
+<img src="/img/prologue/intro/edge-light.png" alt="夜莺边缘架构" class="homepage-banner-light">
+<img src="/img/prologue/intro/edge-dark.png" alt="夜莺边缘架构" class="homepage-banner-dark">
 
 上图中，机房 A 与中心机房网络链路稳定，因此直接由中心端的夜莺进程执行告警引擎功能；机房 B 与中心机房网络链路不稳定，因此在机房 B 部署 `n9e-edge` 作为告警引擎，对机房 B 的数据源进行告警判定。