为面临日志管理难题的运维和开发人员提供使用日志服务SLS进行日志治理的最佳实践和核心步骤：规范日志格式、优化存储空间、使用日志服务构建运维平台。
概述
背景介绍
日志是排查IT故障最有效的手段之一，所以很多企业会建立日志管理平台，将日志统一存储，以备不时之需。但是随着日志越接越多，日志内容变的越来越乱，日志平台的成本会变得很高，系统稳定性越来越差，排查问题的效率越来越低。
笔者是日志服务解决方案架构师，在和客户沟通过程中，大部分客户都会遇到这种问题。很多客户困扰与日志管理成本过高，日志格式混乱，不知道如何优化。他们很想了解下阿里是怎么做的，有没有最佳实践可以参考？所以就有了写一篇日志治理最佳实践的念头。
目标读者
希望可以为IT运维和开发团队负责日志管理的同学，提供日志治理的常用方法。
适用场景
本文介绍的最佳实践适合如下场景：
自建日志管理系统遇到稳定性或者性能问题。
接入的日志类型太多，日志格式难以统一。
日志存储和管理成本太高，想要优化成本。
为什么要治理日志？
日志平台成本高
大部分客户想要治理日志最大的原因就是日志平台成本太高了。最近遇到的一个客户有自建ELK平台，每天新增日志有10T，包括自建的ELK、Kafka、flink在内，每月在日志管理上的费用超过30万。在今年的经济形势下，IT降本的压力变得非常大，运维负责人首先就想到这个日志平台，是否有什么方法可以帮助其降低日志平台的成本？光ELK平台，就占了其运维运算的5%，而且就出问题的时候查下日志，平时也没怎么使用，感觉甚是鸡肋。
日志系统稳定性差
日志平台如果日志存量较大的话，很容易出现平台稳定性问题。比如之前遇到的客户，有接近400T的总日志量，ELK系统稳定性一直是困扰其运维人员的难题，几乎天天有服务器宕机。查询日志受系统性能影响，只能查询两个小时的数据，查询一个关键词，通常需要十几秒的时间，用户体验较差，也影响问题排查效率。
日志格式不统一
很多公司都有几十甚至上百套业务系统，日志输出格式也都是五花八门，大部分开发为了输出日志方便，会将业务日志都放到一个字段中，规范些的会用JSON或者分隔符，不规范的就会随意输出日志。这对日志的管理和使用造成了很大的困难。最大的问题就是这种不统一的日志格式只能创建全文索引进行关键词查询，全文索引会产生日志空间膨胀，导致存储和索引的成本成倍提高。
日志潜力无法挖掘
很多运维负责人面对存在日志系统里的全量日志，总感觉如果只在出问题的时候用来搜索故障日志，有点大材小用了。这些日志一定是可以挖掘出更多的用法，在运维场景中，是否可以结合指标和trace实现业务系统的全面可观测？是否可以提前发现问题？是否可以快速定位问题？是否可以和业务有更紧密的结合，通过现有数据帮助业务创新？提高运维的价值和地位？这些都是运维负责人想要做的，但是如果没有对日志内容，用法进行深度治理，上述这些需求将很难得到落实。
日志治理的常用方法
面对日志管理中遇到的这些问题，主要有如下几大治理手段：规范日志输出方式，优化存储空间以及升级日志管理系统。
规范日志输出方式
日志格式
混乱的日志输出格式会造成日志阅读困难，很难被使用。但是什么样的日志格式是比较理想的呢？通常根据日志的作用和来源，有不同的格式要求，但是都需要遵循如下几个原则：
可追溯：记录必要的信息，例如时间戳、发起方、请求id、处理ip、处理结果、错误ID等。
可分析：字段表达清晰，不需要过多的清洗即可分析结果。
可建模：每个字段有明确含义，避免歧义。
可诊断：包含明确错误信息与上下文。
这里有个推荐的日志格式样例（也是阿里飞天日志格式）：
[time] \t [level]\t[ThreadId]\t[$file_name:$line_no]\t{required_key_1}:{xxxx}\t{required_key_2}:{xxxx}\t{index_msg}:{xxxx}\t{no_index_msg}:{xxxx}\t{user_key_1}:{xxxx}\t{user_key_2}:{xxxx}
各字段的解释如下：
字段名称 |
字段描述 |
time |
时间戳 |
level |
日志级别，INFO/WARNING/ERROR/FATAL（debug一般不建议作为常规输出类型） |
ThreadId |
线程号 |
$file_name |
$line_no 文件和行号（可选） |
required_key_1 |
平台部分定义，应用必须填写的字段 |
Index_msg |
默认开启全文索引的字段，业务需要索引的信息，填写到这个字段中 |
No_index_msg |
不需要索引的信息填写到这个字段 |
user_key_1 |
业务自定义字段，是否需要索引，由业务自己确定 |
如上这类日志格式有以下几个特点：
字段之间使用分隔符区分，在解析字段时，使用分隔符的效率相对较高，建议使用3个或以下的字符作为分隔符，这里使用了“\t”作为分隔符。
将需要建索引的字段和不需要建索引的字段分开，比如这里的index_msg和 no_index_msg这两个字段，里面可以用JSON将日志内容按字段输出。这样做的好处就是可以很方便的提取需要建索引的字段。
为业务自定义字段预留了扩展空间，业务变化很快，你无法预先制定业务日志内容到底是什么，所以需要额外预留出几个字段用于应对业务的变化。
日志文件
在程序输出日志的时候，有些开发人员会选择将所有日志都打印到一个文件中，有些会打印到无数个小文件中，这些都不是理想的日志文件输出方式。通常比较好的方案是根据日志类型进行输出，将不同需求的日志输出到不同的日志文件中，通过对不同类型的文件采用不同的日志格式，可以方便的接入日志管理系统中。
通常对于一个应用系统，至少应该有3类日志文件：
程序逻辑相关的日志，例如：app.log
用户请求和访问相关的日志，例如：access.log
错误日志，例如 error.log
而且日志文件不宜过大，过大的日志文件对于日志监控，问题定位都会带来不变。因此需要进行日志文件的切分，日志文件通常会按天、小时来进行分割，具体分割原则还是应该根据日志大小和需求进行。
为了防止日志文件将整个磁盘空间占满，需要定期归档并清理日志文件。并且一个文件夹下不建议存放过多数量的日志文件，一旦发现文件数量过多，例如超过5千，需要将历史日志归档或清理。
优化存储空间
随着接入日志平台的日志越来越多，尤其是当日志存储时间大于1个月时，日志存储空间就会变得很大，这会造成系统稳定性下降，也会增加成本。所以对于一个日志管理平台来说，优化存储空间是非常重要的环节。通常会使用冷热分层的存储策略，也就是将一个月内需要频繁使用的日志使用热存储，保证性能，将一个月以上偶尔使用的日志使用冷存储，节约成本。
升级日志管理方案
对于使用MongoDB、ELK等开源日志平台的企业，在日志量较大的时候，普遍会遇到性能和稳定性问题，所以还是需要一个既能满足可靠性和性能要求，有能满足低成本要求的日志管理解决方案。对于阿里云上的用户来说，最佳方案就是使用日志服务SLS来统一存储和管理日志，并且可以将指标和trace数据也接入SLS中，全面提高运维人员对整个业务系统的可观测性。
方案架构
下图是使用日志服务构建出来的运维系统架构图，日志服务SLS可以将log、metric、trace三大类可观测性数据全部接入一个平台中，结合高性能数据查询引擎和关联分析能力，构建基础的云原生可观测数据平台。再结合智能告警与响应中枢和基于AI的数据分析与异常巡检模块，帮助企业构建出一套智能运维系统。
方案优势
基于SLS的智能运维平台有如下几大优势：
统一接入：可观测数据统一接入和存储，为数据协同关联分析提供原生支持能力。
一站式：支持采集、加工、分析、可视化、告警等智能运维系统所必备的能力，免除搭建和运维各种组件的烦恼。
智能高效：具备秒级分析百亿级数据能力；支持完整AIOps能力、支持智能异常检测与根因分析。
弹性低成本：具备PB/day规模的弹性伸缩能力；全托管免运维的公有云服务，无需预留资源，真正按量付费。
使用日志服务治理日志
下面就来介绍下，如何使用日志服务SLS来治理日志。
前提条件
已经将日志格式修改成易于识别的统一格式
已经注册阿里云账号并且开通日志服务
操作步骤
1. 规划Project和Logstore
很多客户使用SLS遇到的第一个问题，也是比较重要的问题，就是根据什么来创建project和logstore，是否有规律可循？这里给一些project和logstore的规划建议
Project规划建议
项目（Project）是日志服务中的资源管理单元，用于资源隔离和控制。您可以通过项目来管理某一个应用的所有日志及相关的日志源。它管理着用户的所有日志库（Logstore），采集日志的机器配置等信息，同时它也是用户访问日志服务资源的入口。
建议为不同部门或者不同业务单元分配不同的project，每个Project之间的日志是相互独立的，这样可以为不同的project分配不同的权限，确保不同部门之间的数据独立性。通常一个账号下的Project数量最好能控制在30个以内。
Project是建在不同region集群内的，可以很方便的采集相同region内ECS中的日志，需要跨region采集日志时需要进行额外的配置，所以尽量将project建在主要应用系统相同的region。
Logstore规划建议
日志库（Logstore）是日志服务中日志数据的采集、存储和查询单元。每个日志库隶属于一个项目，且每个项目可以创建多个日志库。您可以根据实际需求为某一个项目生成多个日志库，其中常见的做法是为一个应用中的每类日志创建一个独立的日志库。例如，用户有一个“big-game”游戏应用，服务器上有三种日志：操作日志（operation_log）、应用程序日志（application_log）以及访问日志（access_log），用户可以首先创建名为“big-game”的项目，然后在该项目下面为这三种日志创建三个日志库，分别用于它们的采集、存储和查询。一个logstore中的索引字段数建议不超过300个，否则会影响查询效率，索引有长度限制，超过限制会造成索引创建失败。
无论是写入或者查询日志，您都需要指定操作的 Logstore。如果您希望投递日志数据到MaxCompute 做离线分析，其数据投递也是以 Logstore 为单元进行数据同步，即一个 Logstore 内的日志数据投递到一张 MaxCompute 的 Table。
2. 创建Project和Logstore
登录日志服务控制台后，点击创建Project按钮。
输入名称，选择所属地域，建议把重要日志开启，以便于排查日志采集过程中遇到的问题。
创建完project后根据提示创建logstore。
3. 接入日志
在接入数据模块内，选择所接入日志对应的数据类型，这里选择“分隔符-文本日志”方式接入日志。
4. 创建机器组
采集日志需要安装日志服务的探针logtail，这里选择采集哪些服务器上的日志，并且安装logtail。在ECS上部署的话，可以勾选ECS批量部署logtail。
5. 设置logtail配置
设置需要采集的日志及所在路径，支持通配符模式匹配
使用分隔符模式采集日志，可以看到样例日志中的字段被自动提取出来了，可以在页面中给提取出来的字段命名
6. 设置索引字段用于查询分析
点击下一步就完成了日志采集的配置，如果此时有新日志产生，会自动将字段提取出来，可以直接创建索引。默认是勾选上全文索引选项的，这里可以选择取消，并且只添加需要参与分析的字段，以节约成本。
7. 开启智能冷热分层功能
当数据保存时间超过30天时，可以开启智能冷热分层功能，优化存储成本，在创建的logstore中通过点击“修改”按钮进入logstore设置页。
在logstore属性页面中，设置数据保存时间为180天，热存数据保存时间为30天，开启智能冷热分层存储功能后，31天-180天的数据会自动转移到SLS的冷存储中。但是使用方式并不会收到影响。
