first

md/OMPUB-497.md

@@ -0,0 +1,48 @@
+# 福建项目：用户要求将一个数据中心的功能端日志写入割裂的OLAP集群
+
+| ID | Creation Date | Assignee | Status |
+|----|----------------|----------|--------|
+| OMPUB-497 | 2022-05-27T09:47:02.000+0800 | 郑超 | 完成 |
+
+
+---
+
+* 目前福建两套TSG集群（福州长乐TSG、泉州移动TSG）均已更新完毕，版本TSG - 22.01
+
+* 由于有2个CM，需要用户维护2套策略，但是用户觉得这样不方便，用户执意想用1个CM下策略，日志由不同城市的功能端发给其对应的OLAP，再回到对应的CM
+
+*问题：可否支持用户这样的使用方式？*
+
+备注：
+1、由于福州-泉州之间的互联网络为千兆带宽，所以不满足组件一个TSG集群的条件，最终采用了2套独立的TSG集群的方案（目前泉州的功能端 8-9万/s 原始日志 发送给福州的kafka，已经占用带宽90%）
+
+2、使用1个CM+2个OLAP的方式 未来会产生的问题 已经提醒用户，但是用户并不是很在意（他认为策略、日志关联上的问题并不是很重要），策略日志还是可以从2个界面上看到，用户也不用Report功能
+
+3、作为福建项目的项目经理，在原则上，我没有同意他这样做，但是我也确实没有找到更合适、更直接的理由拒绝他
+
+逻辑图如下：
+ !image-2022-05-27-10-00-09-955.png|thumbnail! 
+**zhengchao** commented on *2022-05-27T17:28:41.623+0800*:
+
+按上图魔改吧。提醒用户无法解决日志查询和统计异常
+
+
+
+---
+
+**zhangzhihan** commented on *2022-05-27T17:40:49.383+0800*:
+
+收到
+
+
+
+---
+
+
+
+## Attachments
+
+**28294/image-2022-05-27-10-00-09-955.png**
+
+---
+