南通网站建设策划书,室内软装设计软件,上海知名公司,天津建设网网站打不开我们的系统#xff0c;已经接入阿里云的日志服务很长一段时间了#xff0c;存了数以TB级别的日志#xff0c;突然有一天#xff0c;领导说#xff0c;我们需要所有订单的ip信息用于审计订单的真实性#xff0c;突然发现日志系统无法一次性查找到我所有需要的信息#xf…我们的系统已经接入阿里云的日志服务很长一段时间了存了数以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日志服务_实时日志分析系统_日志管理软件_网站日志分析工具 - 阿里云cn.aliyun.com
