我们的系统，已经接入阿里云的日志服务很长一段时间了，存了数以TB级别的日志，突然有一天，领导说，我们需要所有订单的ip信息用于审计订单的真实性，突然发现日志系统无法一次性查找到我所有需要的信息，让我很无奈，是我们没有记录吗？那我们遇到了哪些问题呢。
日志级别规范
日志级别我们已经有了较好的规范了
只在必要时打印日志
- 面对不确定因素时(Warning/Info)
- 订单、支付、物流等核心业务场景(Info)
- 程序运行错误(Error)
日志内容及格式：
日志格式：
我们选择使用json格式来处理日常的日志，比较方便简洁，格式自由，另外就是使用t制表符分割，然后使用key:value格式来处理，也比较好分隔。
多行日志我们是明确禁止的，必须打成一行，并且非json，我们不予采集，因为多行和非标准的格式给我们带来了大量的麻烦，日志采集规则实在是难以覆盖
日志内容：
对于日志内容，其实这是最难做的，也是我非常想要表达的，包括我现在遇到的很多问题，也是由于内容不够结构化导致的。日志就像我们使用mongodb那样，除了唯一主键，其他的schema可以任意增加删除，这样其实给了程序员太多自由空间，必须在某些地方强制要求才可以。
所以我们在这方面做出几个改进：
- 使用DB里面的列名，作为日志的key，这样避免出现同义key，但是接手的人太多，每个人都有自己的命名习惯，导致最终日志无法查询
- 对于订单相关日志，要求同时出现订单号和用户id，以便查询
- 当出错时，应该打印出错所涉及的订单号和用户id，如果涉及到支付，应该打印支付渠道和支付网关的返回的订单号以便审计查询
- 在json的值里面不要嵌套其他类似json的内容，例如出现msg: 订单成功{info:success}这样的字符，难以解析，难以排查，并且在最终查询时只能解析部分字符串，对于后面的类json内容无法良好的处理
日志系统的边界
了解日志系统能力的边界很重要，我们目前使用阿里云日志系统，功能很强大，但是也有一些限制：
- 索引仅对新内容有效果：可以支持三个月内索引重建，耗费大量时间金钱
- 日志系统可能存在不完整日志情况，不能过分依赖，对于类似审计这样的需求应该使用DB
- 同上，日志可以输出良好的报表，但是对于系统消耗也比较大，对于一些订单详情，流量，可以选择接入bi系统来处理，并使用bi的OLAP库
- 同时在何时时机对研发进行日志系统培训，让他们用好日志系统
日志存储周期
现在很多上了kubernetes和docker，像我们是没有kubernetes，但是用的docker，本地日志不再长期保存，并且现在的主机数量以及日志数量也是难以支持研发上机查询，所以我们本地只保存不到1G的日志，其他日志由阿里云直接采集走在日志服务上汇集。
阿里云日志是支持无限期存储的，目前我们有部分比较重要的日志选择了永久保存，并定期存储到阿里云oss。
对原有日志的改造
既然一些问题已经浮出浮出水面，那么我们需要安排研发进行修改，在研发人手不是那么充裕的条件下，我们选择循序渐进，即：日志问题始终提高警惕，新的日志按照新的研发规范进行，旧的日志，随时发现随时提，随时改，随着时间推移得到一个良性的日志系统。
本文强烈推荐使用阿里云日志服务
上云必备www.aliyun.com
