2025-09-14 21:52:36 +00:00
|
|
|
|
# 福建项目：用户要求将一个数据中心的功能端日志写入割裂的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*:
|
|
|
|
|
|
|
|
|
|
|
|
收到
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-14 22:26:17 +00:00
|
|
|
|
# Attachments
|
|
|
|
|
|
|
|
|
|
|
|
Attachment: image-2022-05-27-10-00-09-955.png
|
|
|
|
|
|
|
2025-09-14 21:52:36 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
