日志

前言履约治理是一个面向物流商家的OMS工作台，自从初代目把架子搭起来之后，就没有持续投入了，起初始终是合作伙伴同学在负责日常保护和需要撑持。通过几年的横蛮成长，零碎曾经杂草丛生，乱象百出。再起初，甚至一度成为一块无主之地，走行业共建的形式来反对。对于一个不反对行业隔离的零碎，行业共建象征这个零碎将疾速腐化。两年前我开始接管履约治理，来到这片广大的蛮荒之地，正如所有那些渴望造物乐趣并且手里刚好有锤子镰刀的人，我就像一匹脱缰的野马，脑子里常常会产生很多大胆且离奇的想法，心愿借此把履约治理打造成一个完满的零碎。只惋惜真正可能付诸实践的少之又少，本篇就是为数不多得以落地，并且有相当实用价值idea中的一个，整理出来分享给有须要的同学做参考。 日志乱象日志是日常开发中最有可能被忽视，最容易被滥用的一个模块。被忽视是因为打日志切实是一个再简略不过的事，前人设计好了一个logback.xml，前面只须要如法炮制定义一个logger，顺手一个info调用就搞定，他甚至不确定这条日志能不能打进去，也不晓得会打在哪个文件，反正先跑一次试试，不行就换error。被滥用是因为不同场景日志的格局内容千差万别，或者说日志打法太灵便，太随便了，格调太多样化了，以至于简直每个人一言不合就要本人写一个LogUtil，我见过最夸大的，一个零碎中用于打日志的工具类，有二三十个之多，前人纠结该用哪个工具可能就要做半个小时的思想斗争，完满诠释了什么叫破窗效应。最好的学习形式就是通过反面教材吸取教训，上面咱们列举一些最常见的日志设计开发过程中的问题。 分类之乱一般来说，一个零碎必然须要设计多个日志文件以辨别不同业务或场景，不可能所有的日志都打到一个文件里。然而怎么进行分类，没人通知咱们，于是就有了各种各样的分类。按零碎模块分。这种分类应该是最根底的一种分类，也是最有层次感的分类。比方履约服务中枢的零碎分层。基本上每一层对应一个日志文件。 按租户身份分。个别中台零碎都会反对多个租户(行业)，每一个租户独自对应一个日志文件。这种分类个别不会独自应用，除非你要做齐全意义上的租户隔离。意识流分类法。不合乎MECE法令，没有清晰对立的分类逻辑，按业务分，按零碎模块分，按接口能力分，按新老链路分，各种分法的影子都能看到，后果就是分进去几十个文件，打日志的人基本就不晓得这一行的日志会打进哪个文件。以上说的各种分类形式，都不是相对纯正的，因为无论哪一种，无论一开始设计的如许边界清晰，随着工夫的推动，最初都会演变为一个大杂烩。 某人心愿独自监控某个类产生的日志，新增日志文件；新增了一个业务，比方一盘货，想独自监控，新增日志文件；发动了一场服务化战斗，针对服务化链路独自监控，新增日志文件；某个业务想采集用户行为，又不想全接日志音讯，新增日志文件；资损敞口的场景，须要特地关注，新增日志文件；非凡期间内产生的日志，比方大促，新增日志文件；凡此种种，不一而足。发现没有，总有那么一瞬间能让人产生新增日志文件的神经激动，他们的诉求和场景也不堪称不合理，只管这些日志的维度齐全不相干，然而没有什么能阻止这种激动。最开始的那一套日志设计，就像一个濒临死亡的大象，一直地被不同的利益方从身上扯下一块分去。 格局之乱对于日志须要有肯定的格局这点置信没有人会有异议，格局的乱象次要体现在两个方面，一个是格局的设计上，有些零碎设计了非常复杂的格局，用多种分隔符组合，反对日志内容的分组，用关键词定位的形式代替固定地位的格局，同时反对格局扩大，这对人脑和计算机去解析都是一种累赘。第二个是同一个日志文件，还能呈现不同格局的内容，堆栈和失常业务日志混淆。来看一个例子，我不给任何提醒，你能在大脑里很快剖析出这个日志的构造吗？ requestParam$&trace@2150435916867358634668899ebccf&scene@test&logTime@2023-06-14 17:44:23&+skuPromiseInfo$&itemId@1234567:1&skuId@8888:1&buyerId@777:1&itemTags@,123:1,2049:1,249:1,&sellerId@6294:1&toCode@371621:1&toTownCode@371621003:1&skuBizCode@TMALL_TAOBAO:1&skuSubBizCode@TMALL_DEFAULT:1&fromCode@DZ_001:1+orderCommonInfo$&orderId@4a04c79734652f6bd7a8876379399777&orderBizCode@TMALL_TAOBAO&orderSubBizCode@TMALL_DEFAULT&toCode@371621&toTownCode@371621003&+工具之乱有时候甚至会呈现，同一个类，同一个办法中，两行不同的日志埋点，打进去的日志格局不一样，落的日志文件也不一样。为什么会呈现这种状况？就是因为用了不同的日志工具。要究其根源，咱们须要剖析一下不同的工具到底是在做什么。能够发现，很多工具之间的差异就是反对的参数类型不一样，有些是打印订单对象的，有些是打印消息的，有些是打印调度日志的。还有一些差异是面向不同业务场景的，比方一盘货专用工具，负卖专用工具。还有一些差别是面向不同的异样封装的，有些是打印ExceptionA，有些是打印ExceptionB的。世间离奇事，莫过于此，或者只能用存在即正当去解释了。 日志分层我始终崇奉极简的设计准则，简略意味着颠扑不破。下面提到，一套日志零碎最终的终局肯定是走向凌乱，既然这种趋势无奈防止，那么咱们在最后设计的时候就只能确保一件事，保障原始的分类尽量简略，且不重叠。其实通用的分类形式无非就两种，一种按职能程度拆分，一种按业务垂直拆分。一般来说，一级分类，应该采纳程度拆分。因为业务的边界个别是很难划清的，边界绝对含糊，职能的边界就绝对清晰稳固很多，职能其实反映的是工作流，工作流一经造成，根本不会产生太大的结构性变动。基于这种思路，我设计了如下的日志分层。 从档次上来看，其实只有三层，入口，内核，进口。入口日志只负责打印流量入口的出入参，比方HSF，controller。进口日志负责打印所有第三方服务调用的出入参。内核日志，负责打印所有两头执行过程中的业务日志。就三层足矣，足够简略，不重不漏。另外把堆栈日志独自拎进去，堆栈相比业务日志有很大的特殊性，本文题目所指出的日志存储升高优化，也只是针对堆栈日志做的优化，这个前面再讲。 格局设计日志的格局设计也有一些考究。首先日志的设计是面向人可读的，这个无需多言。另外也十分重要的一个点，要面向可监控的设计，这是容易被很多人漠视的一个点。基于这两个准则，说一下我在格局设计上的一些思路。首先要做维度形象。既然是面向监控，监控个别须要反对多个保护，比方行业维度，服务维度，商家维度等等，那么咱们就须要把所有的维度因子抽出来。那么这些维度理论打印的时候怎么传给logger呢？倡议是把他们存到ThreadLocal中，打的时候从上下文中取。这样做还有一个益处是，日志打印工具设计的时候就会很优雅，只须要传很少的参数。格局尽量简略，采纳约定大于配置的准则，每一个维度占据一个固定的地位，用逗号宰割。切忌设计一个大而全的模型，而后间接整个的序列化为一个JSON字符串。也不要被所谓的扩展性给引诱，给应用方轻易开出一个可能自定义格局的口子，即使你能轻而易举的提供这种能力。依据我的教训，这种扩展性肯定会被滥用，到最初连设计者也不晓得理论的格局到底是怎么的。当然这个须要设计者有较高的视线和远见，不过这不是难点，难的还是克服本人炫技的欲望。在内容上，尽量打印能够自解释的文本，做到见名知义。举个例子，咱们要打印退款标，退款标本来是用1, 2, 4, 8这种二进制位存储的，打印的时候不要间接打印存储值，翻译成一个能形容它含意的英文code。格局示例 timeStamp|threadName logLevel loggerName|sourceAppName,flowId,traceId,sceneCode,identityCode,loginUserId,scpCode,rpcId,isYace,ip||businessCode,isSuccess||parameters||returnResult||内容示例2023-08-14 14:37:12.919|http-nio-7001-exec-10 INFO c.a.u.m.s.a.LogAspect|default,c04e4b7ccc2a421995308b3b33503dda,0bb6d59616183822328322237e84cc,queryOrderStatus,XIAODIAN,5000000000014,123456,0.1.1.8,null,255.255.255.255||queryOrderStatus,success||{"@type":"com.alibaba.common.model.queryorder.req.QueryOrderListReq","currentUserDTO":{"bizGroup":888,"shopIdList":[123456],"supplierIdList":[1234,100000000001,100000000002,100000000004]},"extendFields":{"@type":"java.util.HashMap"},"invokeInfoDTO":{"appName":"uop-portal","operatorId":"1110","operatorName":"account_ANXRKY8NfqFjXvQ"},"orderQueryDTO":{"extendFields":{"@type":"java.util.HashMap"},"logisTypeList":[0,1],"pageSize":20,"pageStart":1},"routeRuleParam":{"@type":"java.util.HashMap","bizGroup":199000},"rule":{"$ref":"$.routeRuleParam"}}||{"@type":"com.alibaba.common.model.ResultDTO","idempotent":false,"needRetry":false,"result":{"@type":"com.alibaba.common.model.queryorderstatus.QueryOrderStatusResp","extendFields":{"@type":"java.util.HashMap"}},"success":true}||堆栈倒打本文的重点来啦，这个设计就是结尾提到的奇思妙想。堆栈倒打源于我在排查另一个零碎问题过程中感触到的几个痛点，首先来看一个堆栈示例。 这么长的堆栈，这稀稀拉拉的字母，即便是天天跟它打交道的开发，置信第一眼看上去也会头皮发麻。回忆一下咱们看堆栈，真正想得到的是什么信息。所以我感触到的痛点外围有两个。第一个是，SLS(阿里云日志产品零碎)上搜进去的日志，默认是折叠的。对于堆栈，咱们应该都晓得，传统异样堆栈的特色是，最顶层的异样，是最靠近流量入口的异样，这种异样咱们个别状况下不太关怀。最底层的异样，才是引起系列谬误的源头，咱们日常排查问题的时候，往往最关怀的是谬误源头。所以对于堆栈日志，咱们无奈通过摘要一眼看出问题出在哪行代码，必须点开，拉到最上面，看最初一个堆栈能力确定源头。我写了一个谬误示例来阐明这个问题。惯例的堆栈构造其实分两局部，我称之为，异样起因栈，和谬误堆栈。 如上，一个堆栈蕴含有三组异样，每一个RuntimeException是一个异样，这三个异样连起来，咱们称为一个异样起因栈。每一个RuntimeException外部的堆栈，咱们称为谬误堆栈。阐明一下，这两个名词是我杜撰的，没有看到有人对二者做辨别，咱们个别都统称为堆栈。读者能了解我想表白的就行，不必太纠结名词。第二个痛点是，这种堆栈存储老本太高，无效信息承载率很低。诚实说这一点可能大多数一线开发并没有太强烈的体感，但在这个降本增效的大环境下，咱们每个人应该把这点作为本人的OKR去践行，变被动为被动，否则在机器老本和人力老本之间，公司只好做选择题了。当初指标很明确了，那咱们就开始隔靴搔痒。外围思路有两个。针对堆栈折叠的问题，采纳堆栈倒打。倒打之后，最底层的异样放在了最下面，甚至不必点开，瞟一眼就能晓得起因。 同时咱们也反对异样起因栈层数配置化，以及谬误堆栈的层数配置化。解这个问题，实质上就是这样一个简略的算法题：倒序打印堆栈的最初N个元素。外围代码如下。 /** * 递归逆向打印堆栈及cause(即从最底层的异样开始往上打) * @param t 原始异样 * @param causeDepth 须要递归打印的cause的最大深度 * @param counter 以后打印的cause的深度计数器(这里必须用援用类型，如果用根本数据类型，你对计数器的批改只能对以后栈帧可见，然而这个计数器，又必须在所有栈帧中可见，所以只能用援用类型) * @param stackDepth 每一个异样栈的打印深度 * @param sb 字符串结构器 */public static void recursiveReversePrintStackCause(Throwable t, int causeDepth, ForwardCounter counter, int stackDepth, StringBuilder sb){ if(t == null){ return; } if (t.getCause() != null){ recursiveReversePrintStackCause(t.getCause(), causeDepth, counter, stackDepth, sb); } if(counter.i++ < causeDepth){ doPrintStack(t, stackDepth, sb); }}要升高存储老本，同时也要确保信息不失真，咱们思考对堆栈行下手，把全限定类名简化为类名全打，包门路只打第一个字母，行号保留。如：c.a.u.m.s.LogAspect#log:88。外围代码如下。 ...

业务背景有时候日志的信息比拟多，怎么样才能够让零碎做到自适应采样呢？ 拓展浏览日志开源组件（一）java 注解联合 spring aop 实现主动输入日志 日志开源组件（二）java 注解联合 spring aop 实现日志traceId惟一标识 日志开源组件（三）java 注解联合 spring aop 主动输入日志新增拦截器与过滤器 日志开源组件（四）如何动静批改 spring aop 切面信息？让主动日志输入框架更好用 日志开源组件（五）如何将 dubbo filter 拦截器原理使用到日志拦截器中？ 自适应采样是什么？系统生成的日志能够蕴含大量信息，包含谬误、正告、性能指标等，但在理论利用中，解决和剖析所有的日志数据可能会对系统性能和资源产生累赘。 自适应采样在这种状况下发挥作用，它可能依据以后零碎状态和日志信息的重要性，智能地决定哪些日志须要被采样记录，从而无效地治理和剖析日志数据。 采样的必要性日志采样系统会给业务零碎额定减少耗费，很多零碎在接入的时候会比拟排挤。 给他们一个百分比的抉择，或者是一个不错的开始，而后依据理论须要抉择适合的比例。 自适应采样是一个对用户通明，同时又十分优雅的计划。 如何通过 java 实现自适应采样?接口定义首先咱们定义一个接口，返回 boolean。 依据是否为 true 来决定是否输入日志。 /** * 采样条件 * @author binbin.hou * @since 0.5.0 */public interface IAutoLogSampleCondition { /** * 条件 * * @param context 上下文 * @return 后果 * @since 0.5.0 */ boolean sampleCondition(IAutoLogContext context);}百分比概率采样咱们先实现一个简略的概率采样。 0-100 的值，让用户指定，依照百分比决定是否采样。 ...

前言金融用户敏感数据如何优雅地实现脱敏？ 日志脱敏之后，无奈依据信息疾速定位怎么办？ 通过了这两篇文章之后，咱们对日志脱敏应该有了肯定的了解。 然而理论我的项目中，咱们遇到的状况往往更加简单： 1）我的项目的 java bean 定义不标准，大量接口应用 map。 2）历史我的项目泛滥，革新老本微小。 种种原因，导致应用注解的形式消耗大量的工夫。然而个别给咱们革新的工夫是无限的。 那么，有没有一种办法能够对立对敏感信息进行脱敏解决呢？ 答案是有的，咱们能够基于 log4j2 实现本人的脱敏策略，对立实现日志的脱敏。 log4j2 Rewrite咱们能够基于 log4j2 RewritePolicy 对立应用脱敏策略。 本我的项目自 V1.2.0 增加对应反对，后续将晋升对应的可拓展性。 阐明：如果应用 slf4j 接口，实现为 log4j2 时也是反对的。 应用入门maven 引入引入外围脱敏包。 <dependency> <groupId>com.github.houbb</groupId> <artifactId>sensitive-log4j2</artifactId> <version>1.2.1</version></dependency>其余的个别我的项目中也有，如 log4j2 包： <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>${log4j2.version}</version></dependency><dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>${log4j2.version}</version></dependency>log4j2.xml 配置例子如下: <?xml version="1.0" encoding="UTF-8"?><Configuration status="WARN" packages = "com.github.houbb.sensitive.log4j2.rewrite"> <Appenders> <Console name="Console" target="SYSTEM_OUT"> </Console> <Rewrite name="rewrite"> <AppenderRef ref="Console"/> <SensitiveRewritePolicy/> </Rewrite> </Appenders> <Loggers> <Root level="DEBUG"> <AppenderRef ref="rewrite" /> </Root> </Loggers></Configuration>几个步骤： 指定 package 为 packages = "com.github.houbb.sensitive.log4j2.rewrite"依照 log4j2 Rewrite 标准，指定重写策略为 SensitiveRewritePolicy输入时，间接指定为对应的重写之后的后果 <AppenderRef ref="rewrite" />测试失常的日志打印： ...

日志脱敏之殇小明同学在一家金融公司下班，为了满足安全监管要求，最近天天忙着做日志脱敏。 无意间看到了一篇文章金融用户敏感数据如何优雅地实现脱敏？ 感觉写的不错，用起来也很不便。 不过日志脱敏之后，新的问题就诞生了：日志脱敏之后，很多问题无奈定位。 比方身份证号日志中看到的是 3****************8，业务方给一个身份证号也没法查日志。这可怎么办？ 平安与数据唯一性相似于数据库中敏感信息的存储，个别都会有一个哈希值，用来定位数据信息，同时保障平安。 那么日志中是否也能够应用相似的形式呢？ 说干就干，小明在开源我的项目 sensitive 根底上，增加了对应的哈希实现。 应用入门开源地址https://github.com/houbb/sensitive应用形式1）maven 引入 <dependency> <groupId>com.github.houbb</groupId> <artifactId>sensitive-core</artifactId> <version>1.1.0</version></dependency>2）疏导类指定 SensitiveBs.newInstance().hash(Hashes.md5())将哈希策略指定为 md5 3）功能测试 final SensitiveBs sensitiveBs = SensitiveBs.newInstance() .hash(Hashes.md5());User sensitiveUser = sensitiveBs.desCopy(user);String sensitiveJson = sensitiveBs.desJson(user);Assert.assertEquals(sensitiveStr, sensitiveUser.toString());Assert.assertEquals(originalStr, user.toString());Assert.assertEquals(expectJson, sensitiveJson);能够把如下的对象 User{username='脱敏君', idCard='123456190001011234', password='1234567', email='12345@qq.com', phone='18888888888'}间接脱敏为： User{username='脱**|00871641C1724BB717DD01E7E5F7D98A', idCard='123456**********34|1421E4C0F5BF57D3CC557CFC3D667C4E', password='null', email='12******.com|6EAA6A25C8D832B63429C1BEF149109C', phone='1888****888|5425DE6EC14A0722EC09A6C2E72AAE18'}这样就能够通过明文，获取对应的哈希值，而后搜寻日志了。 新的问题不过小明还是感觉不是很称心，因为有很多零碎是曾经存在的。 如果全副用注解的形式实现，就会很麻烦，也很难推动。 应该怎么实现呢？ 小伙伴们有什么好的思路？欢送评论区留言

2022年人均挪动设施应用时长近5小时，其中社交类利用占据了约70%。随着市场需求与用户规模的持续增长，社交泛娱乐产业成为新蓝海，越来越多的翻新场景利用应运而生：社交+直播，社交+Avatar，社交+游戏...通过模式丰盛的社交类利用，人们所取得的不再仅限于娱乐消遣，还有逾越时空的连贯、归属感与满足感。 随着国内市场的日趋成熟与饱和，为了能取得更大的市场，局部娱乐行业公司抉择了出海这条路，其业务也由区域化逐步向全球化转变。 因而，本来以“跟着产品走”的方针，须要转变为“就地取材”的策略。针对不同地区的市场，须要鉴参考当地用户特点，在内容和推广素材上做出差异化。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1178520?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

2022年6月底，阿里云iLogtail代码残缺开源，正式公布了残缺性能的iLogtail社区版。iLogtail作为阿里云SLS官网标配的采集器，多年以来始终稳固服务阿里团体、蚂蚁团体以及泛滥私有云上的企业客户，目前曾经有千万级的装置量，每天采集数十PB的可观测数据，广泛应用于线上监控、问题剖析/定位、经营剖析、平安剖析等多种场景。此次残缺开源，iLogtail社区版首次在内核能力上与企业版齐全对齐，开发者能够构建出与企业版性能相当的iLogtail云原生可观测性数据采集器。 iLogtail的外围定位是可观测数据的采集器，帮忙开发者构建对立的数据采集层，助力可观测平台打造各种下层的利用场景。iLogtail一贯秉承凋谢共建的准则，欢送任何模式的社区探讨交换及公建。 可观测性探讨生存中的可观测 可观测性指的是从零碎的内部输入推断及掂量零碎外部状态。在咱们生存当中也会遇到很多可观测的例子。汽车仪表盘就是一个很典型的可观测例子，在驾驶汽车过程中，特地须要高度重视就是行驶平安问题。而汽车仪表盘升高了辨认汽车外部状态的门槛，即便非汽车工程业余人员也能通过仪表盘疾速辨认汽车的外部状态。 另外，咱们平时的看病能够认为是人体可观测的例子。在现代，医疗程度比较落后，整体来说人体是一个黑盒，只能通过外表的望闻问切来诊断病因，然而这种形式适度的依赖医生的教训、不足无力的数据撑持。而到了近代，随着心电图、X光等医疗设施的倒退，人体的外部机制变得越来越通明，大幅晋升了医疗程度，给人们的身体健康带来了福音。通过上述的例子咱们能够看到，可观测性不仅要能定性地反馈系统外部状态，最重要的是要定量的论证零碎外部状态，须要有足够的数据根据，也就是咱们提到的可观测数据的品质和准确性。 时机与挑战 回到咱们软件行业，通过几十年的飞速发展，整个开发模式、零碎架构、部署模式、基础设施等也都通过了几次颠覆性的改革，这些改革带来了更快的开发和部署效率，但随之而来整个的零碎也更加的简单、开发所依赖人和部门也更多、部署模式和运行环境也更加动静和不确定，这也对可观测数据采集提出了更高的要求。首先须要适应开发模式疾速迭代的需要，须要可能与DevOps流程等进行高度的集成，通过轻量级、自动化集成的形式实现开发、测试、运维的一体化；也须要适应部署架构分布式、容器化的需要，晋升业务服务动静、及时、精确发现的能力；最初，云原生的倒退也带来了更多的上下游依赖，因而也须要适应数据起源、数据类型越来越多的需要。 可观测性的数据根底 Logs、Traces、Metrics作为可观测性数据的三大支柱，根本能够满足各类监控、告警、剖析、问题排查等需要。这里大抵剖析下这三类数据的特点、转化形式以及实用场景： Logs：作为软件运行状态的载体，通过日志能够具体解释零碎运行状态及还原业务解决的过程。常见日志类型包含运行日志、拜访日志、交易日志、内核日志、满日志、谬误日志等。Metrics：是指对系统中某一类信息的统计聚合，绝对比拟离散。个别有name、labels、time、values组成，Metrics数据量个别很小，绝对老本更低，查问的速度比拟快。Traces：是最规范的调用日志，除了定义了调用的父子关系外（个别通过TraceID、SpanID、ParentSpanID），个别还会定义操作的服务、办法、属性、状态、耗时等详细信息。三者间的转换关系：Logs在调用链场景结构化后其实能够转变为Trace，在进行聚合、降采样操作后会变成Metrics。 开源计划探讨 目前行业上支流的可观测开源计划，大略能够分为5个局部。 采集端：承载可观测数据采集及一部分前置的数据处理性能。随着云原生的倒退，采集端也须要适应时代潮流，提供对K8s采集的敌对反对。常见的采集端有Filebeat、FluentD/Fluent-bIt，以及咱们开源的iLogtail。音讯队列：采集Agent往往不会间接将采集到的数据发送到存储系统，而是写入音讯队列，起到削峰填谷的作用，防止流量洪峰导致存储系统宕机。常见音讯队列为Kafka、RabbitMQ等。计算：用于生产音讯队列中的数据，通过解决、聚合后输入到存储系统。比拟常见的为Flink、Logstash等。存储剖析引擎：提供采集数据长久化存储能力，并提供查问剖析能力。常见的存储剖析引擎为Elasticsearch、ClickHouse及Loki。可视化：借助Kibana和Grafana提供采集数据的可视化能力。另外，日志服务SLS作为一款云原生观测与剖析平台，为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。SLS一站式提供数据采集、加工、查问与剖析、可视化、告警、生产与投递等性能，用户能够基于SLS疾速构建一套残缺的可观测平台。iLogtail企业版作为SLS官网标配的采集器，承载了业务数据采集的职责，而iLogtail社区版正是从企业版倒退而来的，性能及性能天然也继承了企业版的绝大部分能力。 iLogtail倒退历程 iLogtail的前身源自阿里云的神农我的项目，自从2013年正式孵化以来，iLogtail始终在一直演进。 诞生初期，面对阿里云本身和晚期客户运维和可观测性需求，iLogtail次要解决的是从单机、小规模集群到大规模的运维监控挑战，此时的iLogtail曾经具备了根本的文件发现和轮转解决能力，能够实现日志、监控实时采集，抓取毫秒级提早，单核解决能力约为10M/s。通过Web前端可反对中心化配置文件主动下发，反对3W+部署规模，上千采集配置项，实现日10TB数据的高效采集。 2015年，阿里巴巴开始推动团体和蚂蚁金服业务上云，面对近千个团队、数百万终端、以及双11、双12等超大流量数据采集的挑战，iLogtail在性能、性能、稳定性和多租户反对方面都须要进行微小的改良。至2017年前后，iLogtail曾经具备了正则、分隔符、JSON等多个格局日志的解析能力，反对多种日志编码方式，反对数据过滤、脱敏等高级解决能力，单核解决能力极简模式下晋升到100M/s，正则、分隔符、JSON等形式20M/s+。采集可靠性方面，减少文件发现Polling形式兜底、轮转队列程序保障、日志清理失落爱护、CheckPoint加强；过程可靠性方面，减少异样主动复原、Crash主动上报、守护过程等。通过全流程多租户隔离、多级高下水位队列、配置级/过程级流量管制、长期降级等机制，反对百万+部署规模，千级别租户，10万+采集配置项，实现日PB级数据的稳固采集。 随着阿里推动外围业务全面上云，以及iLogtail所属日志服务（SLS）正式在阿里云上商业化，iLogtail开始全面拥抱云原生。面对多元的云上环境、迅速倒退的开源生态和大量涌入的行业客户需要，iLogtail的倒退的重心转移到解决如何适应云原生、如何兼容开源协定和如何去解决碎片化需要等问题上。2018年iLogtail正式反对docker容器采集，2019年反对containerd容器采集，2020年全面降级Metric采集， 2021年减少Trace反对。通过全面反对容器化、K8S Operator管控和可扩大插件零碎，iLogtail反对千万部署规模，数万内外部客户，百万+采集配置项，实现日数十PB数据的稳固采集。2021年11月iLogtail迈出了开源的第一步，将Golang插件代码开源。自开源以来，吸引了数百名开发者的关注，并且也有不少开发者奉献了processor跟flusher插件。2022年6月C++外围代码也正式开源了，自此开发者能够基于该版本构建残缺的云原生可观测数据采集计划。 iLogtail外围劣势 外围劣势 -- 轻量、高效、稳固、牢靠轻量可观测数据采集Agent作为一个基础设施，往往须要每台机器都有部署，比方目前阿里外部有数百万的装机量，每天会产生几十PB的可观测数据。因而不论是内存还是CPU的一点点节俭，都能带来比拟大的老本收益。特地是，K8s Sidecar模式对于内存的要求更加刻薄，因为iLogtail与业务容器独特部署，iLogtail部署量会随业务规模扩充而增长。 从设计初期，咱们就比拟器重iLogtail的资源占用问题，抉择了主体局部C++、插件局部Golang实现，并且通过一些技术细节（详见下文）的优化，使得内存还是CPU绝对于同类Agent都有较大的劣势。 高效采集对于日志采集，比拟常见的伎俩是轮询机制，这是一种被动探测的收集形式，通过定期检测日志文件有无更新来触发日志采集；相应的也存在一种被动监听的事件模式，依赖于操作系统的事件告诉（对操作系统有肯定的要求），常见的事件告诉机制是Linux 2.6.13内核版本引入的inotify机制。轮询绝对事件告诉的实现复杂度要低很多、人造反对跨平台而且对于零碎限制性不高；但轮询的采集提早以及资源耗费较高，而且在文件规模较大时轮询一次的工夫较长，比拟容易产生采集提早。 为了同时兼顾采集效率以及跨平台的反对，iLogtail采纳了轮询（polling）与事件（inotify）并存的模式进行日志采集，既借助了inotify的低提早与低性能耗费的特点，也通过轮询的形式兼顾了运行环境的全面性。 iLogtail外部以事件的形式触发日志读取行为。其中，polling和inotify作为两个独立模块，别离将各自产生的Create/Modify/Delete事件，存入Polling Event Queue和Inotify Event Queue中。轮询模块由DirFilePolling和ModifyPolling两个线程组成，DirFilePolling负责依据用户配置定期遍历文件夹，将合乎日志采集配置的文件退出到modify cache中；ModifyPolling负责定期扫描modify cache中文件状态，比照上一次状态（Dev、Inode、Modify Time、Size），若发现更新则生成modify event。inotify属于事件监听形式，依据用户配置监听对应的目录以及子目录，当监听目录存在变动，内核会产生相应的告诉事件。由Event Handler线程负责将两个事件队列合并到外部的Event Queue中，并解决相应的Create/Modify/Delete事件，进而进行理论的日志采集。此外，咱们也通过一些技术手段，保障了polling、inotify两种机制的高效配合，整体近一步晋升了iLogtail运行效率。 事件合并：为防止轮询事件和inotify事件屡次触发事件处理行为，iLogtail在事件处理之前将反复的轮询/inotify事件进行合并，缩小有效的事件处理行为；轮询主动降级：如果在零碎反对且资源足够的场景下，inotify无论从提早和性能耗费都要优于轮询，因而当某个目录inotify能够失常工作时，则该目录的轮询进行主动降级，轮询距离大幅升高到对CPU根本无影响的水平。日志程序采集日志程序性采集是日志采集须要提供的基本功能，也是一个采集的难点，须要思考如下场景： 适应不同的日志轮转(rotate)机制：日志轮转是指当日志满足肯定条件（工夫或文件大小）时，须要进行重命名、压缩等操作，之后创立新的日志文件持续写入。另外，不同应用日志库轮转文件的格局不尽相同，有的工夫结尾，有的数字结尾等。适应不同的采集门路配置形式：优良的日志采集agent并不应该强制限度用户的配置形式，尤其在指定日志采集文件名时，须要适应不同用户的配置习惯。不论是精准门路匹配，还是含糊匹配，例如.log或.log*，都不能呈现日志轮转时多收集或者少收集的状况。为了实现日志文件的程序采集，首先须要定义好文件的惟一标识。咱们晓得在文件系统中，能够通过dev+inode的组合惟一标识一个文件。文件的move操作尽管能够扭转文件名，但并不波及文件的删除创立，dev+inode并不会变动，因而通过dev+inode能够十分不便的判断一个文件是否产生了轮转。然而dev+inode只能保障同一时刻文件的唯一性，当波及文件疾速删除创立的时候，前后两个文件的dev+inode很可能是雷同的。因而纯正通过dev+inode判断轮转并不可行，iLogtail引入了文件签名（signature）的概念，应用日志文件的前1024字节的hash作为文件的signature，只有当dev+inode+signature统一的状况下才会认为该文件是轮转的文件。此外，iLogtail外部也引入了文件轮转队列，保障了文件的程序采集。 采集可靠性iLogtail作为一个可观测数据根底采集组件，除了资源、性能外，可靠性也是一项要害指标。对于一些异样场景，iLogtail也有充沛的设计思考，保障了在网络异样、流量突增、过程重启等场景下仍然可能实现失常的采集工作。 日志解决阻塞问题形容：iLogtail须要大量部署在不同的业务机器上，运行环境是复杂多变的，利用日志burst写入、网络暂时性阻塞、服务端Quota有余、CPU/磁盘负载较低等状况在劫难逃，当这些状况产生时，很容易造成日志采集进度落后于日志产生进度，此时，iLogtail须要在正当的资源限度下尽可能保留住这些日志，期待网络复原或零碎负载下降时将这些日志采集到服务器，并且保障日志采集程序不会因为采集阻塞而凌乱。 解决思路： iLogtail外部通过放弃轮转日志file descriptor的关上状态来避免日志采集阻塞时未采集实现的日志文件被file system回收（在文件轮转队列中的file descriptor始终放弃关上状态，保障文件援用计数至多为1）。同时，通过文件轮转队列的程序读取保障日志采集程序与日志产生程序统一。若日志采集进度长时间继续落后于日志产生进度，齐全的不回收机制，则很有可能呈现文件轮转队列会有限增长的状况，进而导致磁盘被写爆，因而iLogtail外部对于文件轮转队列设置了下限，当size超过下限时禁止后续Reader的创立，只有这种继续的极其状况呈现时，才会呈现丢日志采集的状况。当然，在问题被放大之前，iLogtail也会通过报警的形式，告诉用户及时染指修复问题。 采集配置更新/过程降级问题形容：配置更新或进行降级时须要中断采集并从新初始化采集上下文，iLogtail须要保障在配置更新/过程降级时，即便日志产生轮转也不会失落日志。 解决思路： 为保障配置更新/降级过程中日志数据不失落，在iLogtail在配置从新加载前或过程被动退出前，会将以后所有采集的状态保留到本地的checkpoint文件中；当新配置利用/过程启动后，会加载上一次保留的checkpoint，并通过checkpoint复原之前的采集状态。然而在老版本checkpoint保留结束到新版本采集Reader创立实现的时间段内，很有可能呈现日志轮转的状况，因而新版本在加载checkpoint时，会查看对应checkpoint的文件名、dev+inode有无变动。若文件名与dev+inode未变且signature未变，则间接依据该checkpoint创立Reader即可。若文件名与dev+inode变动则从当前目录查找对应的dev+inode，若查找到则比照signature是否变动。若signature未变则认为是文件轮转，依据新文件名创立Reader；若signature变动则认为是该文件被删除后从新创立，疏忽该checkpoint。过程crash、宕机等异常情况问题形容：在过程crash或宕机时，iLogtail须要提供容错机制，不丢数据，尽可能的少反复采集。解决思路：过程crash或宕机没有退出前记录checkpoint的机会，因而iLogtail还会定期将采集进度dump到本地：除了恢复正常日志文件状态外，还会查找轮转后的日志，尽可能升高日志失落危险。外围劣势 -- 性能及隔离性 无锁化设计及工夫片调度业界支流的Agent对于每个配置会调配独立的线程/go runtime来进行数据读取，而iLogtail数据的读取只配置了一个线程，次要起因是： 数据读取的瓶颈并不在于计算而是磁盘，单线程足以实现所有配置的事件处理以及数据读取。单线程的另一个劣势是能够使事件处理和数据读取在无锁环境下运行，绝对多线程解决性价比较高。iLogtail数据读取线程可实现每秒200MB以上的数据读取（SSD速率能够更高）。但单线程的状况下会存在多个配置间资源分配不均的问题，如果应用简略的FCFS（ First Come First Serve）形式，一旦一个写入速度极高的文件占据了处理单元，它就始终运行上来，直到该文件被解决实现并被动开释资源，此形式很有可能造成其余采集的文件被饿死。因而咱们采纳了基于工夫片的采集调度计划，使各个配置间尽可能偏心的调度，避免采集文件饿死的景象产生。iLogtail将Polling以及Inotify事件合并到无锁的事件队列中，每个文件的批改事件会触发日志读取。每次读取从上次记录的偏移地位开始，并尝试在固定的工夫片内将文读取到EOF处。如果工夫片内读取结束，则示意事件处理实现，删除事件；否则，将事件从新Push到队列尾部，期待下一次调用。 通过以上设计，保障了iLogtail能够高性能的进行数据采集。比照数据能够详见：https://developer.aliyun.com/article/850614 多租户隔离基于工夫片的采集调度保障了各个配置的日志在数据读取时失去偏心的调度，满足了多租户隔离中根本的公平性，但对于隔离性并未起到帮忙作用。例如当局部采集配置因解决简单或网络异样等起因阻塞时，阻塞配置仍然会进行解决，最终会导致队列达到下限而阻塞数据读取线程，影响其余失常配置。为此咱们设计了一套多级高下水位反馈队列用以在不同采集配置间实现读取、解析、发送各个步骤的无效的协调，为了更好的实现不同配置间隔离性，所以iLogtail会为每个配置创立一组队列。 多级：iLogtail从采集到输入总体要通过读取->解析->发送三个步骤，iLogtail在相邻步骤间别离设置一个队列。高下水位： 每个队列设置高下两个水位，高水位时进行非紧急数据写入，只有复原到低水位时才容许再次写入。反馈： 在筹备读取以后队列数据时会同步查看下一级队列状态，下一级队列高水位则跳过读取；以后队列从高水位生产到低水位时，异步告诉关联的前一级队列。极其场景解决对于一些阻塞场景的可靠性也须要思考，次要包含事件处理、数据读取逻辑以及数据发送管制三个方面： 事件处理与数据读取无关，即便读取关联的队列满也照常解决，这里的解决次要是更新文件meta、将轮转文件放入轮转队列，可保障在配置阻塞的状况下，即便文件轮转也不会失落数据。当配置关联的解析队列满时，如果将事件从新放回队列尾，则会造成较多的有效调度，使CPU空转。因而iLogtail在遇到解析队列满时，将该事件放到一个专门的blocked队列中，当解析队列异步反馈时从新将blocked队列中的数据放回事件队列。Sender中每个配置的队列关联一个SenderInfo，SenderInfo中记录该配置以后网络是否失常、Quota是否失常以及最大容许的发送速率。每次Sender会依据SenderInfo中的状从队列中取数据，这里包含：网络失败重试、Quota超限重试、状态更新、流控等逻辑。外围劣势 -- 插件化扩大能力 ...

图解 Fluent Bit 外部设计本文摘录自我的开源书：《Mark’s DevOps 雜碎》中的 图解 Fluent Bit 外部设计。如果你看到图片不清晰，请转回原文。前言最近，因为工作须要，用老程序员在 羊之前最快的速度，通过文档、源码，学习了 Fluent Bit 的一些外围实现设计。正所谓，学得快，忘得更快。固作本笔记，以备未来学不动。 本文指标本文并<mark>不是要介绍 Fluent Bit</mark>。也<mark>不是学习如何应用它</mark>(当然，学习实现自身就是为更好地应用它的性能，同时更好地躲避它的问题。即：<mark>让 3PP的应用预期可控</mark>)。本文次要是初步简略钻研 Fluent Bit 外部实现后的总结与笔记。次要是从繁冗的文档与代码中，找到一点全局观、根底概念，以让学习的人不至于迷路其中细节。 本文是包含学习到的局部设计。 Fluent Bit 虽自称 lightweight，其实实现并不简略。 因为学习工夫无限，应用教训也不多，所以内容不免有错。应用请审慎！ 对读者的假如假如读者曾经理解过 Fluent Bit。想看看其实现机理，以提前发现可能潜在的坑。 互动图片 本文的失常关上办法是，点击 “用 Draw.io 关上” 后，进入互动图片状态。图中很多元素提供链接到相干源码或文档。能够做穿插参考，是进一步深刻的入口，也是图可信性取证。本文的大部分内容是放在图中了。看图比文字更重要。什么是Fluent BitFluent Bit 官网 这样介绍本人： Fluent Bit 是一种超疾速、轻量级且高度可扩大的日志记录和指标处理器和转发器。它是云和容器化环境的首选。而在开源网站 Fluent Bit 是实用于 Linux、Windows、嵌入式 Linux、MacOS 和 BSD 系列操作系统的疾速日志处理器和转发器。它是 Graduated Fluentd 生态系统和 CNCF 子项目的一部分。 Fluent Bit 容许从不同起源收集日志事件或指标，对其进行解决并将它们传送到不同的后端，例如 Fluentd、Elasticsearch、Splunk、DataDog、Kafka、New Relic、Azure 服务、AWS 服务、Google 服务、NATS、InfluxDB 或任何自定义 HTTP 端点。概念上面只介绍本文用到的局部概念。 Record 概念能够简化认为，日志文件中的一行，就是一个 Record。外部以 json 树模式来记录一个 Record。 ...

你是否常常遇到线上须要日志排查问题但迟迟分割不上用户上报日志的状况？或者是否常常陷入因为存储空间有余而导致日志写不进去的囧境？本文介绍了美团是如何从0到1搭建高性能终端实时日志零碎，从此彻底解决日志失落和写满问题的。心愿能为大家带来一些帮忙和启发。1 背景1.1 Logan 简介Logan 是美团面向终端的对立日志服务，已反对挪动端App、Web、小程序、IoT等多端环境，具备日志采集、存储、上传、查问与剖析等能力，帮忙用户定位研发问题，晋升故障排查效率。同时，Logan 也是业内开源较早的大前端日志零碎，具备写入性能高、安全性高、日志防失落等长处。 1.2 Logan 工作流程为了不便读者更好地了解 Logan 零碎是如何工作的，下图是简化后的 Logan 零碎工作流程图。次要分为以下几个局部： 被动上报日志：终端设备在须要上报日志时，能够通过 HTTPS 接口被动上传日志到 Logan 接管服务，接管服务再把原始日志文件转存到对象存储平台。日志解密与解析：当研发人员想要查看被动上报的日志时会触发日志下载与解析流程，原始加密日志从对象存储平台下载胜利后进行解密、解析等操作，而后再投递到日志存储系统。日志查问与检索：日志平台反对对单设施所有日志进行日志类型、标签、过程、关键字、工夫等维度的筛选，同时也反对对一些特定类型的日志进行可视化展现。 1.3 为什么须要实时日志？如前文所述，这套“本地存储+被动上报”的模式尽管解决了大前端场景下根底的日志应用需要，然而随着业务复杂度的一直减少，用户对日志的要求也越来越高，以后 Logan 架构存在的问题也变得越来越突出，次要体现在以下几个方面： 局部场景上报日志受限：因为在 Web 与小程序上用户个别的应用场景是用完即走，当线上呈现问题时再分割用户被动上报日志，整个解决周期较长，有可能会错过最佳排查工夫。短少实时剖析和告警能力：以后短少实时剖析和告警的能力，用户曾多次提到过想要对线上异样日志进行监控，当有合乎规定的异样日志呈现时能收到告警信息。短少全链路追踪能力：以后多端的日志散落在各个系统中，研发人员在定位问题时须要手动去关联日志，操作起来很不不便，美团外部不足一个通用的全链路追踪计划。针对以上痛点问题，咱们提出了建设 Logan 实时日志，旨在提供对立的、高性能的实时日志服务，以解决美团现阶段不同业务零碎想要日志上云的需要。 1.4 Logan 实时日志是什么？Logan 实时日志是服务于挪动端 App、Web、小程序、IoT 等终端场景下的实时日志解决方案，旨在提供高扩展性、高性能、高可靠性的实时日志服务，包含日志采集、上传、加工、生产、投递、查问与剖析等能力。 2 设计实现2.1 整体架构 如上图所示，整体架构次要分为五个局部，它们别离是： 采集端：负责端上日志数据的采集、加密、压缩、聚合和上报等。接入层：负责提供日志上报接口，接管日志上报数据，并将数据转发到数据处理层。数据处理层：负责日志数据的解密、拆分、加工和荡涤等。数据消费层：负责日志数据的过滤、格式化、投递等。日志平台：负责日志数据查问与剖析、业务零碎接入配置、统计与告警等。2.2 采集端通用采集端架构，解决跨平台复用 采集端SDK用于端侧日志收集，须要在多种终端环境落地，然而因为端和平台较多、技术栈和运行环境也不统一，多端开发和保护老本会比拟高。因而，咱们设计了一套外围逻辑复用的通用采集端架构，具体的平台依赖代码则独自进行适配。咱们目前上线了微信、MMP、Web、MRN 端侧，逻辑层代码做到了齐全复用。采集端架构设计图如下： 重点模块介绍： 配置管理：采集端初始化实现后，首先启动配置管理模块，拉取和刷新配置信息，包含上报限流配置、指标采样率、性能开关等，反对对要害配置进行灰度公布。加密：所有记录的日志都应用 ECDH + AES 计划加密，确保日志信息不透露。Web 版加密模块应用浏览器原生加密 API 进行适配，可实现高性能异步加密，其余平台则应用纯 JS 实现。存储管理：线上数据表明，因为页面敞开导致的日志失落占比高达 1%，因而咱们设计了日志落盘性能，当日志上传失败后会先缓存在本地磁盘，等到页面下一次启动时再从新复原上传。队列治理：须要发送的日志首先进行分组聚合，如果期待分组过多则须要抛弃一部分申请，避免在弱网环境或者日志沉积太多时造成内存继续上涨而影响用户。落盘缓存 + 上报复原，避免日志失落 为了不便读者更好地了解端上日志采集过程，上面将具体介绍下采集端流程设计。当采集端初始化 API 开始调用时，先创立 Logger、Encryptor、Storage 等实例对象，并异步拉取环境配置文件。初始化实现之后，先查看是否有胜利落盘，然而上报失败的日志，如果有的话立刻开始复原上传流程。当失常调用写日志 API 时，原始日志被加密后退出以后上报组，等到有上报事件（工夫、条数、导航等）触发时，以后上报组内的所有日志被退出上报队列并开始上传。采集端具体流程图如下： 2.3 数据接入层对于实时日志零碎来讲，接入层须要满足以下几点要求：（1）反对公网上报域名；（2）反对高并发解决；（3）具备高实时性，提早是分钟级；（4）反对投递数据到 Kafka 音讯队列。 ...

引言上篇文章 性能调优——小小的 log 大大的坑 已将具体的介绍了高并发下，不正确的应用日志姿态，可能会导致服务性能急剧下降问题。文末也给各位留下了解决方案——日志级别动静调整。本文将具体介绍“动静日志”的实现原理及源码，心愿各位能在今后的生产环境中应答日志问题能“得心应手”！ 背景日志的重要性显而易见，是咱们排查问题，解决 BUG 的重要伎俩之一，然而在高并发环境下，又会存在悖论：大量打印日志，耗费 I/O，导致 CPU 占用率高；缩小日志，性能是下来了，然而排查问题的链路断掉了。 痛点：一方面须要借助日志可疾速排查问题，另一方面要兼顾性能，二者是否得兼？那么本文的动静日志调整实现就是为了能解决这个痛点所构思开发的。 性能个性低侵入，疾速接入：以二方包（jar）的模式染指，只须要配置启用，对业务无感及时响应，随调随改：应答研发不小心在大流量入口链路打印了大量 INFO 日志，能及时调整日志级别阶梯配置反对：默认全局设置兜底，又能够反对部分 Logger 放/限流人性化操作：与操作界面，不便批改<!-- more --> 技术实现如下，我将以 log4j2 为实例作解说，其它日志实现大同小异，参照实现即可。如下是 log 染指的配置文件示例： <?xml version="1.0" encoding="UTF-8"?><configuration status="info"><Properties> // 全局参数信息</Properties><appenders> // appender 具体配置</appenders><loggers> // 配置 appender 指向</loggers></configuration>以往咱们调整我的项目的日志时，要么是删除代码中的废日志，要么是批改下面的 xml 配置，针对某个包下或者类作日志级别限度，再从新打包部署失效。此时的效率是非常低的，不符个咱们的诉求。那么如何实现动静调整呢，首先想到的是 xml 调整日志级别后是如何失效的？xml 自身就是一些配置信息， log 的实现类读取 xml 信息动静批改日志级别，有没有可能咱们在程序中间接去调用 log4j 外部的封装办法，绕过 xml 不就好了？ 动静调整日志级别源码查看：具体源码我已放在 github dynamic-logger-util，可自行查看。顺着思路，查看 log4j 源码后，发现的确可行，如下即是调整日志办法的实现代码： // 获取日志上下文LoggerContext logContext = LoggerContext.getContext(false);Configuration configuration = logContext.getConfiguration();LoggerConfig loggerConfig = configuration.getRootLogger();loggerConfig.setLevel(level);// 失效logContext.updateLoggers();获取以后的 LoggerContext 后，再获取 configuration，以后的配置即是 xml 内的配置转换过去的，再获取 root logger, 即对应 xml 中的配置如下： ...

理解日志框架Java日志框架：slf4j作用及其实现原理Java日志零碎历史从入门到解体 常见的日志产品SLF4j框架通过扫描classpath上面的org/slf4j/impl/StaticLoggerBinder.class类来发现日志产品jar，个别用到的日志jar 有logback、log4j2。如下是是SLF4j框架对接各个日志产品的依赖。 slf4j-api 是SLF4j的框架APIlogback和slf4j-simple都是间接实现SLF4j框架的接口log4j 不是间接实现SLF4j接口，因而须要一个桥接jar，即slf4j-log4j12log4j2 和logj相似，也须要一个桥接的jar，即log4j-slf4j-impl，留神这个jar和log4j不一样。此外log4j2自身由两个jar组成，即log4j-api和log4j-core <dependencies> <!-- slf4j api--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <!-- slf4j logback implement--> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.2.3</version> </dependency> <!-- slf4j simple implement--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.7.25</version> </dependency> <!-- slf4j adapter for log4j start--> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.7.21</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.17</version> </dependency> <!-- slf4j adapter for log4j end--> <!-- slf4j adapter for log4j2 start--> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.12.1</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.12.1</version> </dependency> <!-- slf4j adapter for log4j2 end--> </dependencies>SLF4J如何进行SPISPI的全称是Service Provider Interface，是Java提供的可用于第三方实现和扩大的机制，通过该机制，咱们能够实现解耦，SPI接口方负责定义和提供默认实现，SPI调用方能够按需扩大。 ...

一、日志简介1.1 什么是日志？日志也叫 Log。用来记录零碎在运行过程中，产生的信息（变量值、参数、响应后果、谬误、异样）。保留到 xxx.log 文件中1.2 日志的作用剖析代码，定位bug调试代码理解零碎运行的状态剖析用户行为，做数据统计1.3 日志的级别logging.DEBUG：调试级别【高】logging.INFO：信息级别【次高】logging.WARNING：正告级别【中】logging.ERROR：谬误级别【低】logging.CRITICAL：严重错误级别【极低】 个性：日志级别设定后，只有比该级别 低 的日志会打印如：设定日志级别为 info。 debug 级别的日志信息，不会打印。 warning、error、critical 会打印1.4 日志的应用步骤将 日志源码文件（logging_use.py），存入 common/ 目录在 我的项目 目录下创立 log目录, 用来存储日志文件。初始化 日志配置 文件名,日志文件 切分的工夫距离单位,单位个数,保留的日志文件数打印日志(logging.级别（"输入的信息"）)1.5 日志的应用# 1.将 logging_use.py 文件部署到我的项目中。 个别：拷贝至 common/ 下。# 2.在 我的项目下 创立 log/ 用来寄存生成的 xxx.log 日志文件#3.在 `__init__.py`文件内，初始化日志信息，指定 日志文件名【必填】、单位、单位个数、保留文件个数。#4.在 原须要print打印输出的地位，替换应用 logging.级别(“想要输入的信息”)

2021年初，可观测性的概念在国内市场还鲜少有人提到，但到了2021年下半年，无关可观测性的研究和实际却开始如雨后春笋般层出不穷，出名公司 Grafana 甚至间接将原来的监控工具改成了可观测性技术栈并推了一系列服务。可观测性真的可能解决传统监控体系面临的诸多问题吗？又该如何构建可观测体系？本期，亚马逊云科技 Tech Talk 特地邀请到观测云 CEO 蒋烁淼带来分享《构建端到端的可观测体系最佳实际》。 可观测性为何忽然“火出圈”可观测性看似是个陈腐词，但其实它的起源远比咱们的认知要早得多。可观测性最早是匈牙利裔工程师鲁道夫·卡尔曼针对线性动静零碎提出的概念。若以信号流图来看，若所有的外部状态都能够输入到输入信号，此零碎即有可观测性。1948年伯特·维纳发表的著述《控制论-对于动物和机器中管制和通信的迷信》同样提到了可观测性。管制实践中的可观测性是指零碎能够由其内部输入推断其外部状态的水平。 随着云计算的倒退，可观测性的概念逐步走入计算机软件畛域。为什么近期可观测性的热度显著晋升了呢？ 蒋烁淼认为，这很大水平是因为零碎复杂性的加强。IT 零碎的实质是一个数字化的零碎，过来，零碎自身构造简略，多为单体式架构，且基础设施绝对固定，能够通过监控去查看零碎。但随着云原生时代的到了，治理对象从繁多主机逐步变成云，起初又变成云原生的分布式简单零碎，传统的面向基础设施的监控、简略的日志和简略的 APM 没有方法解决问题，因而，须要构建零碎残缺的可观测性。 可观测性中应用的次要数据类是指标、日志、链路。它们通常被称为“可观测性的三大支柱”。 指标（Metric）：指标是间断工夫下的零碎的值的记录，根底指标通常用于形容两种数据类型，一种是计数（Count），一种是计量（Gauge）。日志（Log）：零碎/利用输入的工夫相干的记录，通常由零碎/软件开发人员输入，不便定位系统的谬误和状态。链路（Tracing）：基于有向无环图构建的软件各个模块间接地调用关系。三大支柱至关重要，开发者正是通过这三个维度的数据来断定利用零碎的情况。和传统监控相比，可观测体系领有诸多劣势。 传统监控面向已知的问题，只能去发现和告诉那些已知可能会产生的故障，如：CPU>90%。次要监控对象是 IT 对象，仅面向服务端的组件，解决根底的运维问题。 而可观测性则可能帮助发现并定位未知的问题。其外围是一直收集零碎产生的各种外围指标与数据，通过数据分析的形式来保障和优化业务，如：发现小程序客户端在某个城市的领取失败率十分高，从而判断是否是代码层面上导致这样一个异样。可观测性次要监测的对象不仅仅是IT对象，还有利用和业务，面向云、分布式系统、APP/小程序。 在分享中蒋烁淼谈到，随着基础设施的倒退，传统监控将逐渐被可观测性所取代。 他将构建可观测性的价值总结为以下五点： 让 SLO 可视化，清晰的指标和现状发现与定位未知问题缩小团队间的廓清老本升高业务异样造成的无奈预知的经济损失晋升最终用户体验和满意度开源 or SaaS，可观测性构建正确的打开方式是？相比于传统监控体系，构建可观测性既然有诸多劣势和价值。那么该如何构建可观测性呢？ 首先，须要尽可能地收集所有组件零碎的所有相干⾯的根底数据，包含云、主机、容器、Kubernetes 集群，应⽤和各种终端。实时收集这些数据的老本并不⾼，但如果没有收集，⼀旦系统故障须要排查剖析的时候，就⽆法无效评估过后的状态。 其次，要明确零碎可观测性构建的责任。谁是这个组件的构建者，谁负责定义这个组件的 SLI，谁负责收集所有的相干根底数据并构建相应的仪表盘以及谁为相干的组件的 SLO 负责，须要责任到人。 第三，开发者须要为可观测性负责。开发者要将⾃⼰开发零碎的可观测性数据裸露作为软件品质⼯程的⼀局部，如果说单元测试是为了保障最⼩单元代码的可⽤性，那么开发者标准化裸露可观测性根底数据也将作为⽣产系统可靠性的必要条件。 第四，须要建⽴统⼀的指标、⽇志、链路标准，统⼀团队的⼯具链。即采取雷同的指标命名标准，雷同的⽇志格局，雷同的链路零碎。如果在遵循 OpenTelemetry 规范后，仍有不同，则可定义串联整个零碎的统⼀TAG 标准，如：所有谬误都是 state:error。 第五，要继续优化改良整体可观测性。针对整个零碎的可观测，包含数据收集，视图构建，TAG 体系建⽴，这些步骤均须要工夫，不能因为覆盖度或者构建的仪表盘未能在某次事变中施展作⽤而持续⽤过来的⽅式解决问题。每次未被观测的故障都是进⼀步晋升可观测范畴的绝佳机会。 从可观测性构建的门路不难看出，其过程是非常复杂的。那么，支流的构建形式有哪些？蒋烁淼介绍了两种最为常见的可观测性构建形式，别离是通过开源的形式构建和采纳 SaaS 产品进行构建。 得益于开源生态的蓬勃发展，为可观测性的构建提供了诸多抉择。采纳开源的形式构建，须要构建者从前端的数据抓取到后端的数据处理，包含数据展现、告警等周边性能的相干常识有十分详尽的理解把握。因而，这种形式适宜于那些有足够实力或者学习老本及工夫老本绝对短缺的团队。 相比于开源的形式，采纳成熟的 SaaS 产品构建可观测性是一种更加高效的形式。蒋烁淼以观测云的产品为例，介绍了这种形式的四点劣势。 不做缝合怪：在服务器内仅装置一个 agent 就能够收集这台主机所有相干的零碎数据，防止成堆的 agent 和配置项。不做小白鼠：能提供端到端的残缺笼罩，并能做到开箱即用，防止参差不齐的集成，如：观测云就可能反对超过200种技术栈，实现端到端的笼罩。不关闭、高度可编程：可实现轻松构建任意的可观测场景，甚至将业务数据参数引入到整体的观测中，灵活性强。此外，还可能防止死板的集成，领有弱小的二次开发能力。不留隐患：察看云对用户侧代码永恒开源，单向通信，不会也不能向客户环境下发指令。所有的数据收集默认脱敏且用户可对整个过程进行管制。 后面提到，可观测性的构建是应“云”而生的，不仅如此，观测云自身也是完完全全的云原生产品。观测云中整套产品包含数据平台，都是部署在亚马逊云科技的 EKS 之上的，并基于容器进行编排。观测云的整体架构非常简单，即通过一个 agent 将海量数据进行对立，进入数据平台，而后通过平台的能力提供残缺的可观测性。整个零碎分为外围平台层、Web 层和数据接入层，外围平台层是齐全由观测云进行自研的，没有进行开源。下层的 Web 层，在外围数据处理平台上有一套与平台对接的 API。蒋烁淼说：“对于客户来说，更举荐间接抉择观测云的 SaaS 产品，如果违心，客户也能够在亚马逊上齐全孤立地进行部署，也是十分不便的，只不过整体费用要比间接采纳 SaaS 产品高得多。 为什么会抉择亚马逊云科技？次要是基于以下考量： 观测零碎自身要有高一个数量级的可靠性和更高的 SLA：观测云是帮忙客户构建可观测性零碎的平台，因而须要本身领有很高的可靠性，如果不能提供足够高的可靠性，一旦观测零碎呈现故障，便无奈及时揭示客户，提供具体的剖析更无从谈起。此外，抉择云服务自身也可能让一部分观测云平台的 SLA 由亚马逊来提供。更成熟的 Marketplace：用户可通过中国的团队间接在亚马逊上进行产品购买，亚马逊云科技会把产品生产间接在 Marketplace 上记账。须要阐明的是，观测云的产品是依据数据规模来付费的，当用户没有数据量的时候简直是收费的。全球性：亚马逊云科技可能提供比海内产品更好的兼容性，尤其对于中国的技术栈整体老本更低。蒋烁淼在分享中走漏：“在春节过后，观测云将会在海内亚马逊云科技节点部署咱们的观测平台。观测云心愿用中国力量为中国的出海客户提供比海内产品更好的、老本更低的抉择。”借力 APN 融入亚马逊云科技寰球网络：观测云心愿借助亚马逊云科技弱小的生态，将可观测性作为最终对客户提供服务的伎俩，并心愿可能借力APN，帮忙更多用户理解可观测性的成果，这个也是观测云抉择亚马逊科技十分重要的起因之一。除了是完完整整的云原生产品，在观测云的零碎中，还蕴含几个十分乏味的设计。首先，在采集侧： ...

在生产环境记录利用的运行日志曾经成为常规，但日志须要通过解决和剖析才有意义，第三方日志管理工具的呈现正旨在解决这个问题。 软件剖析公司 Takipi 负责产品市场的 Josh Dreyfuss 今日撰文，比拟了三个有代表性的日志管理工具： Splunk 、 Sumo Logic 和 Logstash ， 从性能、易用性、资源占用等方面剖析了它们的优缺点。 概述这篇文章别离从 on-premises、SaaS，以及开源三种模式选取一个有代表性的日志管理工具进行剖析， Splunk、Sumo Logic 和 Logstash 别离对应这三种不同的模式。 Splunk是日志管理工具行业一个比拟大的玩家，它专攻企业市场，并以 on-premises 模式运作。Splunk 领有最多功能和弱小的整合能力，但价格也最高。为了投合目前 ITOA 畛域的发展趋势，Splunk 也提供了 SaaS 版本，并且为 SMB 筹备的更轻量级的版本。不过本文将只剖析 Splunk 的 on-premises 业务所提供的服务。Sumo Logic最后试图成为 Splunk 的 SaaS 版本代替，不过他们走出了本人独有的倒退路线。到当初，它们曾经是市场上性能最丰盛的 SaaS 版日志管理工具之一，并且它们也专攻企业市场。Logstash是一款开源的工具，常常作为 ELK 技术栈的其中之一应用，另外是 ElasticSearch 和 Kibana。在 ELK 技术栈里，Logstash 承当的是日志解决，它创立一个集中化的管道来贮存、搜寻和剖析日志文件。它应用内建的过滤器和输入输出，以及一些插件来给日志治理提供弱小的性能。比拟装置：因为 on-premises、SaaS、开源模式的不同，三者的装置也各不相同，应用 Splunk 和 Logstash 你须要提供硬件和网络等基础设施，另外应用 Logstash 你通常还须要装置 ELK 外面的另外两个。性能：Splunk 的性能可能是市面上最丰盛的，你简直能够从它的 UI 或 API 调出你所须要的任何数据——前提是你的日志蕴含这些数据。并且它领有高可用性、可扩展性，以及很器重安全性，另外它还能解决很多类型的机器数据。Sumo Logic 则是性能最丰盛的日志治理 SaaS 软件之一，它领有很多和 Splunk 相似的性能，另外还有一项个性是设置工夫的触发揭示。Logstash 则因为其开源个性，领有最强的自定义能力，你能应用自定义的日志格局或者定制自定义插件。应用界面：Logstash 并不蕴含 UI，其前端局部由 ELK 中的 Kibana 实现，你也能够应用 Graphite、Librato 和 DataDog 来代替 Kibana。Splunk 提供一个内容丰盛且灵便的界面，可通过 XML 或拖拽来定制。Sumo Logic 的界面则专一于显示实时数据。集成与插件：抉择工具时一个重要的点是看它是否与你现有的工作流集成良好，对于日志管理工具的度量指标，则须要思考它是否能解决你已有的日志以及是否与你的环境同步。Splunk 有超过 600 个可用的插件，为它解决日志提供了强力的撑持。Sumo Logic 是为特定的大型工具设计，包含开发自动化工具、云平台、零碎平台，以及平安工具。Sumo Logic 笼罩了支流的工具，但对于较小的或比拟少见的工具则无能为力。Logstash 作为开源工具，它的插件始终在增长，目前它已有超过 160 个插件，大部分来自社区。价格：Splunk 的价格为每年 1800 到 60000 美元，Sumo Logic 提供一个精简的免费版，以及 60 美元 /G 的免费版本。Logstash 则为开源收费，不过你依然须要本人承当服务器和带宽费用。文档和社区：对于工具的抉择，文档的丰盛水平以及社区的沉闷水平也是重要的考量指标。Splunk 领有十分丰盛的文档，以及以在线论坛模式组织的社区。Logstash 的文档也不错，不过有些中央存在前后不统一。Sumo Logic 的文档则不够丰盛，社区也比拟令人困惑。总结 ...

官网 Winston 非常适合配置不同的日志目的地。 在咱们的小应用程序中，让咱们创立另一个传输。 这次我想把日志保留到一个数据库中，MongoDB 简洁一些。 在 logger.js 文件上，复制以下代码块。 确保装置 Winston MongoDB，即 npm install winston-mongodb。 How to use MongoDB下载并装置 MongoDB 社区服务器。 导航到您的环境变量（对于 Windows 用户），在用户变量下，抉择门路 → 编辑 → 新建，增加 C:\Program Files\MongoDB\Server\4.4\bin（4.4 可能因您计算机上安装的 MongoDB 版本而异）. 关上命令提示符并键入 mongo。 这将查看您是否已胜利装置 MongoDB。 MongoDB shell 版本将打印在您的终端上，这意味着您的装置胜利。 输出 use logs 创立数据库日志。 输出 db.createCollection("server_logs") 以创立 collection. 在 logger.js 里插入下列代码： const { createLogger, format, transports } = require('winston');// Import mongodbrequire('winston-mongodb');module.exports = createLogger({transports:[// File transport new transports.File({ filename: 'logs/server.log', format:format.combine( format.timestamp({format: 'MMM-DD-YYYY HH:mm:ss'}), format.align(), format.printf(info => `${info.level}: ${[info.timestamp]}: ${info.message}`),)}),// MongoDB transport new transports.MongoDB({ level: 'error', //mongo database connection link db : 'mongodb://localhost:27017/logs', options: { useUnifiedTopology: true }, // A collection to save json formatted logs collection: 'server_logs', format: format.combine( format.timestamp(), // Convert logs to a json format format.json()) })]});运行 node app.js 以启动服务器并拜访以下 URL 以触发服务器响应和申请。 ...

if (process.env.NODE_ENV !== 'production') { logger.add(new winston.transports.Console({ format: winston.format.combine( winston.format.colorize({ all: true }), winston.format.simple() )}));}上述代码的含意是，如果以后 Node.js 执行环境不是生产环境，则将 winston 的输入，打印到管制台上。 _stream_readable.js 抛出 data 事件： 读取事件处理函数： console 对应的 event handler： transformed： console 有专门对应的 transport 实现文件，位于 console.js 内： 从 data 字符串能看出在 console 打印黑白字符串的实现形式： 并没有像我设想的那样，执行到 82 行的 console.log console 对象的 _stdout 属性，在 internal 这个 constructor.js 里注入： 这个 writeUtf8String 函数，是原生 native API： 位于 Node.js 源代码 的 internal/stream_base_common.js 外部： ...

依照这篇文章日志库 winston 的学习笔记 - 创立一个应用 winston 的 Node.js 利用里的代码，对下列办法进行单步调试： 因为咱们调用的是 info 办法，所以生成的日志，level 为 info： 第一个参数为 message，前面的都是 meta 信息：在 info 的实现代码里，首先判断传入 log 办法的参数个数： 如果参数个数为 0 或者 1，有专门的实现。否则，进入 self.log: 结构 info 对象： 其中 msg 变量存储的是用户调用 info 办法传入的第一个参数，meta 是传递的第二个参数。 最初调用外部的 write 办法，传入的 message，是两个参数的连贯。 encoding 是 utf8 chunk： write 外面先 read，而后再 _transform: format 咱们抉择的是 json format： json.js 负责把 info 对象序列化成 json 字符串： 后果： addChunk： emit： 三个 listeners： data listener： ...

winston 被设计为一个简略且通用的日志库，反对多种传输。 传输实质上是日志的存储设备。 每个 winston 记录器都能够在不同级别配置多个存储渠道。例如，人们可能心愿将谬误日志存储在长久的近程地位（如数据库），但所有调试日志都输入到控制台或本地文件。 应用 winston 的举荐办法是创立您本人的记录器。 最简略的办法是应用 winston.createLogger： const winston = require('winston'); const logger = winston.createLogger({ level: 'info', format: winston.format.json(), defaultMeta: { service: 'user-service' }, transports: [ // // - Write all logs with level `error` and below to `error.log` // - Write all logs with level `info` and below to `combined.log` // new winston.transports.File({ filename: 'error.log', level: 'error' }), new winston.transports.File({ filename: 'combined.log' }), ],}); //// If we're not in production then log to the `console` with the format:// `${info.level}: ${info.message} JSON.stringify({ ...rest }) `//if (process.env.NODE_ENV !== 'production') { logger.add(new winston.transports.Console({ format: winston.format.simple(), }));}winston 的日志等级const levels = { error: 0, warn: 1, info: 2, http: 3, verbose: 4, debug: 5, silly: 6};如何创立 loggerconst logger = winston.createLogger({ transports: [ new winston.transports.Console(), new winston.transports.File({ filename: 'combined.log' }) ]});即便 logger 实例创立之后，也能容易地删除或者削减新的 transport： ...

须要思考的问题1.log要具备显示调用方文件名和行号的能力，要不然你连谁打的这个log都不晓得2.log要具备按申请聚合的能力，不然上下文全是乱的，没法看。光给你一行报错log你能剖析为啥出错？必须是这个申请的残缺log才有价值。3.在2的根底上要有按用户聚合的能力，不便查流水4.在3的根底上要有染色能力，指定用户能log全开，实时定位问题5.log能还原成fiddler抓包，重现现场，对于概率性问题保留现场再重要不过了。6.log要具备单机调试性能，能够不停机编写条件开启指定log，忽视日志级别。 分布式跟踪零碎-产品比照https://github.com/1046102779/opentracing/blob/master/%E5%88%86%E5%B8%83%E5%BC%8F%E8%B7%9F%E8%B8%AA%E7%B3%BB%E7%BB%9F%E2%80%94%E2%80%94%E4%BA%A7%E5%93%81%E5%AF%B9%E6%AF%94.md Jaegerhttps://pjw.io/articles/2018/...https://www.alibabacloud.com/... How to usehttps://github.com/jaegertrac... Documenthttps://www.jaegertracing.io/...阿里云jaeger：基于 Jeager 开发的分布式追踪零碎，反对将采集到的追踪数据长久化到日志服务中，并通过 Jaeger 的原生接口进行查问和展现 https://github.com/aliyun/ali...基于opentracing + jaeger 实现全链路追踪 https://www.jianshu.com/p/fbe...opentracing + jaeger node实际： [https://www.bookstack.cn/read...] PandoraWhy 1.x.xhttps://github.com/midwayjs/p...因为原定的配套sandbox在社区部署十分艰难，导致pandora这个货色无奈疾速部署，展示报表等，后续应该也很难在社区应用，倡议应用其余同类产品代替（pm2 等），咱们也会在其余中央标注。如上所说，当初 2.0 版本次要在团体内应用。当初文档是针对 Pandora.js 1.0 的，能够尝试装置 pandora@1.x.x；How to usenpm install pandora@1.x.x -gDocumentshttps://midwayjs.org/pandora/zh-cn/guide/introduce.html#%E8%AE%BE%E8%AE%A1%E5%8E%9F%E5%88%99 TipsMidway npm源应用社区源midway启动自定义：https://midwayjs.org/midway/guide.html#%E6%A1%86%E6%9E%B6%E6%89%A9%E5%B1%95pandora启动配置：https://midwayjs.org/midway/guide.html#%E9%80%9A%E8%BF%87%E5%86%85%E7%BD%AE%E7%9A%84%E5%90%AF%E5%8A%A8%E6%96%87%E4%BB%B6启动参数配置：https://midwayjs.org/midway/guide.html#%E5%90%AF%E5%8A%A8%E5%8F%82%E6%95%B0%E4%BC%A0%E9%80%92npm run build ; pandora startTSWhttps://github.com/Tencent/TSW

前言日志是开发者用来分析程序和排查问题的重要工具。随着零碎架构从晚期的单体利用，演变到现在的微服务架构，日志的重要性也逐渐晋升。除了用日志辅助问题排查，还能够通过日志对微服务申请的全链路进行性能剖析，甚至能够它用来解决分布式系统中的一致性问题。与此同时，零碎产生的日志量和日志治理难度也显著减少。于是，日志管理工具随之诞生并迭代降级。从最开始登录到跳板机上查看日志，到自建分布式日志核心来对立治理日志流，到云平台厂商提供专门的日志治理服务。开发者只须要在利用中接入SDK将日志回流到日志平台，就能够应用日志平台提供智能检索、数据分析以及链路剖析等能力，平台中易用的图形化界面和成熟的数据管理能力极大的晋升了开发效率。 然而，日志治理平台并不是万能的，总有一些场景它会缺席（如本地调试产生的日志并不会回流到日志平台，不反对简单的数据分析，当然还有最常见也是最令人解体的，数据失落了。。。），而咱们不得不和一大堆原始日志文件面面相觑。这时咱们就不得不从工具包中掏出原始的武器-linux指令，开始一顿操作猛如虎。 本文将联合本人在日常开发过程中遇到的场景给出对应的日志检索语句，也欢送大家将它珍藏到本人的工具包中，或是在下方留言本人遇到的日志剖析难题，博主会将其欠缺到文章中。 日志构造在理解到日志剖析语句之前，先简略介绍一下日志的类型和构造，后序将以这一节介绍的内容作为背景提供具体的日志剖析语句。 日志类型次要有两种，一种是业务日志，即实现业务性能的过程中产生的日志，通常是开发者在程序中被动埋点触发的。还有一种是系统日志，这一类日志范畴更大，底下还能够持续细分，如零碎所在的宿主机各项指标的快照，或者是依赖的中间件外部打印的日志等。 业务日志和系统日志通常在不同的目录下，事实上，不同类型的系统日志个别也会用独立的目录进行隔离。以一个接入了Mysql，RocketMq的零碎为例，它的日志目录构造可能如下所示： /log /mysql /rocketmq /app /app_name1 /app_name2可见，app下不同的业务零碎之间也会进行日志隔离，不便检索和查看。 接着看一下每个目录下日志文件的构造，这个往往没有相对的规范，开发者通常依照零碎的须要设计日志文件构造，甚至产生指定用处的日志（如mysql的bin log和relay log）。这里简略介绍一下我进行零碎开发时习惯的日志结构设计。 通常我至多会辨别出三个日志文件: application.log, application-error.log和application-warn.log。正如文件的名称所示，它们别离对应不同级别的日志，application.log中会蕴含利用生命周期中的全副日志，而application-error.log和application-warn.log日志则别离只记录error级别日志和warn级别日志，从而不便疾速定位系统异样。然而，如果你间接查看目录下的所有日志文件，会发现它不止有这三个文件. 这是因为零碎运行过程中会产生大量的日志，如果只用一个文件进行日志的存储，会导致文件变得极为宏大并重大耗费磁盘空间。因而，操作系统或是日志工具在通过配置后会执行日志截断，压缩和备份等操作，缩小日志对整个宿主机稳定性的影响。被截断后的日志会依据配置在日志名加上后缀并保留，通常是加上工夫戳。 除了上文所示的依据日志级别来划分多个日志文件，还能够从别的维度设计日志文件，比方将零碎流量的入口和进口别离打印日志。流量的入口能够了解为RPC接口Server端，HTTP服务Server端，MQ接管消息日志等，与之绝对的流量的进口是指RPC接口Client端，调用上游HTTP服务等。因而整个日志目录将会蕴含以下几个文件 application.logappilcation-error.logapplication-warn.logrpc-client.logrpc-server.logmq.log具体的日志配置不在本文的范畴内，大家能够自行浏览logback等日志框架的文档。 日志剖析小操作接下来将会列出在日常开发过程中常见的日志查问和剖析场景，并给出对应的指令。 查看日志查看单个日志文件cat是咱们最罕用的浏览文件的指令，通过cat ${filename}即可展现文件的内容。以application.log为例 cat application.log这个指令实用于查看所有可读文件。 查看多个日志文件上文提到，因为Logrotate机制的存在，日志文件往往会被截断成多个带有不同工夫戳后缀的文件，而咱们又不确定想要查问的日志具体在哪个文件中，这时候能够将多个文件都传给cat指令，cat ${filename} ${filename2} ${filename...}，cat会一一读取文件并展现。然而如果文件数量十分大呢？幸好cat指令反对相似正则的匹配，*关键字容许咱们匹配任意多个字段。 cat application1.log application2.log application3.logcat application.log*当然，在文件数量很多的时候用cat指令查看全量日志曾经不是很好的抉择了，下文将会给出其它日志查询方法。 查看最初几行日志cat指令会将整个日志文件从头到尾读取并展现在控制台，然而有时咱们往往只须要看最近一段时间的日志即可。而且在日志文件特地大的时候，用cat指令不仅比较慢，而且会导致大量无关的日志充斥屏幕影响浏览。这时用tail指令就能够很好的解决这个问题。tail指令能够只读取日志最初几行内容并展现在屏幕上。 tail application.log # 读取application.log文件最初一部分日志tail指令同样反对传入多个文件，它会依照程序别离读取几个文件的最初一部分内容并打印到控制台 tail application1.log application2.log application3.log如果想要指定展现最初100行的日志，则能够应用tail -n来配合查问： tail -n 100 application.log查看增量日志有时，咱们心愿实时查看日志文件的内容，从而更疾速的捕捉到零碎的行为，tail -f指令则反对动静的展现文件新增的内容。如果想要退出主动刷新，能够通过ctrl+c指令来实现： tail -f application.log分页查看日志有时，因为日志内容切实太多，导致控制台疯狂输入，间接吞没了要害信息。因而，须要一个指令可能分页查看日志内容，升高控制台刷新的频率。more指令为这个场景提供了十分好的反对。 more application.log执行了more指令后，控制台将会逐屏展现文件内容，能够应用空格(space键)来展现下一屏的内容，回车（Enter键）展现下一行的内容，Q键退出more指令 至此，文件的全文查问和局部查问的次要指令曾经给出，上面给出另一种类型查问，依据关键字查问，的相干指令 关键字检索依据关键字检索日志在分布式系统中，往往会有数十甚至数百个零碎参加到流程中，这时流量的入口会生成一个惟一的logId用来串联和标记全链路申请。当咱们须要上下游排查问题时，往往会将logId提供给对方来排查。同样，当咱们拿到logId时也须要从日志中跟该logId有关联的日志内容查问进去。这就是一个典型的依据关键字检索日志的场景。grep指令很好的解决了这个问题，它可能将日志中和关键字匹配的行打印进去。 grep "logId" application.log下面的指令会将application.log文件中所有蕴含logId的行打印进去。grep指令同样反对多文件查问 grep "logId" application1.log application2.log application3.loggrep "logId" application*.log还有正则表达式的匹配或者是大小写不敏感的匹配 grep "logId" application.log -i # 大小写不敏感grep -E "[\w\d]*" application.log # 正则表达式这里顺便揭示一个零碎设计的留神点，在分布式系统中logId是通过写入以后线程上下文中实现传递，因而如果在以后线程中提交了一部分工作给异步线程执行，同时有心愿可能用以后线程来跟踪，则务必记得将logId传递到异步线程的上下文中。 ...

体验简介本场景将提供一台配置了CentOS 7.7版本的ECS实例（云服务器）。通过本教程的操作，您能够基于已有环境疾速采集Nginx日志。 体验此场景后，能够把握的常识有： 日志服务数据导入基本操作。 背景常识本场景次要波及以下云产品和服务： 日志服务：日志服务SLS是云原生观测与剖析平台，为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。日志服务一站式提供数据采集、加工、查问与剖析、可视化、告警、生产与投递等性能，全面晋升您在研发、运维、经营、平安等场景的数字化能力。 云服务器ECS：云服务器（Elastic Compute Service，简称ECS）是阿里云提供的性能卓越、稳固牢靠、弹性扩大的IaaS（Infrastructure as a Service）级别云计算服务。云服务器ECS免去了您洽购IT硬件的后期筹备，让您像应用水、电、天然气等公共资源一样便捷、高效地应用服务器，实现计算资源的即开即用和弹性伸缩。阿里云ECS继续提供创新型服务器，解决多种业务需要，助力您的业务倒退。 上传日志文件1、关上虚构桌面的FireFox ESR浏览器，在RAM用户登录页面，输出云产品资源列表中的子用户名称，而后单击下一步。2、在用户明码页面，输出云产品资源列表中的子用户明码，而后单击登录。 3、在浏览器中关上新页签，拜访如下地址，下载测试日志文件。 https://sls-shiyanshi.oss-cn-hangzhou.aliyuncs.com/sls/testlog.csv4、在浏览器中关上新页签，复制如下对象存储OSS控制台地址，粘贴到地址栏中并拜访。 https://oss.console.aliyun.com/5、在对象存储控制台左侧导航栏中，单击Bucket列表。6、在Bucket列表页面，单击Bucket名称。7、在文件治理页面，单击新建目录。8、在新建目录对话框中，输出目录名sls，单击确定。9、在文件治理页面，单击文件名sls。10、在sls目录中，单击上传文件。11、在上传文件页面，文件ACL抉择公共读，单击扫描文件，找到目录/home/adc/下载，抉择下载好的测试日志test.log，而后单击上传文件。 在工作列表页面，期待状态变为上传胜利，示意测试日志文件曾经上传胜利到OSS。 创立Logstore1、在浏览器中关上新页签，复制如下日志服务控制台地址，粘贴到地址栏中并拜访。 https://sls.console.aliyun.com/2、在日志服务控制台页面下方的Project列表区域，抉择云产品资源列表中Project name，而后单击Project名称。3、在左侧日志库性能栏中，单击 4、在创立Logstore对话框中，输出Logstore名称，关上WebTracking开关，而后单击确定。参数阐明： Logstore名称：自定义Logstore名称，在其所属Project内必须惟一。创立Logstore胜利后，无奈更改其名称。 WebTracking：关上WebTracking开关，您能够通过WebTracking从HTML、H5、iOS或Android上采集数据到日志服务。5、在创立胜利对话框中，单击勾销。 导入OSS数据1、在日志服务控制台的接入数据区域，单击OSS-对象存储。2、在抉择日志空间页面，在我的项目Project中抉择云产品资源列表中的Project name，在日志库Logstore中抉择步骤三中创立的Logstore，而后单击下一步。3、在数据源设置页面，输出配置名称，抉择OSS Region、Bucket，输出文件夹前缀，抉择数据格式，而后单击预览。参数阐明： 配置名称：自定义配置名称。 OSS Region：待导入的OSS文件所在Bucket的地区，可在云产品资源列表中查看Bucket的地区。 Bucket：待导入的OSS文件所在的Bucket，可在云产品资源列表中查看Bucket Name。 文件夹前缀：待导入的OSS文件所在文件夹的前缀，输出sls/。 数据格式：文件的解析格局，抉择单行文本日志。 4、在文件预览后果框中，预览数据，后果无误后，单击下个配置。 5、在数据格式配置页面，单击测试，测试后果无误后，单击下个配置。 6、在调度距离页面，关上立刻执行，单击下一步。 7、在查问剖析配置页面，单击下一步。8、在完结页面，单击查问日志。9、在查问剖析对话框中，单击确定。10、在查问剖析页面，稍等几分钟后，单击查问/剖析，即可查问到从OSS导入的日志数据。

一、前言日志不仅记录了程序的执行过程，同时也是剖析问题的一种重要伎俩。 对于神策剖析 iOS SDK 而言，通过日志零碎岂但能够理解到 SDK 的行为，而且便于咱们排查问题。因而，日志零碎是 SDK 中必不可少的一项性能。 上面针对神策剖析 iOS SDK 日志零碎进行解析，心愿可能给大家提供一些参考。 二、日志打印形式对于 iOS 开发而言，在控制台打印日志的罕用形式有 NSLog 和 printf，咱们先来看一下两者的区别。 2.1NSLogNSLog 是 Foundation 框架提供的日志输入函数，能够在控制台进行格式化输入。 日志的内容会主动蕴含一些零碎信息，例如：项目名称、工夫等。另外，NSLog 还能够打印 OC 中的对象，并且输入的内容会主动换行。示例代码如下： //代码 NSString * a = @"Hello World!"; NSLog(@"这里是第一个 %@", a); NSLog(@"这里是第二个 %@", a); /**控制台日志： 2021-05-17 14:45:01.550403+0800 use-sdk[4608:164047] 这里是第一个 Hello World! 2021-05-17 14:45:01.550498+0800 use-sdk[4608:164047] 这里是第二个 Hello World! */ 2.2printfprintf 只能打印 char 类型，并且内容不会主动换行，须要咱们手动操作[1]。示例代码如下： //代码 printf("Hello World!!!\nHello World!!!\nHello World!!!"); /** Hello World!!! Hello World!!! Hello World!!! ...

先记录后优化应用命令行查看日志的时候，如果想要带有黑白的话，简略脚本如下。 colorize.sh #!/bin/bash# 上面的 ERROR 等是匹配到的，辨别大小写，这里的例子是 springboot 的日志# Example:# 2021-07-14 14:34:19.222 DEBUG 5960 --- [http-nio-8089-exec-3] c.y.c.b.m.P.selectList : <== Total: 8awk 'function color(c,s) { printf("\033[%dm%s\033[0m\n",30+c,s)}/ERROR/ {color(1,$0);next}/SUCCESS/ {color(2,$0);next}/WARNING/ {color(3,$0);next}/INFO/ {color(7,$0);next}/DEBUG/ {color(6,$0);next}{print}' $1# 应用例子：$ sed -n '/2021-07-14 14/,$p' ./logs/spring.log | colorize如果想要更多的色调，上面的文章有将到，前面有空再写 256 color 的脚本。 Refs: Shell - Customize the color of each line of a log file based on a patternTerminal Control Sequences 终端管制转义序列Enable 256 Color Terminal in UbuntuFeatures/256 Color Terminals在 NodeJS 终端输入有简略款式的文本内容

摘要：云日志服务（Log Tank Service，简称 LTS）能够提供日志收集、剖析、存储等服务。用户能够通过云日志服务疾速高效地进行设施运维治理、用户业务趋势剖析、安全监控审计等操作。本文分享自华为云社区《【云图说】第32期 窥探日志的机密》，原文作者：阅识风波 。 网络设备、操作系统及服务程序等软硬件在运行时都会产生 log，记录着该事件产生的工夫、使用者、具体操作等相干形容。然而，因为日志通常不属于零碎的外围性能，所以经常不被器重。直到须要决策分析和问题定位时，这时日志的重要性才会凸显进去。 点击关注，第一工夫理解华为云陈腐技术~

zap是 Uber 开发的一个高性能、强类型、分 level 的 go 语言日志库1.对象创立1.1 Logger 构造体type Logger struct { core zapcore.Core // 外围接口 development bool addCaller bool onFatal zapcore.CheckWriteAction // default is WriteThenFatal name string errorOutput zapcore.WriteSyncer addStack zapcore.LevelEnabler callerSkip int clock Clock}Logger对象的创立有两种形式: 通过New 间接创立func New(core zapcore.Core, options ...Option) *Logger { if core == nil { return NewNop() } log := &Logger{ core: core, errorOutput: zapcore.Lock(os.Stderr), addStack: zapcore.FatalLevel + 1, clock: _systemClock, } return log.WithOptions(options...)}函数WithOptions应用的是函数式抉择模式, 和ants源码浏览（https://segmentfault.com/a/11... 中应用的办法统一。 ...

以前有关注到 Loki 这个开源我的项目，还是 1.x 的，借鉴了prometheus 的 chunks 存储，labels, promql 查问等个性，做了一套日志零碎。 和 docker / k8s 集成比拟好，最近看到版本到 2.2，感觉能够小试一下 整体架构 下面的架构图，形容了 Loki 的几个根底组件 promtail: 日志采集组件，通过配置scrape_configs（嗯，看着和prometheus的采集配置如同啊)，采集对应的本地文件，journal日志，应用positions(一个yaml配置文件)，治理采集偏移量等，在通过http的形式，推送到远方的存储中loki: 外围日志存储，查问组件，能够拆分为 querier，ingester, distributor 等多个组件，也能够部署为一个过程，数据存储能够落地为S3的文件中（大杀器啊，对象存储切实是太好用了）grafana: 数据查问模块，能够应用LogQL(一种相似promql的语法）查问当然还有一些其余组件，如loki-canary（日志链路可用性监控）, fluentd（和fluentd对接的）等 梳理下需要本人始终有多个 VPS，先看下本人有哪些节点 3台VPS：广州，香港，美国各1， 配置1外围/2G ~ 2外围4G，都有公网IP1台软路由：没有公网IP，可上网1台NAS：11T硬盘，16G内存，家里，可上网3 个都是 linux 零碎，而且下面的组件都容器化的，应用 docker-compose 治理，以前应用过 ELK，对于 VPS 来讲，太重了，始终找不到一个适合的日志零碎，当初能够在 loki 上小试牛刀 因为都曾经容器化，所以 docker 的规范输入是须要收集的，采集的需要总结如下 docker 规范输入本地的日志文件systemd 日志文件对应不通过的地区，还须要买通相干的网络环境，可能对立收集到内网的 NAS 中 如何收集 docker 规范输入日志对于 docker 标出输入，默认实现上，是会落到本地文档的，能够通过docker inspect id， 返回的LogPath 看到具体文件门路地址 个别的采集计划，就是主动获取 LogPath，而后采集对应的文件即可 Loki 采纳的是实现了一个规范的 Docker Log Driver, 装置好插件，就能够间接推送了，应用流程如下 先部署 loki-docker-driver ...

graylog 是一个开源的业余的日志聚合、剖析、审计、展现、预警的工具，跟 ELK 很类似，然而更简略，上面说一说 graylog 如何部署，应用，以及对 graylog 的工作流程做一个简略的梳理本文篇幅比拟长，一共应用了三台机器，这三台机器上部署了 kafka 集群(2.3)，es 集群(7.11.2)，MongoDB 正本集(4.2)，还有 graylog 集群(4.0.2)，收集的日志是 k8s 的日志，应用 DaemonSet 的形式通过 filebeat(7.11.2)将日志收集到 kafka 中。本文将从部署开始，一步一步的理解 graylog 是怎么部署，以及简略的应用。 graylog 介绍 组件介绍从架构图中能够看出，graylog 是由三局部组成： mongodb 寄存 gralog 管制台上的配置信息，以及 graylog 集群状态信息，还有一些元信息es 寄存日志数据，以及检索数据等graylog 相当于一个直达的角色mongodb 和 es 没什么好说的，作用都比拟清晰，重点说一下 graylog 的一些组件，及其作用。 Inputs 日志数据起源，能够通过 graylog 的 Sidecar 来被动抓取，也能够通过其余 beats,syslog 等被动推送Extractors 日志数据格式转换，次要用于 json 解析、kv 解析、工夫戳解析、正则解析Streams 日志信息分类，通过设置一些规定来将日志发送到指定的索引中Indices 长久化数据存储，设置索引名及索引的过期策略、分片数、正本数、flush 工夫距离等Outputs 日志数据的转发，将解析的 Stream 发送到其余的 graylog 集群Pipelines 日志数据的过滤，建设数据荡涤的过滤规定、字段增加或删除、条件过滤、自定义函数Sidecar 轻量级的日志采集器LookupTables 服务解析，基于 IP 的 Whois 查问和基于源 IP 的情报监控Geolocation 可视化地理位置，基于起源 IP 的监控流程介绍 ...

背景介绍因为VPC的Flow log不是实时的， VPC flow log在聚合工夫距离内捕捉数据后，须要额定的工夫来解决数据并将其公布到 CloudWatch Logs 或 Amazon S3。此额定工夫，对于公布到 CloudWatch Logs 约为 5 分钟，对于公布到 Amazon S3 约为 10 分钟。流日志服务在此额定的工夫内以最大限度提供。在某些状况下，您的日志可能会提早超过后面提到的 5 到 10 分钟的额定工夫，无奈满足一些客户对于流量剖析的实时性要求，因而客户会询问咱们是否反对一些第三方的流量剖析零碎来对流量进行实时的监控与剖析。 在2021年的2月23日，亚马逊云中国区发表了VPC Traffic Mirroring的性能落地[1]，应用此性能，能够联合一些第三方的流量剖析零碎，解决客户对于流量剖析的实时性需要。在文档[2]中，列出了联合应用Suricata进行流量剖析的实例，在此篇文档中进行测试与扩大。 依据文档[3]如下测试步骤，只能在log中看到Vxlan的镜像报文，无奈对报文内内容(例如HTTP申请)进行记录与剖析：Step 1: Install the Suricata software on the EC2 instance targetStep 2: Create a traffic mirror targetStep 3: Create a traffic mirror filterStep 4: Create a traffic mirror session 依据下列配置与测试，可能胜利记录客户的HTTP申请。应用下列命令更新Suricata Rule sudo suricata-update通过查看更新后的rule，能够看到http相干的rule检测前会先应用“http $HOME_NET any -> $EXTERNAL_NET any”匹配数据报文的源目IP，$HOME_NET和$EXTERNAL_NET是在Suricata的配置文件/etc/suricata/suricata.yaml中做的定义，因而更改其配置文件，设置$HOME_NET和$EXTERNAL_NET均为any，配置后如下： HOME_NET: "any" EXTERNAL_NET: "any"因为通过Traffic Mirror镜像过去的报文是具备Vxlan封装的，因而须要Suricata对报文进行Vxlan的解封装，更改配置文件/etc/suricata/suricata.yaml使其对报文进行Vxlan的解封装，配置后如下： decoder: vxlan: enabled: true ports: $VXLAN_PORTS # syntax: '8472, 4789'更改配置文件/etc/suricata/suricata.yaml开启HTTP Log，配置后如下： - http-log: enabled: yes filename: http.log append: yes重启Suricata过程使更改后的配置失效 （须要先kill掉以后suricata过程，删除rm -rf /var/run/suricata.pid文件，而后再次运行命令“suricata -c /etc/suricata/suricata.yaml -k none -i eth0 -D”启动过程），重启过程不会删除之前曾经生成的日志.进行测试，在镜像流量的源设施上拜访www.baidu.com curl www.baidu.com 在镜像流量的指标设施上（装置了Suricata的设施）查看/var/log/suricata/http.log，能够看到申请被胜利记录： 03/15/2021-07:04:00.347144 www.baidu.com[]/[]curl/7.61.1**GET[]HTTP/1.1[]200[]2381 bytes[]172.31.27.94:39626 -> 220.181.38.15补充阐明：1.Suricata报文解决流程图 ...

简介： 近程日志是什么？具体做了哪些事件？外部是怎么实现的？本文将从 性能、架构、体验优化三个方面来介绍一下近程日志倒退过程及瞻望。阿里云 云原生利用研发平台EMAS 张月（此间） 前言当 App 公布到用户手里之后，开发者对 App 运行状态的感知就只能通过各类业务和稳定性监控了。这些监控平台会把线上问题（如解体堆栈、异样网络申请等）及业务数据采集到服务端，而后给用户提供聚合 Metrics 等 BI 数据。但这个过程很容易失落细节，不能直观反映问题产生起因，导致线上问题很难排查剖析。 可能聪慧的你会想，我把所有的日志都上报到后端不就行了？然而这样会给 App 带来很多无意义的网络耗费，也会造成比拟大的网络和存储的压力。阿里云近程日志（ https://www.aliyun.com/product/emascrash/tlog ）在这个场景下应运而生，通过将日志寄存 App 本地，须要时拉取的形式，在就义了一点实时性的状况下，解决了上报日志费流量存储，不上报日志没方法查问题的窘境。 近程日志具体在外面做了哪些事件？外部又是怎么实现的？接下来我就会从 性能、架构、体验优化 三个方面来介绍一下近程日志倒退过程，最初再聊聊咱们的瞻望。 性能如前言介绍的一样，咱们会把日志先存在 App 本地，当须要的时候再拉取上来做剖析查看。整个过程能够简略拆解成如下几步： 挪动端个性C层面实现：性能晋升，一份代码多端反对加密存储：应用非对称加密形式，日志存储上报更平安日志轮转：最长反对7天日志存储，每天最大存储 10MMMAP机制：防止缓存日志失落，晋升性能 (注：MMAP 机制是将文件间接映射成内存的操作，防止页缓存到文件的拷贝，详情可移步：https://www.cnblogs.com/huxiao-tee/p/4660352.html )后端个性近程日志的定位是异步拉取，把问题日志从挪动设施端拉回来剖析。联合不同应用场景，用户对设施精准度、拉取及时性、拉取成功率等不同偏重的特点，咱们在拉取模式和产品联动上做了不同的实际。 拉取模式精准拉取：指定设施列表举个例子，一个风和日丽的上午，你刚到公司，发现老板满脸不爽的通知你昨天晚上他 App 解体了。那摆在眼前就是两条路，要么搞定这个问题，要么“提桶跑路”。这个时候近程日志出场了，你能够纯熟的输出老板的设施Id，做一次日志拉取，查查老板 App 的日志定位起因，解决问题。 这个模式下，用户应用面临了两个体验问题： 拉取速度慢。下发拉取工作后，须要终端用户从新关上App能力实现日志上传，但这个工夫很不可控。拉取成功率低。下发拉取工作会有局部设施inactive，导致没方法承受拉取指令，导致日志无奈上传。针对这个问题，咱们在拉取上做了相干的优化，实现了智能筛选的性能。 智能筛选：指定筛选条件用户不须要指定指标设施列表，而是关怀某个或几个维度下的设施具体日志。那用户能够设定拉取的设施组合条件，零碎主动帮用户选取设施。 为了放慢设施拉取速度以及拉取成功率，近程日志在选取设施减少了如下策略： 主动筛选最近启动的设施拉取。主动调整筛选出的设施池，扩充拉取规模，最多扩充到原始规模的8倍等。联动解体数据在端上问题产生的场景中，大多数是因为解体或者异样行为。为了给与对这种场景撑持，咱们提供了解体剖析数据联动的反对，突破了「解体剖析」 和「近程日志」两个产品之间的数据孤岛，提供了问题排查的更多的可能性。 数据联动：解体设施列表通过解体剖析提供解体设施列表，能够帮近程日志间接划定待拉取设施范畴，用户更加省力，通过 EMAS 「解体剖析」中的列表页一键跳转拉取。 这个形式极大简化了用户在排查解体相干问题时选定设施列表的工作，但对于每个解体问题还是须要创立拉取日志工作。这个拉取过程还是存在一个工夫上的通畅感，这不仅会打断工程师的排查思路，也会消磨排查问题的积极性。咱们是否罢黜拉取动作，间接把解体问题对应的设施日志筹备好呢？「智能拉取」就是为了解决这个场景的问题。 智能拉取：提前拉取咱们加深了后面的数据联动，对于首现和 Top 解体问题，每天7点定时创立工作，开发同学下班的时候基本上都曾经拉取胜利了，极大的晋升了开发同学的问题排查效率。 架构 体验优化除了在内功上打磨，产品的应用体验上咱们也做了相当多的优化，也和大家分享一下。 工作音讯告诉，让你可能第一工夫感知日志上报整合工作详情与日志详情页面，查看工作日志更不便欠缺工作、设施、日志查问筛选工作工夫线透出，感知工作生命周期顶部菜单栏变侧边栏，控制台与EMAS格调对立拉取工作长久化，容错性更好。 到此，近程日志的现有的性能、架构和体验介绍就此结束了，接下来说说咱们对将来的布局。 瞻望减少上报模式目前都是通过服务端下发工作，端上接受任务上报这种「被动上报」的模式，有肯定的局限性，咱们接下来心愿对客户端在某些状况下「被动上报」日志，比方间断Crash，或者用户在App内反馈问题时上报做相应的反对。 丰盛采集数据当初咱们的日志打印仅限于用户日志，还须要反对更多的无痕埋点，记录用户操作门路和网络IO等操作，让日志数据更丰盛，可能通过日志复现用户操作流水，机器状态的变动。 更多产品联动「解体剖析」是咱们产品联动的第一站，除了解体和异样，对品质有谋求的App开发者也越发器重性能问题，毕竟「性能决定当初，性能决定将来」，后续咱们也会思考和如何将「性能剖析」产品和近程日志买通，更好的服务咱们的用户。 挪动研发平台 EMAS阿里巴巴利用研发平台 EMAS 是国内当先的云原生利用研发平台（挪动App、H5利用、小程序、Web利用等），基于宽泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），致力于为企业、开发者提供一站式的利用研发治理服务，涵盖开发、测试、运维、经营等利用全生命周期。欢送大家移步应用：https://cn.aliyun.com/product/emas

在resources目录下增加logback.xml文件 <?xml version="1.0" encoding="UTF-8"?><configuration> <springProperty name="LOG_PATH" source="logging.path" defaultValue="/home/admin/xxx/logs" /> <!--自定义控制台日志格局--> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder charset="UTF-8"> <pattern>[%d{yyyy-MM-dd HH:mm:ss.SSS}] %level [%thread] %file:%line - %msg%n</pattern> <charset>UTF-8</charset> </encoder> </appender> <!--零碎INFO级别日志-滚动记录日志--> <appender name="SYS_INFO" class="ch.qos.logback.core.rolling.RollingFileAppender"> <!--被写入的文件名，能够是绝对目录，也能够是相对目录，如果下级目录不存在会主动创立，没有默认值--> <File>${LOG_PATH}/sys_info.log</File> <!--如果是 true，日志被追加到文件结尾，如果是 false，清空现存文件，默认是true。--> <append>true</append> <!--级别过滤器（LevelFilter）,此处只打INFO级别的日志--> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>INFO</level> <!--上面2个属性示意匹配规定level的承受打印，不匹配的（即非INFO）回绝打印--> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <!-- 最罕用的滚动策略，它依据工夫来制订滚动策略，既负责滚动也负责登程滚动--> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!--设置滚动文件规定，如果间接应用 %d，默认格局是 yyyy-MM-dd--> <fileNamePattern>${LOG_PATH}/sys_info.log.%d</fileNamePattern> <!--保留30天的日志--> <maxHistory>30</maxHistory> </rollingPolicy> <encoder charset="UTF-8"> <pattern>[%d{yyyy-MM-dd HH:mm:ss.SSS}] %level [%thread] %file:%line - %msg%n</pattern> <charset>UTF-8</charset> </encoder> </appender> <!--零碎ERROR级别日志-滚动记录日志--> <appender name="SYS_ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_PATH}/sys_error.log</File> <append>true</append> <!--此处只打ERROR级别的日志--> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>ERROR</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_PATH}/sys_error.log.%d</fileNamePattern> <maxHistory>12</maxHistory> </rollingPolicy> <encoder charset="UTF-8"> <pattern>[%d{yyyy-MM-dd HH:mm:ss.SSS}] %level [%thread] %file:%line - %msg%n</pattern> <charset>UTF-8</charset> </encoder> </appender> <!--业务business-1日志--> <appender name="bs1_Appender" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_PATH}/api.log</File> <append>true</append> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>INFO</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${LOG_PATH}/api.log.%d</fileNamePattern> <maxHistory>12</maxHistory> </rollingPolicy> <encoder charset="UTF-8"> <pattern>[%d{yyyy-MM-dd HH:mm:ss.SSS}] %level [%thread] %file:%line - %msg%n</pattern> <charset>UTF-8</charset> </encoder> </appender> <!-- additivity属性为false，示意此logger的打印信息不再向下级传递(注：该值默认为true，logger的日志信息会顺次向下级传递，最高级logger为root，如果不加则至多打印2次，自身一次，root一次)--> <logger name="bs1" additivity="false" level="INFO"> <appender-ref ref="bs1_Appender"/> </logger> <!--info和error离开打印，注：ERROR > WARN > INFO > DEBUG > TRACE--> <root level="INFO"> <appender-ref ref="CONSOLE"/> <appender-ref ref="SYS_INFO"/> <appender-ref ref="SYS_ERROR"/> </root></configuration>在application.yml文件中增加日志目录 ...

作者： inkt1234 来源：https://blog.csdn.net/Linktha... 最近，在对公司容器云的日志方案进行设计的时候，发现主流的ELK或者EFK比较重，再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统，下面介绍下Loki的背景。 背景和动机当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下： 我们的监控使用的是基于prometheus体系进行改造的，prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值，alert设置metric达到某个特定的基数触发了告警，但是这些信息明显是不够的。我们都知道，k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志,举个例子：当我们的某个pod的内存变得很大，触发了我们的alert，这个时候管理员，去页面查询确认是哪个pod有问题，然后要确认pod内存变大的原因，我们还需要去查询pod的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了： 如果，这个时候应用突然挂了，这个时候我们就无法查到相关的日志了，所以需要引入日志系统，统一收集日志，而使用ELK的话，就需要在Kibana和Grafana之间切换，影响用户体验。所以 ，loki的第一目的就是最小化度量和日志的切换成本，有助于减少异常事件的响应时间和提高用户的体验 ELK存在的问题现有的很多日志采集的方案都是采用全文检索对日志进行索引（如ELK方案），优点是功能丰富，允许复杂的操作。但是，这些方案往往规模复杂，资源占用高，操作苦难。很多功能往往用不上，大多数查询只关注一定时间范围和一些简单的参数（如host、service等），使用这些解决方案就有点杀鸡用牛刀的感觉了。因此，Loki的第二个目的是，在查询语言的易操作性和复杂性之间可以达到一个权衡。 因此，Loki的第二个目的是，在查询语言的易操作性和复杂性之间可以达到一个权衡。 成本全文检索的方案也带来成本问题，简单的说就是全文搜索（如ES）的倒排索引的切分和共享的成本较高。后来出现了其他不同的设计方案如：OKlog(https://github.com/oklog/oklo...、基于网格的分布策略。这两个设计决策提供了大量的成本降低和非常简单的操作，但是查询不够方便。因此，Loki的第三个目的是，提高一个更具成本效益的解决方案。 整体架构Loki的架构如下： 不难看出，Loki的架构非常简单，使用了和prometheus一样的标签来作为索引，也就是说，你通过这些标签既可以查询日志的内容也可以查询到监控的数据，不但减少了两种查询之间的切换成本，也极大地降低了日志索引的存储。Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail, 在k8s中promtail以daemonset方式运行在每个节点中，通过kubernetes api等到日志的正确元数据，并将它们发送到Loki。下面是日志的存储架构： 读写日志数据的写主要依托的是Distributor和Ingester两个组件,整体的流程如下： Distributor一旦promtail收集日志并将其发送给loki，Distributor就是第一个接收日志的组件。由于日志的写入量可能很大，所以不能在它们传入时将它们写入数据库。这会毁掉数据库。我们需要批处理和压缩数据。Loki通过构建压缩数据块来实现这一点，方法是在日志进入时对其进行gzip操作，组件ingester是一个有状态的组件，负责构建和刷新chunck，当chunk达到一定的数量或者时间后，刷新到存储中去。每个流的日志对应一个ingester,当日志到达Distributor后，根据元数据和hash算法计算出应该到哪个ingester上面。 此外，为了冗余和弹性，我们将其复制n（默认情况下为3）次。 Ingesteringester接收到日志并开始构建chunk: 基本上就是将日志进行压缩并附加到chunk上面。一旦chunk“填满”（数据达到一定数量或者过了一定期限），ingester将其刷新到数据库。我们对块和索引使用单独的数据库，因为它们存储的数据类型不同。 刷新一个chunk之后，ingester然后创建一个新的空chunk并将新条目添加到该chunk中。 Querier读取就非常简单了，由Querier负责给定一个时间范围和标签选择器，Querier查看索引以确定哪些块匹配，并通过greps将结果显示出来。它还从Ingester获取尚未刷新的最新数据。对于每个查询，一个查询器将为您显示所有相关日志。实现了查询并行化，提供分布式grep，使即使是大型查询也是足够的。 可扩展性Loki的索引存储可以是cassandra/bigtable/dynamodb，而chuncks可以是各种对象存储，Querier和Distributor都是无状态的组件。对于ingester他虽然是有状态的但是，当新的节点加入或者减少，整节点间的chunk会重新分配，已适应新的散列环。而Loki底层存储的实现Cortex已经 在实际的生产中投入使用多年了。有了这句话，我可以放心的在环境中实验一把了。 微信搜索：【Java小咖秀】更多精彩等着您~回复手册获取博主15万字Java面试通关手册&1.4万字Linux命令实战书册~

一、ELK服务架构解析 （1）收集记录日志流程思考//备注：思考如果我们自己搭建一个日志收集平台应该如何操作和搭建？具体会有哪些动作？（1）目的：将线上的服务器日志不断的收集到一个统一的平台，并且提供一个可视化的界面能对所有的日志进行索引查询（2）架构拆解之需要哪些步骤： 线上服务器日志收集工具----> 统一的日志存储平台----> 日志分析工具 ----> 可视化界面（3）以上步骤，对应ELK就是: 「L代表」logstash[或者filebeat]：日志收集工具，部署在线上服务器中，对相关的yml配置文件进行配置可以对日志进行收集并传输到统一的日志存储平台，其中filebeat更轻量，一般使用filebeat 「E代表」Elasticsearch：日志分析工具，用来对所有的日志创建各种索引进行搜索等，也是我们常说的搜索引擎 「K代表」Kibana：可视化界面，用来对日志进行可视化展示和搜索，相当于一个管理界面 （2）ELK架构需要安装的服务工具 工具名称作用部署位置配置文件备注filebeat收集日志产生日志的线上服务器，比如线上有两台web服务器，那么需要在两台web服务器都部署filebeatfilebeat.yml轻量，推荐Logstash收集日志产生日志的服务器上pipelines.ymllogstash.yml和filebeat比较更重，线上服务器本身运行web服务，部署logstash更耗费线上资源，不推荐elasticsearch日志分析工具，搜索引擎filebeat或者logstash的输出服务器elasticsearch.yml能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎，使其具有复杂的搜索功能Kibana日志可视化平台配合elasticsearch使用kibana.yml通常与 Elasticsearch 配合使用，对其中数据进行搜索、分析和以统计图表的方式展示各配置文件解析（1）Filebeat配置文件主要配置解析 //filebeat配置文件filebeat.yml解析 filebeat.inputs: - type: log # Change to true to enable this input configuration. enabled: true # Paths that should be crawled and fetched. Glob based paths. paths: //这一项配置，代表要收集日志的目录 - /opt/nginx-1.14.0/logs/stars/star.access.log output.logstash: # The Logstash hosts hosts: ["10.3.0.115:5401"] //该项是日志收集以后到一个统一平台，作为输出的IP地址 # Configure processors to enhance or manipulate events generated by the beat. processors: - add_host_metadata: ~ - add_cloud_metadata: ~ - add_docker_metadata: ~ - add_kubernetes_metadata: ~（2）logstash配置文件主要配置解析【主要四种插件，inputs,codecs,filters,outputs。】 ...

<property name="PATTERN">%d{yyyy-MM-dd HH:mm:ss} [%p] [%-40.40c{2.}] [%X{ip}] [%X{id}] %msg%n</property>模式转换字符：下表说明了以上模式使用的字符和所有其他字符，可以在自定义模式中使用： 转换字符表示的意思c用于输出的记录事件的类别。例如，对于类别名称”a.b.c” 模式 %c{2} 会输出 “b.c”C用于输出呼叫者发出日志请求的完全限定类名。例如，对于类名 “org.apache.xyz.SomeClass”, 模式 %C{1} 会输出 “SomeClass”.d用于输出的记录事件的日期。例如， %d{HH:mm:ss,SSS} 或 %d{dd MMM yyyy HH:mm:ss,SSS}.F用于输出被发出日志记录请求，其中的文件名l用于将产生的日志事件调用者输出位置信息L用于输出从被发出日志记录请求的行号m用于输出使用日志事件相关联的应用程序提供的消息M用于输出发出日志请求所在的方法名称n输出平台相关的行分隔符或文字p用于输出的记录事件的优先级r用于输出毫秒从布局的结构经过直到创建日志记录事件的数目t用于输出生成的日志记录事件的线程的名称x用于与产生该日志事件的线程相关联输出的NDC（嵌套诊断上下文）X在X转换字符后面是键为的MDC。例如 X{clientIP} 将打印存储在MDC对键clientIP的信息%文字百分号 %%将打印％标志格式修饰符：默认情况下，相关资料原样输出。然而，随着格式修饰符的帮助下，可以改变最小字段宽度，最大字段宽度和对齐。 下表涵盖了各种各样的修饰符的情况： Format modifierleft justifyminimum widthmaximum width注释%20cfalse20none用空格左垫，如果类别名称少于20个字符长%-20ctrue20none用空格右垫，如果类别名称少于20个字符长%.30cNANONE30从开始截断，如果类别名称超过30个字符长%20.30cfalse2030用空格左侧垫，如果类别名称短于20个字符。但是，如果类别名称长度超过30个字符，那么从开始截断。%-20.30ctrue2030用空格右侧垫，如果类别名称短于20个字符。但是，如果类别名称长度超过30个字符，那么从开始截断。

应用程序日志是由软件应用程序记录的事件文件， 它一般包含错误，信息事件和警告。一个良好的日志系统有助于快速发现问题，定位问题，同时也为业务分析起到一定的作用。 传统ELK系统ELK系统是目前比较流行的日志解决方案，由Elasticsearch、Logstash、Kibana组成，目前三个组件都归属于Elastic。 Elasticsearch是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎，具有HTTP Web接口和无模式JSON文档。Elasticsearch是用Java开发的，并在Apache许可证下作为开源软件发布。 自2010年发布以来，Elasticsearch已迅速成为最受欢迎的搜索引擎，常用于日志分析，全文搜索和业务分析等业务场景。 Logstash 将日志收集后发送到Elasticsearch中进行存储，用户访问Kibana提供的UI界面查询数据。 Choerodon中的日志系统总览和ELK类似，Choerodon选用了Elasticsearch存储日志数据，并由Kibana展示数据。Choerodon平台运行在Kubernetes平台之上，同时也管理多个Kubernetes集群，为了让日志系统尽可能的不影响业务系统，Choerodon使用了比Logstash更轻量的由C语言编写的fluent bit替代采集端工具Logstash。fluent bit通过Deamonset的方式运行在Kubernetes集群中的每一个可调度的节点上，实时采集日志，发送到Elasticsearch中，一般情况下，从日志产生到Kibana中可以查看到的延迟不超过1秒钟。精简结构图如下： 先看一下查看界面： 通过搜索关键字error查询含有该关键字的日志，界面显示最近15分钟gateway-helper服务出现了三次error的日志信息，列表中为该日志的缩略信息，可以点击日志前面的小箭头展开查看完整的信息。 展开之后就可以看到更加详细的信息了。 PS：多行展示官方的fluent bit截止目前暂未良好的支持docker中的json-file日志，建议使用Choerodon定制fluent bit。 Fluent bit vs FluentdFluentd和Fluent Bit项目均由Treasure Data创建和赞助，旨在解决日志的收集，处理和交付问题。 两个项目都有很多相似之处，Fluent Bit完全基于Fluentd架构和一般设计的设计和经验。选择使用哪一个取决于最终需求，从架构角度可以考虑： Fluentd是日志收集器，处理器和聚合器，使用Ruby和C构建。Fluent Bit是一个日志收集器和处理器，它没有像Fluentd一样强大的聚合功能。在Choerodon日志方案聚合功能由Elasticsearch提供。Fluent bit一般情况下占用内存要仅为fluentd十分之一以下。类似于Fluent bit的组件还有很多如Filebeat等，Choerodon也在关注各主流组件的更新，选择最合适的日志采集端工具。 如何自动收集日志一般在采集日志的时候，为了更容易分析日志，需要将日志进行解析。下面的这个图中将Java应用的一条日志解析为level,class,processid和msg四个部分： 解析日志需要指定解析规则，Choerodon部署界面可以为应用配置解析规则，当配置了解析规则后即表示该应用的日志需要按照配置的规则收集，部署界面如下图所示： 通过mysql这个解析规则解析该应用的日志，目前Choerodon日志解决方案中默认提供了docker、mysql、tomcat、springboot和nginx的日志解析规则，如果你认为需要添加其他通用的日志解析规则欢迎到Choerodon社区中建议。 在Fluent-bit中可以配置通配符"*”来收集匹配规则的日志，但是很多时候开发者希望在部署应用时指定是否收集日志。在Choerodon平台中，应用是运行在Kubernetes平台之上的，所以开发者可以通过给应用的部署集添加标签来表示需不要收集日志，再通过一个程序去读取标签的内容，自动修改Fluent-bit的配置就可以随心的控制是否需要收集日志了。如果需要默认收集所有应用的日志，排除部分日志可以使用Fluent-bit提供的 fluentbit.io/exclude注解。 在日志中添加集群相关的信息Choerodon的服务运行在Kubernetes集群中，如果能够在查看日志的时候也能看到日志来自哪个服务器，属于哪个Pod就能够更快的定位和查找问题。 Fluent bit提供了Kubernetes的filter，通过赋予Fluent bit查询权限，它就能够自动的为每条日志附加集群的相关信息。 如何告警收集日志之后开发者需要对某个关键字出现的次数进行告警，如Exception这个关键字在某服务中一分钟出现了5次以上，需要将这个消息通知给特定的人员。 在这之前大家先来了解一下Choerodon中的监控方案： 应用监控数据经Prometheus采集处理之后展示在Grafana中，告警信息通过Alertmanager发送给用户。因为在监控方案中已经有可用的告警机制，开发者只需要将日志系统中的内容转换为Prometheus可以采集的指标数据即可使用监控方案中的告警机制。 Elastalert是用Python编写的Elasticsearch告警工具，通过配置一定时间间隔查询elasticsearch数据库，对比预设规则达到告警的目的，Choerodon可以通过简单的改造elastalert实现将elastalert查询的结果转换为Prometheus的数据格式供Prometheus拉取。改造步骤分为以下几个部分： 引入prometheusSDK：prometheus提供了Python的SDK,简单的引入之后应用就具有了可以被监控的特性，可以选择监听指定端口已提供监控数据。埋点：将更新监控数据的操作置于elastalert每次执行查询完成后已更新监控数据即可。目前Choerodon正在用Golang开发新的日志监控工具，得益于Golang的特性，新的日志监控工具将以更低的内存消耗，更低的cpu占用和更稳定的运行状态为日志监控提供支持。 使用Choerodon认证登录Kibana如上所示，Kibana作为日志查看界面，如果使用社区版Kibana是没有权限校验的，会存在一定风险，希望授权用户才能访问日志查询界面。为此Choerodon设计开发了一个认证代理服务，将无权限控制的Kibana放置于认证代理的后端，只有通过了认证，才能访问到Kibana的界面。如下图所示： 效果图： 现在，你已经了解Choerodon的日志方案，接下来就可以跟随着Choerodon官网部署尝试一下吧。 参考文献： https://zh.wikipedia.org/wiki/Elasticsearchhttps://docs.fluentbit.io/manual/about/fluentd_and_fluentbit本篇文章出自Choerodon猪齿鱼社区董文启。