日志

1. 目标
   • 支持故障定界
   • 辅助故障分析
   • 性能问题分析
2. 度量
   • WHO+WHEN+WHAT: 谁什么时候发生了什么问题
   • WHY+HOW: 为什么会发生？ 怎么发生的？
   • HOW: 如何恢复故障？如何修复问题？
3. 功能
   • 日志生成，系统可以产生高质量的、刚刚好的日志，支持3个目标
   • 日志处理，围绕日志进行地快速地、准确地分析，支持故障的恢复和问题的修复；

日志全景图

待补充

日志生成 —— 现有问题

总体来说，现有日志满足度量项1，却无法满足度量项2＋3

• 日志不规范，缺少有效的指导书
  1. ERROR/FATAL/PANIC报错没有错误码，或者给定错误码不正确；
  2. 错误描述信息不足，无法支撑定界和深入地分析；
  3. DEBUG级别的日志没有明确规范，哪些类型的日志应该使用DEBUG1，哪些类型的日志应该使用DEBUG2 等等；
• 多个组件的日志风格不统一，无法规一化处理
  1. GTM、DN／DN、OM／CM以及导入服务，使用的是不同的日志生成方法；
  2. 以上四的日志风格不同，有的根本缺少基本的日志规范和要求
  3. 日志存储路径的不确定性，导入服务的日志是使用时指定的，搜集日志不方便；
• 日志单点化
  1. 只有出错的地方有日志
  2. 缺少描述完整问题的上下文日志
• 日志生成的手段不足
  1. 运行时出错无法搜集运行轨迹上的数据； 如果问题不出现前就打印大量日志，做法又不妥
  2. 缺少对内存（二进制）数据搜集的有效手段； 使用现有日志生成方法会便利日志量膨胀得很厉害 为什么会造就以上的问题呢？
• 数据库系统的复杂性
  1. 根因的产生源与运行时错误的时间差越长，问题越复杂
  2. 各模块间的相互影响
  3. 分布式，跨网络，跨节点，管理的复杂度
• 开发者的局限性
  1. 思维的局限性
  2. 知识的局限性