[汇总] 降低问题排查成本, 降低整体复杂度

[wklken]

现状

调用:

• SaaS调用 API
• ESB/APIGateway调用 API
• API 数据同步模块
  • 调用LDAP
  • 调用 MAD
  • 调用 HTTP API
• API 的auth模块(auth失败的场景)
• SaaS 的登录校验模块(登录无限跳转的场景)
• API 本身的校验报错信息

重点模块:

• bkuser_core/enhanced_account
• bkuser_core/esb_sdk
• bkuser_core/categories/plugins

TODO: 收集其他用户返回的错误堆栈信息

日志

已经处理了:

• SaaS 调用后台没有详细的报错信息 + 打印双份日志问题 feat(api/logging): enhance the logging while api 500 #357 fix(logging/exception): remove redundant logging while handle the exceptions #290
• 自定义exception缺失详情 fix(exception): blueException missing message detail while logging or print #286
• 通用日志打印优化, 详情+打印方式 Ft logger prints #284
• 自定义登录打印详细日志 Ft bklogin log #309
• [日志] auth fail的日志没有区分度 #403 fix(api/enhanced_account): token auth fail with different exception message #408
• [优化] esb_sdk优化/日志优化 #406 refactor(api/esb_sdk): remove useless codes of esb #409
• 日志中存在敏感信息(后台不可用的时候会打印到日志文件中) fix(login): logger remove sensitive info from data #415
• [logging] 数据源数据同步流程打印更详细的日志 #296 fix(api/celery): change CELERY_RESULT_BACKEND to django-db, instead of MQ or Redis #419
• 初始化数据报错没有上下文, 难以定位 fix(api/category): plugin init_settings add more detail in log info #422

还需要确定的点:

• debug日志是否对问题排查有帮助?
• info日志是否包含足够多的过程信息?
• error日志是否都有上下文(重点排查log.exception)
• 是否足够方便检索(目前全部放stdout)
• 切换成文件, 是否足够细(需要确认是否支持v3的日志约定)
• [logging] esb/apigateway调用的request_id记录到链路日志中 #360
• [logging] 定时/异步任务的日志优化 #407
• [部署] 上云版日志切换成文件 #374
• [容器化] 日志切换标准输出到文件 #358

防御性处理

• HTTP API 数据源校验 [优化] HTTP API 数据源同步报错 #390 fix(plugin/custom): fix http api as datasource wrong response check #400

celery定时/异步

• [bug] dev-api定时同步任务同步失败会导致mq queue 暴涨 #402 fix(api/celery): change CELERY_RESULT_BACKEND to django-db, instead of MQ or Redis #419
• [bug] HTTP 数据源同步失败, 一直展示重试中 #404 fix(api/sync_data): custom sync from crontab use the same task_id #411

metrics

?

文档

• LDAP/MAD数据同步问题 FAQ汇总
• HTTP 数据源插件文档同步修改

其他

• HTTP API数据同步部门记录了extra.code, 而profile没有记录(排查问题有困难) fix(api/sync): custom profile sync add original code into extras #420
• 支持sentry Ft add sentry #306
• user_settings目前允许插入重复的配置 [api] user_settings唯一性约束 #423 fix(api/user_settings): add unique_together for user_settings_setting(category_id+meta_id) #425

[wklken]

修修补补加日志, 并没有真正解决问题, 降低问题排查的成本, 但是没有降低复杂度

---

本质上, 应该分析几个点, 从根本上减少概念/封装, 降低复杂度

• saas通过sdk调用后台接口
• 后台接口提供了过于通用的查询能力, 导致viewset层过于复杂(重点: category/profile)
• 目录同步 plugins 机制(概念过多, 嵌套层级过深, 重点: 简化逻辑/减少封装)

[wklken]

需要有: 明确的规划和方向

[wklken]

• SaaS 逻辑已抹除, 重构到API的 api/v1/web
• SDK已抹除
• 解耦了 Open API 和 SaaS API