weiyhcarlos/trainning

trainning's Issues

pythonic

以下是看到的一些

1. if "ttl" in varDict.keys()

2. while(True)

3. def set_handler(self, params_dict): 参数表可以写成(self, config, method)，调用时set_handler(**params_dict)，保持接口可读性

4. try catch中不要包含不必要的逻辑，例如：

           try:
               data[module]["time"] = data["time"]
               data[module]["machine_id"] = data["mac"]
               self.database[module].insert_one(data[module])
           except PyMongoError:
               self.store_local(module, data[module])
               error_info += ("upload " + module + " info fail.\n")

代码规范

注意以下问题：

1. 单行代码79字符，包括注释
2. 使用常用且易理解的缩写 args_par.py,
3. 变量命名尽量有意义 args_par.py line18 dic
4. 使用log而非print
5. 尽量避免使用保留字和buildin函数名作为变量名
6. 仍有不少配置hardcode在代码里
7. 使用统一命名规范： global_vars， varDict

文档和部署

未考虑agent如何部署，也未说明依赖？以后系统应考虑快速部署方式，必要时需要提供部署文档。

sync_time

code/syn_time.py

1. subprocess滥用，python有自己的ntp库，不需要依赖ntpdate。

2. 尽量不要上传二进制文件，尤其是在code目录。

3. 直接装自带的deb包并使用ntpdate校准系统时间，可能引发一系列问题，例如：

   ＊ 兼容性
   ＊ 被监控机有自己需要同步的ntp服务器，并且业务服务强依赖该ntp，监控agent应该尽量避免修改任何系统环境

WEBUI设计

• 限制一小时查询时间太没人性了，绝大多数问题跟踪都不止需要看一小时
  • 可以通过存储不同粒度的数据实现
  • 数据量不大也可以直接从原始数据聚合出粗时间粒度的数据
• 时间选择控件操作还是略复杂，保留的同时，考虑其他方便使用的优化
  • 可以考虑 “最近一小时” 之类的select
  • 可以考虑 时间快捷前进后退 的功能
• 做到时间选择和页面数据统一，避免误解
• 对比图表没标题的
• 切换指标没必要再点“查询” “对比”之类的吧

代码问题

1. 尽量少用module globals级别的变量
2. 类似services.js line 25 附近的hardcode代码有点多，考虑下更优雅的方式
3. detail_part的几个template没有必要，只用一个template即可实现
4. template内硬编码也略多，其实很多options、links之类，可以在js内维护数据结构，tpl内循环生成
5. machines_resources.py 73行开始的if else也是，想想怎么抽象更好
6. 有余力的情况下，完善单元测试吧，pytest即可

设计问题

1. 数据写入
   目前是agent直接连接mongos写数据，stage1没有问题，后续要继续考虑如何实现
2. 数据上传
   是否有必要从tcp这么底层开始实现？
3. 数据采集
   • 进制转化不应该在采集时做，不通用且小数值有丢失精度风险
   • 考虑下现在采集cpu监控数据的逻辑是否正确？

api设计问题

GET /monitor/api/machines
GET /monitor/api/machines/:id
只应该是同一类资源取集合或取特定一个资源的区别，实现时变成了取基本信息集合和取一台机器的基本信息加监控数据，接口的二义性会增加理解成本，不符合规范，请注意