使用日志服务SLS进行日志治理最佳实践

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 为面临日志管理难题的运维和开发人员提供使用日志服务SLS进行日志治理的最佳实践和核心步骤:规范日志格式、优化存储空间、使用日志服务构建运维平台。

为面临日志管理难题的运维和开发人员提供使用日志服务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的数据分析与异常巡检模块,帮助企业构建出一套智能运维系统。

image.png

方案优势

基于SLS的智能运维平台有如下几大优势:

  • 统一接入:可观测数据统一接入和存储,为数据协同关联分析提供原生支持能力。

  • 一站式:支持采集、加工、分析、可视化、告警等智能运维系统所必备的能力,免除搭建和运维各种组件的烦恼。

  • 智能高效:具备秒级分析百亿级数据能力;支持完整AIOps能力、支持智能异常检测与根因分析。

  • 弹性低成本:具备PB/day规模的弹性伸缩能力;全托管免运维的公有云服务,无需预留资源,真正按量付费。

使用日志服务治理日志

下面就来介绍下,如何使用日志服务SLS来治理日志。

前提条件

  1. 已经将日志格式修改成易于识别的统一格式

  2. 已经注册阿里云账号并且开通日志服务

操作步骤

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按钮。

image.png

输入名称,选择所属地域,建议把重要日志开启,以便于排查日志采集过程中遇到的问题。

image.png

创建完project后根据提示创建logstore。

image.png

3. 接入日志

在接入数据模块内,选择所接入日志对应的数据类型,这里选择“分隔符-文本日志”方式接入日志。

image.png

4. 创建机器组

采集日志需要安装日志服务的探针logtail,这里选择采集哪些服务器上的日志,并且安装logtail。在ECS上部署的话,可以勾选ECS批量部署logtail。

image.png

5. 设置logtail配置

设置需要采集的日志及所在路径,支持通配符模式匹配

image.png

使用分隔符模式采集日志,可以看到样例日志中的字段被自动提取出来了,可以在页面中给提取出来的字段命名

image.png

6. 设置索引字段用于查询分析

点击下一步就完成了日志采集的配置,如果此时有新日志产生,会自动将字段提取出来,可以直接创建索引。默认是勾选上全文索引选项的,这里可以选择取消,并且只添加需要参与分析的字段,以节约成本。

image.png

7. 开启智能冷热分层功能

当数据保存时间超过30天时,可以开启智能冷热分层功能,优化存储成本,在创建的logstore中通过点击“修改”按钮进入logstore设置页。

image.png

在logstore属性页面中,设置数据保存时间为180天,热存数据保存时间为30天,开启智能冷热分层存储功能后,31天-180天的数据会自动转移到SLS的冷存储中。但是使用方式并不会收到影响。

image.png
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
2月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
673 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
3月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
397 3
|
13天前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
MySQL事务日志-Undo Log工作原理分析
|
1月前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。
|
3月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1773 14
MySQL事务日志-Redo Log工作原理分析
|
3月前
|
XML JSON 监控
告别简陋:Java日志系统的最佳实践
【10月更文挑战第19天】 在Java开发中,`System.out.println()` 是最基本的输出方法,但它在实际项目中往往被认为是不专业和不足够的。本文将探讨为什么在现代Java应用中应该避免使用 `System.out.println()`,并介绍几种更先进的日志解决方案。
89 1
|
2月前
|
存储 监控 安全
什么是日志管理,如何进行日志管理?
日志管理是对IT系统生成的日志数据进行收集、存储、分析和处理的实践,对维护系统健康、确保安全及获取运营智能至关重要。本文介绍了日志管理的基本概念、常见挑战、工具的主要功能及选择解决方案的方法,强调了定义管理目标、日志收集与分析、警报和报告、持续改进等关键步骤,以及如何应对数据量大、安全问题、警报疲劳等挑战,最终实现日志数据的有效管理和利用。
207 0
|
4月前
|
设计模式 SQL 安全
PHP中的设计模式:单例模式的深入探索与实践在PHP的编程实践中,设计模式是解决常见软件设计问题的最佳实践。单例模式作为设计模式中的一种,确保一个类只有一个实例,并提供全局访问点,广泛应用于配置管理、日志记录和测试框架等场景。本文将深入探讨单例模式的原理、实现方式及其在PHP中的应用,帮助开发者更好地理解和运用这一设计模式。
在PHP开发中,单例模式通过确保类仅有一个实例并提供一个全局访问点,有效管理和访问共享资源。本文详细介绍了单例模式的概念、PHP实现方式及应用场景,并通过具体代码示例展示如何在PHP中实现单例模式以及如何在实际项目中正确使用它来优化代码结构和性能。
62 2
|
3月前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
51 0