关于日志分析:日志服务运维观测能力助力新零售容器化部署升级

河北媛福达商贸团体成立于2017年,从起初繁多的传统批发企业倒退至现在集生产、物流、种植、餐饮、电商+实体批发为一体的新批发团体。现有五大业务板块(连锁超市、线上商城、加工生产、迷信种植、文化餐饮)。媛福达主营业务以订单交易为外围,对系统的稳定性、可靠性要求高,须要全面无死角、高效灵便的运维反对。在运维层面次要通过各个层级和各个功能模块的日志零碎来监测零碎运行状况,定位问题,优化性能。零碎晚期利用开源ELK零碎的形式构建整个运维零碎,将日志会集到ELK零碎提供对立检索。 残缺内容请点击下方链接查看: https://developer.aliyun.com/article/1195412?utm_content=g_10... 版权申明:本文内容由阿里云实名注册用户自发奉献,版权归原作者所有,阿里云开发者社区不领有其著作权,亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容,填写侵权投诉表单进行举报,一经查实,本社区将立即删除涉嫌侵权内容。

May 8, 2023 · 1 min · jiezi

关于日志分析:日志服务运维观测能力助力新零售容器化部署升级

河北媛福达商贸团体成立于2017年,从起初繁多的传统批发企业倒退至现在集生产、物流、种植、餐饮、电商+实体批发为一体的新批发团体。现有五大业务板块(连锁超市、线上商城、加工生产、迷信种植、文化餐饮)。 媛福达主营业务以订单交易为外围,对系统的稳定性、可靠性要求高,须要全面无死角、高效灵便的运维反对。在运维层面次要通过各个层级和各个功能模块的日志零碎来监测零碎运行状况,定位问题,优化性能。零碎晚期利用开源ELK零碎的形式构建整个运维零碎,将日志会集到ELK零碎提供对立检索。 容器部署维服务架构,对系统运维提出更高要求媛福达整体的IT零碎基于容器的微服务架构进行构建,因为容器具备可灵便开启敞开的特点,随着业务的倒退,运维压力也呈指数增大。原有运维架构已无奈满足高频次的开关容器带来的冲击,因而媛福达须要一套牢靠的运维零碎保障业务的稳定性。在云原生技术的飞速推动下,云上资源愈发简单,架构更加多样,从最开始的服务器、数据库,到前面的负载平衡、WAF、CDN、OSS等产品的联合应用,急需一个对立的监测平台来洞察云上资源的运行状况。因为媛福达属于批发行业,线上与线下订单量会随节日、促销流动、爆品等因素大幅晋升, 因而在特定工夫内C端用户访问量和订单量会有很大稳定,因而媛福达须要一个可观测的平台来实时预测业务的变化趋势,以及时调整云上资源的大小,优化用云老本。一站式可观测运维解决方案,轻松缓解一劳永逸的零碎压力传统运维IT零碎的运维老本过高、压力过大,采纳容器容器的微服务架构之后,其轻量化的个性使得运维更加灵便高效。相较于传统运维,这种形式能够实现更疾速的部署与交付。但随着媛福达业务的增长,容器数量也逐步减少,且随同着高频次容器开关次数,传统利用开源ELK零碎的形式构建整个运维零碎的形式已无奈满足一劳永逸的业务需要。 因而阿里云为其提供了一站式云原生可观测运维解决方案,该计划基于 SLS 云原生可观测平台实现,以大数据源为撑持,兼容开源规范,可实现多场景适配 AI 算法,进行大规模数据处理剖析。是阿里云针对企业级大数据运维场景推出的解决方案,帮忙企业在日常运维工作中轻松实现异样检测、根因剖析、秒级响应以及实时预测。 针对媛福达面对的性能瓶颈问题,阿里云云原生可观测运维解决方案为其提供了免运维、高性能的日志数据存储、查问和建模服务。可反对PB级数据实时查问与剖析,提供10多种查问运算符、10多种机器学习函数、100多个SQL函数。帮忙媛福达在节日流动、电商大促等高并发、大流量的场景下轻松实现日志数据的查问。即便呈现突发性的问题,也能疾速查问问题日志,迅速定位问题点,极大水平晋升用户的产品应用体验。 且因为媛福达大部分零碎曾经迁徙上云,联合不同的业务需要,往往须要搭配各种不同类型的云产品,由此带来的老本治理与资源管理难度会进一步晋升。阿里云云原生可观测运维解决方案,依靠于日志服务SLS一站式的观测能力,可无缝接入各类云产品,实现资源与应用老本一站式的可视化治理,自定义图表、数据实时监控、数据异样报警等能力,帮忙媛福达对业务的异样数据进行监管告警,及时发现异常变动,实现最快的零碎排障与最优的云产品资源应用布局。 客户证言阿里云的SLS,为咱们提供了高质量、高容量的日志存储服务,以及高效率的日志查问剖析服务。SLS的一站式服务,操作简略,直观明了,对于咱们产品线上问题可能随时疾速的溯源,极大的升高了服务器存储资源和人力资源的投入老本。同时领有从多维度统计分析日志的性能,对咱们的业务晋升也有很大帮忙。 原文链接 本文为阿里云原创内容,未经容许不得转载。

April 25, 2023 · 1 min · jiezi

关于日志分析:新鲜出炉|基于深度学习的运维日志领域新进展

作者:云智慧算法工程师 Hugo Guo 运维日志畛域钻研方向次要蕴含异样日志检测、日志模式解析、日志内容分类、日志告警等。本篇文章介绍了热门异样检测模型 DeepLog、A2Log 等模型,以及云智慧自研模型 Translog 等。与此同时,在文章最初介绍了将来基于深度学习的运维日志畛域次要钻研方向。 日志钻研概述日志工作与数据日志是运维畛域中的必不可少的一种半结构化数据类型,基于此发展的钻研工作也多种多样。 日志数据实时处理次要蕴含以下几方面: Log Compression:在运行时压缩软件日志。Log Parsing:从软件日志中主动提取事件模板和要害参数。Log Mining:进步零碎的可靠性,次要关注异样检测。 日志模式解析海量日志数据之间语义相似性较高,理论需要须要将日志示意化。因而学者冀望对日志提取出固定的模版以求代表整个日志数据库。 下方为四个经典的日志模式解析算法: Drain(基于树结构类似度)Spell(最长公共子序列)AEL (常数和变量的产生频率)IPLoM(迭代分区策略,依据音讯长度、令牌地位和映射关系等)下图为日志模版提取过程,从上到下顺次是原始日志,解析后的日志模版。 学术前沿工作分享DeepLogDeepLog 是日志深度学习开山之作,采纳LSTM编码提取好模板的日志并为给定序列中的下一个模板提供了一个具备概率的排序输入,以此进行异样检测。 A2LogA2Log 采纳无监督的形式去寻找失常和异样之间的boundary,基于Attention机制和最新的Transformer框架,对失常的日志输入得分依据阈值去判断boundry。 LogRobustLogRobust 双向LSTM+Attention进行编码分类,对原始日志的模版进行word vector的向量化送入模型进行分类。 HitAnomalyHitAnomaly 是对于日志模版和参数别离采纳Transformer进行编码。 LogsyLogsy 测试数据来源于新的零碎,同时最初将异样分数退出思考。 自研模型分享TranslogTranslog 首次思考多起源、资源不对齐的日志源异样检测。是基于 Transfer learning 和 Transformer 的全新框架 Pretraining 和 Tuning 的学习范式,通过 Translog 耗费可升高为原来的5%,然而成果达到 SOTA。 AdapterAdapter 的构造非常简略,像一个适配器为大模型的常识流动进行贯通。 下图右所示的是不同的日志源有着雷同的异样问题,为迁徙学习提供可能性。 云智慧将 Adapter 在三个公开数据集上进行测试,最终 Adapter 算法都取得了SOTA。同时 Adapter 的参数量减少了将近百分之95% 下图左方的试验阐明预训练的形式会比间接从头开始训练更快收敛,同时会在较少的step下失去更高的F1分数。下图右方试验阐明不同数据源的预训练的模型会产生不同的成果,发现BGL的预训练模型成果更好。 下图试验阐明 Translog 在 low-resource 会体现出比失常的更好的后果。阐明对于其余散布不平衡的日志源咱们的模型也会有肯定较好的成果。 ...

November 25, 2022 · 1 min · jiezi

关于日志分析:日志异常检测准确率低一文掌握日志指标序列分类

背景目前,日志异样检测算法采纳基于工夫序列的办法检测异样,具体为:日志结构化->日志模式识别->工夫序列转换->异样检测。异样检测算法依据日志指标时序数据的周期性检测出历史新增、时段新增、时段突增、时段突降等多种异样。 然而,在理论中,日志指标时序数据并不都具备周期性,或具备其余散布特色,因而仅依据周期性进行异样检测会导致误报率高、准确率低等问题。因而如果在日志异样检测之前,首先对日志指标时序数据进行分类,不同类型数据采纳不同办法检测异样,能够无效进步准确率,并升高误报率。 日志指标序列的类型日志指标序列分为时序数据与日志指标数据两大类: 时序数据: 蕴含安稳型、周期型、趋势型、阶跃型。 日志指标数据: 蕴含周期型、非周期型。 工夫序列分类算法工夫序列分类是一项在多个畛域均有利用的通用工作,指标是利用标记好的训练数据,确定一个工夫序列属于事后定义的哪一个类别。 工夫序列分类不同于惯例分类问题,因为时序数据是具备程序属性的序列。 工夫序列分为传统工夫序列分类算法与基于深度学习的工夫序列分类算法。传统办法又依据算法采纳的用于分类的特色类型不同,分为全局特色、部分特色、基于模型以及组合办法4大类。基于深度学习的工夫序列算法分为生成式模型与判别式模型两大类。本文次要对传统工夫序列分类算法进行介绍。 传统工夫序列分类算法基于全局特色的分类算法全局特色分类是将残缺工夫序列作为特色,计算工夫序列间的相似性来进行分类。分类办法有通过计算不同序列之间间隔的远近来表白工夫序列的相似性以及不同间隔度量办法 + 1-NN(1-近邻)。次要钻研序列相似性的度量办法。 工夫域间隔问题场景形容: 如下图所示,问题场景是一个语音辨认工作。该工作用数字示意音调高下,例如某个单词发音的音调为1-3-2-4。两个人说同一单词时,因为音节的发音拖长,会造成不同的发音序列 前半部分拖长,发音:1-1-3-3-2-4 后半局部拖长,发音:1-3-2-2-4-4 在采纳传统欧式间隔,即点对点的形式计算发音序列间隔时,间隔之和如下: 欧式间隔 = |A(1)-B(1)| + |A(2)-B(2)| + |A(3)-B(3)| + |A(4)-B(4)| + |A(5)-B(5)| + |A(6)-B(6)| =6_x0001_ 算法原理: 如果咱们容许序列的点与另一序列的多个间断的点绝对应(即,将这个点所代表的音调的发音工夫缩短),而后再计算对应点之间的间隔之和,这就是dtw算法。dtw算法容许序列某个时刻的点与另一序列多个间断时刻的点绝对应,称为工夫规整(Time Warping)。如下图所示,语音辨认工作的dtw间隔如下: dtw间隔= |1-1| + |1-1| + |3-3| + |3-3| + |2-2| + |2-2| + |4-4| + |4-4| = 0 dtw计算出的间隔为0,由此代表两个单词发音统一,与理论状况相符。 算法实现: dtw算法实现包含计算两个序列各点之间间隔形成矩阵以及寻找一条从矩阵左上角到右下角的门路,使得门路上的元素和最小两个次要步骤。间隔矩阵如下图所示,矩阵中每个元素的值为两个序列对应点之间的间隔。DTW算法将计算两个序列之间的间隔,转化为寻找一条从间隔矩阵。左上角到右下角的门路,使得门路上的元素和最小。实现要点如下: 转化为动静布局的问题(DP);<!----> 因为寻找所有门路太耗时,须要增加门路数量限度条件(能够等效为寻找矩阵横纵坐标的差的容许范畴,即warping window)。 差分间隔法差分间隔法是计算原始工夫序列的一阶微分,而后度量两个工夫序列的微分序列的间隔,即微分间隔。差分法将微分间隔作为原始序列间隔的补充,是最终间隔计算函数的重要组成部分。 对于一个工夫序列t=(t1, t2, …,tm),其一阶微分计算公式如(2-1)所示,二阶微分计算公式如(2-2)所示,更高阶的微分计算形式顺次类推。 差分间隔法将位于工夫域的原工夫序列和位于差分域的一阶差分序列相结合,晋升分类成果。钻研方向次要是如何将原序列和差分序列正当联合。 基于部分特色的分类算法将单条工夫序列中的一部分子序列作为特色,用于工夫序列分类。次要有以下特点: 关键在于寻找可能辨别不同类的部分特色;因为子序列更短,因而构建的分类器速度更快;但因为须要寻找部分特色,须要肯定的训练工夫。 ...

November 18, 2022 · 1 min · jiezi

关于日志分析:日志导致线程Block的这些坑你不得不防

研发人员在我的项目开发中不可避免地要应用日志,通过它来记录信息和排查问题。Apache Log4j2提供了灵便且弱小的日志框架,尽管上手比拟快,但稍有不慎也非常容易踩“坑”。本文介绍了美团对立API网关服务Shepherd在实践中所踩过的对于日志导致线程Block的那些“坑”,以及咱们如何从日志框架源码层面进行剖析和解决问题的过程,并在最初给大家分享一些对于日志避“坑”的实践经验,心愿能给大家带来一些帮忙。1. 前言日志对程序的重要性显而易见。它很“大”,咱们在我的项目中常常通过日志来记录信息和排查问题,相干代码随处可见。它也很“小”,作为辅助工具,日志应用简略、上手快,咱们通常不会破费过多精力耗在日志上。但看似不起眼的日志也暗藏着各种各样的“坑”,如果使用不当,它不仅不能帮忙咱们,反而还可能升高服务性能,甚至拖垮咱们的服务。 日志导致线程Block的问题,置信你或者曾经遇到过,对此应该深有体会;或者你还没遇到过,但不代表没有问题,只是可能还没有触发而已。本文次要介绍美团对立API网关服务Shepherd(参见《百亿规模API网关服务Shepherd的设计与实现》一文)在实践中所踩过的对于日志导致线程Block的那些“坑”,而后再分享一些避“坑”教训。 2. 背景API网关服务Shepherd基于Java语言开发,应用业界赫赫有名的Apache Log4j2作为次要日志框架,同时应用美团外部的XMD-Log SDK和Scribe-Log SDK对日志内容进行解决,日志解决整体流程如下图1所示。业务打印日志时,日志框架基于Logger配置来决定把日志交给XMDFile解决还是Scribe解决。其中,XMDFile是XMD-Log外部提供的日志Appender名称,负责输入日志到本地磁盘,Scribe是Scribe-Log外部提供的日志Appender名称,负责上报日志到近程日志核心。 随着业务的快速增长,日志导致的线程Block问题愈发频繁。比方调用后端RPC服务超时,导致调用方大量线程Block;再比方,业务外部输入异样日志导致服务大量线程Block等,这些问题重大影响着服务的稳定性。因而,咱们联合我的项目在过来一段时间裸露进去的各种因为日志导致的线程Block问题,对日志框架存在的稳定性危险因素进行了彻底的排查和修复,并在线下、线上环境进行全方位验证。在此过程中,咱们总结了一些日志应用相干的实践经验,心愿分享给大家。 在进入注释前,首先介绍我的项目过后的运行环境和日志相干配置信息。 JDK版本java version "1.8.0_45"Java(TM) SE Runtime Environment (build 1.8.0_45-b14)Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)日志依赖版本<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.7</version></dependency><dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.7</version></dependency><dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.7</version></dependency>日志配置文件<?xml version="1.0" encoding="UTF-8"?><configuration status="warn"> <appenders> <Console name="Console" target="SYSTEM_OUT" follow="true"> <PatternLayout pattern="%d{yyyy/MM/dd HH:mm:ss.SSS} %t [%p] %c{1} (%F:%L) %msg%n" /> </Console> <XMDFile name="ShepherdLog" fileName="shepherd.log"/> <!--XMDFile异步磁盘日志配置示例--> <!--默认按天&按512M文件大小切分日志,默认最多保留30个日志文件。--> <!--留神:fileName前会主动减少文件门路,只配置文件名即可--> <XMDFile name="LocalServiceLog" fileName="request.log"/> <Scribe name="LogCenterSync"> <!-- 在指定日志名方面,scribeCategory 和 appkey 两者至多存在一种,且 scribeCategory 高于 appkey。--> <!-- <Property name="scribeCategory">data_update_test_lc</Property> --> <LcLayout/> </Scribe> <Async name="LogCenterAsync" blocking="false"> <AppenderRef ref="LogCenterSync"/> </Async> </appenders> <loggers> <AsyncLogger name="com.sankuai.shepherd" level="info" additivity="false"> <AppenderRef ref="ShepherdLog" level="warn"/> <AppenderRef ref="LogCenterAsync" level="info"/> </AsyncLogger> <root level="info"> <!--Console日志是同步、阻塞的,举荐只在本地调试时应用,线上将该配置去掉--> <!--appender-ref ref="Console" /--> <appender-ref ref="LocalServiceLog"/> <appender-ref ref="LogCenterAsync"/> </root> </loggers></configuration>3. 踩过的坑本章节次要记录我的项目过来一段时间,咱们所遇到的一系列日志导致的线程Block问题,并一一深入分析问题根因。 ...

August 1, 2022 · 19 min · jiezi

关于日志分析:高效实战|航空业海量日志数据的智能化分析

对于以后航空业面临的海量实时业务数据监测与剖析挑战,云智慧推出了一种基于业务系统日志数据,应用实时流式数据采集、大数据处理和人工智能技术实现海量日志数据智能化剖析的解决方案,帮忙IT运维人员实时、动静发现业务及IT零碎存在的故障和异样,疾速定位问题本源,保障航司业务继续、稳固和高效运行。 挑战与需要随着航空及上下游服务产业链的疾速倒退,零碎多、架构简单、新旧业务零碎长期共存,继续产生的海量日志数据不足无效的解决伎俩,对IT运维和经营带来极大的危险与挑战。 以民航为例,旅客抉择飞机出行须要经验订票、值机、登机等一系列流程,每种业务解决都要逾越多个平台的利用零碎,每个零碎都会实时输入日志数据记录以后利用运行状况,上述流程中任何一个利用的故障或者性能问题都会影响乘客出行。 如何实时理解业务的整体运行状态,如何基于海量、实时的利用日志剖析疾速确定业务运行异样及潜在危险,如何依据业务量变动动静确定业务异样规范,如何针对以后业务中的异常情况及时预警,如何实现日志数据与其余运维监控数据的交融剖析和查问,疾速、精确定位业务及零碎的故障,这都是日志智能剖析平台须要解决的难题。 云智慧日志智能剖析解决方案及平台架构云智慧海量日志智能剖析解决方案包含系统日志数据的实时采集、传输、集群化的音讯队列、预处理组件及实时流式大数据处理,实现日志数据的解析、转换、脱敏、业务逻辑解决后,以结构化数据保留在分布式存储系统中,而后调用算法集之中的一种或多种算法组合进行多场景的智能剖析、告警及可视化展现,同时提供数据API满足其它数据深刻开掘和摸索需要。 海量日志智能化剖析平台架构如下图所示: 计划特色和劣势云智慧日志智能化剖析平台解决方案为航空业务运行的连续性、用户体验的晋升和业务的高效运维提供了牢靠的技术撑持,此计划具备如下劣势: 丰盛的日志数据实时采集 反对自有高性能采集器,兼容支流开源数据采集器、灵便程度扩大的数据接入接口,疾速接入流式数据。超高的吞吐量和极小的响应工夫,数据接入即可秒级查问。高性能、动静扩大数据处理平台。 内置数十种解决组件,反对可视化解决pipeline及单步处理结果验证、处理结果采纳列式存储、线性存储扩大。平台具备实时流式数据处理能力,满足航空业海量日志数据实时处理和智能剖析的严格要求。 反对依据数据量进行程度伸缩,数据处理能力:40T/天,EPS:130万/秒。反对多个节点同时写入,写入速度:单个节点:60万条/秒。同等条件下,写入速度比Elasticsearch 快10倍以上。多场景智能剖析平台能力 算法平台基于最新架构和人工智能算法,具备弱小的智能化剖析能力,为下层业务提供算法撑持和扩大。内置多个智能剖析场景,包含日志智能搜寻及上下文剖析、日志模式自动识别、基于算法的智能异样检测、智能告警及指标告警对接、日志与利用性能监控、根底监控数据的交融关联剖析等。计划价值基于海量日志数据的云智慧智能日志剖析计划曾经在航空、金融、能源等行业的智能运维我的项目中胜利施行,实践证明此平台能给行业客户带来显著的改善和晋升: 实现离散日志的对立采集、解决、存储、归档以及查问,极大晋升日志治理和剖析的便捷性。基于实时日志数据智能剖析帮忙业务人员及时掌控业务运行状态,疾速发现业务运行的异样并及时报警,缩小业务中断工夫。基于业务日志数据、利用性能监控数据、根底资源监控数据的交融剖析,实现简单线上业务及零碎问题起因的疾速定位,晋升简单问题解决的效率。客户案例实战某航空企业的主营业务是面向航司及上下游服务商,提供业务解决、电子分销、结算清理等服务,当呈现性能迟缓或中断时,现有监控零碎无奈无效定位故障和异样。 针对此用户需要,云智慧为该企业构建了基于海量实时业务日志数据的业务运维智能剖析平台,通过对业务数据的实时采集、解决、多维度智能剖析,及时发现零碎业务层面异常情况,加强该航空客户业务预警、故障诊断与智能剖析能力。此平台屡次提前发现业务解决响应工夫变长、业务指令交互错误率减少等故障前兆。基于智能剖析算法对行将产生的异样作出预测和及时告警,从而无效防止故障的业务危险。 总结和瞻望云智慧日志智能剖析平台基于AIOps策略,交融根底资源监控、利用性能监控、用户体验监控等多维度运维数据和人工智能剖析算法,可能及时发现业务经营中潜在危险,辅助管理人员作出精确判断和决策,实现对业务经营衰弱及将来发展趋势的继续洞察,加强企业外围竞争力。 开源福利云智慧已开源数据可视化编排平台 FlyFish 。通过配置数据模型为用户提供上百种可视化图形组件,零编码即可实现合乎本人业务需要的炫酷可视化大屏。 同时,飞鱼也提供了灵便的拓展能力,反对组件开发、自定义函数与全局事件等配置, 面向简单需要场景可能保障高效开发与交付。 点击下方地址链接,欢送大家给 FlyFish 点赞送 Star。参加组件开发,更有万元现金等你来拿。 GitHub 地址: https://github.com/CloudWise-OpenSource/FlyFish Gitee 地址:https://gitee.com/CloudWise/fly-fish 超级体验官流动: http://bbs.aiops.cloudwise.com/d/712-flyfish 万元现金流动: http://bbs.aiops.cloudwise.co... 微信扫描辨认下方二维码,备注【飞鱼】退出AIOps社区飞鱼开发者交换群,与 FlyFish 我的项目 PMC 面对面交换~

July 13, 2022 · 1 min · jiezi

关于日志分析:别在-Java-代码里乱打日志了这才是打印日志的正确姿势

我的公众号:MarkerHub,Java网站:https://markerhub.com更多精选文章请点击:Java笔记大全.md 小Hub领读:不同级别的日志应该辨别应用,另外用 [] 进行参数变量隔离。 西格玛的博客http://t.cn/E9BkD7a应用 slf4j 应用门面模式的日志框架,有利于保护和各个类的日志解决形式对立实现形式对立应用: Logback 框架打日志的正确形式 什么时候应该打日志 当你遇到问题的时候,只能通过 debug 性能来确定问题,你应该思考打日志,良好的零碎,是能够通过日志进行问题定为的。当你碰到 if…else 或者 switch 这样的分支时,要在分支的首行打印日志,用来确定进入了哪个分支常常以性能为外围进行开发,你应该在提交代码前,能够确定通过日志能够看到整个流程根本格局 必须应用参数化信息的形式: logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);对于 debug 日志,必须判断是否为 debug 级别后,才进行应用: if (logger.isDebugEnabled()) { logger.debug("Processing trade with id: " +id + " symbol: " + symbol);}不要进行字符串拼接, 那样会产生很多 String 对象,占用空间,影响性能。 反例 (不要这么做): logger.debug("Processing trade with id: " + id + " symbol: " + symbol);应用 [] 进行参数变量隔离 如有参数变量,应该写成如下写法: logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);这样的格局写法,可读性更好,对于排查问题更有帮忙。 不同级别的应用 ERROR: 基本概念 影响到程序失常运行、以后申请失常运行的异常情况: 关上配置文件失败所有第三方对接的异样 (包含第三方返回错误码)所有影响性能应用的异样,包含: SQLException 和除了业务异样之外的所有异样 (RuntimeException 和 Exception)不应该呈现的状况: ...

March 22, 2021 · 2 min · jiezi

问题发现定位

问题发现定位平台功能点需要全面,实现大多基于日志(收集多KAFKA,分布式存储),日志检索(多采用ES)。链路分析再次基础上做采样聚合,接口级别的非采样在监控中做(时间流存储,监控报警阈值模型智能预测等),日志针对性做些细粒度的链路分析。技术涉及不多,主要是日志压缩和索引的建设。功能点成体系就好。本文重点关注这个。更多工程内容见:https://segmentfault.com/a/11... 日志规范。定则规范全链路传递1.nginx traceid当前由几部分组成:(nginx的ip) + (生成的时间) + (生成id的nginx的启动时间 + 生成id的nginx的进程号)+(循环自增id + 末两位固定02)nginx扩展+http header传递2.thrift利用thrift 0号位空缺作为header使用3.mq ?? 问题发现:1.odin实时监控,阈值报警。(接口维度,机器维度)2.woater实时监控,智能报警3.srm灭火图/上线事件监控4.安全扫描 问题定位5.故障分析平台(全链路故障点)6.问题分析平台(搜索:ES)kafka+ES详细日志查询:大量debug/trace等日志。取代机器+grep:ES获取机器索引时间+日志压缩/解压缩,时间定位查询7.性能分析(抽样) 业务评估 1.机器调用关系2.服务依赖关系(静态),次数(统计)链路分析,延时(采样平均),调用次数(静态,动态采样)3.模块性能分析(采样统计)4.专项(mysql,定位到代码和人) 成本管理1.资源成本统计2.实时资源占用监控 整体解决思路

May 14, 2019 · 1 min · jiezi

Kubernetes Ingress 日志分析与监控的最佳实践

摘要: Ingress主要提供HTTP层(7层)路由功能,是目前K8s中HTTP/HTTPS服务的主流暴露方式。为简化广大用户对于Ingress日志分析与监控的门槛,阿里云容器服务和日志服务将Ingress日志打通,只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。前言目前Kubernetes(K8s)已经真正地占领了容器编排市场,是默认的云无关计算抽象,越来越多的企业开始将服务构建在K8s集群上。在K8s中,组件通过Service对外暴露服务,常见的包括NodePort、LoadBalancer、Ingress等。其中Ingress主要提供HTTP层(7层)路由功能,相比TCP(4层)的负载均衡具备非常多的优势(路由规则更加灵活、支持金丝雀、蓝绿、A/B Test发布模式、SSL支持、日志、监控、支持自定义扩展等),是目前K8s中HTTP/HTTPS服务的主流暴露方式。Ingress简介K8s中Ingress只是一种API资源的声明,具体的实现需要安装对应的Ingress Controller,由Ingress Controller接管Ingress定义,将流量转发到对应的Service。目前Ingress Controller的实现有非常多种(具体可以参考Ingress Controller官方文档),比较流行的有Nginx、Traefik、Istio、Kong等,在国内接受度最高的是Nginx Ingress Controller。日志与监控日志和监控是所有Ingress Controller都会提供的基础功能,日志一般包括访问日志(Access Log)、控制日志(Controller Log)和错误日志(Error Log),监控主要从日志以及Controller中提取部分Metric信息。这些数据中访问日志的量级最大、信息最多、价值也最高,一般7层的访问日志包括:URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等,对于Ingress Controller这种转发型的日志,还包括转发的Service名、Service响应时间等额外信息。从这些信息中,我们能够分析出非常多的信息,例如:网站访问的PV、UV;访问的地域分布、设备端分布;网站访问的错误比例;后端服务的响应延迟;不同URL访问分布。我们的开发、运维、运营、安全等人员可以基于这些信息完成各自的需求,例如:新老版本发布前后的数据指标对比;网站质量监控、集群状态监控;恶意攻击检测、反作弊;网站访问量统计、广告转化率统计。然而手动搭建、运维一整套的Ingress日志分析与监控系统非常复杂,系统所需要的模块有:部署日志采集Agent并配置采集、解析规则;由于K8s集群中,访问量相对较大,因此需要搭建一个缓冲队列,例如Redis、Kafka等;部署实时数据分析引擎,例如Elastic Search、clickhouse等;部署可视化组件并搭建报表,例如grafana、kibana等;部署告警模块并配置告警规则,例如ElastAlert、alertmanager等。阿里云日志服务Ingress解决方案为简化广大用户对于Ingress日志分析与监控的门槛,阿里云容器服务和日志服务将Ingress日志打通(官方文档),只需要应用一个yaml资源即可完成日志采集、分析、可视化等一整套Ingress日志方案的部署。Ingress可视化分析日志服务默认为Ingress创建5个报表,分别是:Ingress概览、Ingress访问中心、Ingress监控中心、Ingress蓝绿发布监控中心、Ingress异常检测中心。不同角色的人员可根据需求使用不同的报表,同时每个报表均提供筛选框用于筛选特定的Service、URL、状态码等。所有的报表均基于日志服务提供的基础可视化组件实现,可根据公司实际场景进行定制化调整。Ingress概览Ingress概览报表主要展示当前Ingress的整体状态,主要包括以下几类信息:整体架构状态(1天),包括:PV、UV、流量、响应延迟、移动端占比、错误比例等;网站实时状态(1分钟),包括:PV、UV、成功率、5XX比例、平均延迟、P95/P99延迟等;用户请求类信息(1天),包括:1天/7天访问PV对比、访问地域分布、TOP访问省份/城市、移动端占比、Android/IOS占比等;TOPURL统计(1小时),包括:访问TOP10、延迟TOP10、5XX错误TOP10、404错误TOP10。Ingress访问中心Ingress访问中心主要侧重于用于访问请求相关的统计信息,一般用于运营分析,包括:当日UV/PV、UV/PV分布、UV/PV趋势、TOP访问省份/城市、TOP访问浏览器、TOP访问IP、移动端占比、Android/IOS占比等。Ingress监控中心Ingress监控中心主要侧重于网站实时监控数据,一般用于实时监控与告警,包括:请求成功率、错误比例、5XX比例、请求未转发比例、平均延迟、P95/P99/P9999延迟、状态码分布、Ingress压力分布、Service访问TOP10、Service错误TOP10、Service延迟TOP10、Service流量TOP10等。Ingress蓝绿发布监控中心Ingress蓝绿发布监控中心主要用于版本发布时的实时监控与对比(版本前后对比以及蓝绿版本当前对比),以便在服务发布时快速检测异常并进行回滚。在该报表中需要选择进行对比的蓝绿版本(ServiceA和ServiceB),报表将根据选择动态显示蓝绿版本相关指标,包括:PV、5XX比例、成功率、平均延迟、P95/P99/P9999延迟、流量等。Ingress异常检测中心Ingress异常检测中心基于日志服务提供的机器学习算法,通过多种时序分析算法从Ingress的指标中自动检测异常点,提高问题发现的效率。实时监控与告警Ingress作为K8s网站请求的主要入口,实时监控与告警是必不可少的Ops手段之一。在日志服务上,基于上述的报表,只需3个简单的步骤即可完成告警的创建。下述示例为Ingress配置5XX比例的告警,告警每5分钟执行一次,当5XX比例超过1%时触发。除了通用的告警功能外,日志服务还额外支持:多维度数据关联,即通过多组SQL结果交叉判断进行告警,增加告警准确度;除支持短信、语音、通知中心、email外,还支持钉钉机器人通知、自定义WebHook扩展;告警的记录也以日志的形式记录,可以实现对告警失败进行告警的双保险。订阅报告日志服务除支持通过告警方式通知外,还支持报表订阅功能,可使用该功能将报表定期渲染成图片并通过邮件、钉钉群等方式发送。例如每天早上10点向运营群中发送昨日网站访问情况、每周发送报告到邮件组中存档、新版本发布时每5分钟发送一次监控报表…自定义分析如果容器服务Kubernetes版提供的默认报表无法满足你的分析需求,可以直接使用日志服务SQL、仪表盘等功能进行自定义的分析和可视化。尝鲜为了让大家可以体验Kubernetes审计日志功能,我们特别开通了体验中心,大家可以通过 https://promotion.aliyun.com/ntms/act/logdoclist.html 进入,该页面提供了非常多和Kubernetes相关的报表。参考文档阿里云日志服务阿里云容器服务Kubernetes版Ingress日志分析与监控告警配置订阅报表Ingress官方文档Ingress Controller官方文档一站式开发者服务,海量学习资源0元起!阿里热门开源项目、机器学习干货、开发者课程/工具、小微项目、移动研发等海量资源;更有开发者福利Kindle、技术图书幸运抽奖,100%中–》https://www.aliyun.com/acts/product-section-2019/developer?utm_content=g_1000047140本文作者:元乙阅读原文本文为云栖社区原创内容,未经允许不得转载。

March 19, 2019 · 1 min · jiezi

2小时快速搭建后端接口报警系统(基于阿里云日志服务分析nginx访问日志)

目标后端任一接口一分钟内5xx响应超过一定的量,马上收到报警提示报警及慢接口有详细列表可以查看低成本。几年前公司的日志报警系统是自研的,开发成本比较高,也没有达到阿里云日志服务这种产品化程度机器部署情况阿里云EC服务器功能概述阿里云日志服务,采集并分析nginx访问日志;写日志分析SQL,每分钟调度执行,符合条件就触发报警;根据响应状态码提供:接口5xx响应报警、接口4xx响应报警;报警通知方式为钉钉群机器人,5xx跟4xx响应分别通知到专用的后端跟前端同学群;修改日志分析SQL,在专用dashboard展示相关报警请求的详细信息列表根据响应时间提供:慢响应请求列表,同样放到dashboard效果图钉钉群报警【c是符合条件的个数,st是响应状态码】阿里云日志服务仪表盘-5xx报警接口详情操作步骤配置日志采集新建Project;新建Logstore;配置nginx日志采集;日志路径:/path_to_logs/**/access.log模式:nginx配置;从线上nginx.conf文件里拷贝 log_format main,配置到页面;Topic生成方式:文件路径正则;自定义正则:/path_to_logs/([^/]+)/access.log,正好把域名提取出来。可参考生成主题Logtail机器组:配置nginx机器内网IPnginx机器安装Logtail采集器;参考文档五分钟快速入门分析Nginx日志日志服务(SLS)用户手册配置日志分析SQL及报警日志库》查询分析》查询,可以写SQL实时查询/分析,然后另存为告警配置告警条件配置告警通知。一个告警可配置多个通知列表,可以同时通知到钉钉群跟短信5xx报警SQL为了方便查看具体的错误接口,基于uri分组统计并报警,报警内容里包含uri信息为了方便确认严重程度,报警内容里包含响应状态码__topic__:www.xyz.com and status in [500 600) | select count(1) as c, avg(status) as st, case when strpos(request_uri, ‘?’) > 0 then split_part(request_uri, ‘?’, 1) else request_uri end as uri group by uri having count(1)>=5 order by count(1) desc分析SQL的写法可参考告警-实时监控Nginx访问日志实时分析简介。支持的SQL语法及计算函数都有告警条件配置告警通知配置上面的配置图可能会变,这个产品一直在进化,18年12月的时候发现有一次大的改版。dashboard相关报警请求的详细信息列表SQL:topic:www.xyz.com and status in [500 600) | select time_local, status, upstream_addr, topic as vhost, case when strpos(request_uri, ‘?’) > 0 then split_part(request_uri, ‘?’, 1) else request_uri end as uri order by time_local descdashboard慢响应分析SQL:topic:www.xyz.com and request_time > 0.3 | select count(1) as count, avg(request_time) as avg_request_time, min(topic) as vhost, case when strpos(request_uri, ‘?’) > 0 then split_part(request_uri, ‘?’, 1) else request_uri end as uri group by uri order by avg_request_time desc ...

March 13, 2019 · 1 min · jiezi

使用Logtail采集Kubernetes上挂载的NAS日志

采集k8s挂载Nas后的日志该文档主要介绍使用logtail以两种不同的方式进行k8s挂载Nas后的日志采集。两种采集方式的实现原理是一样的,都是通过将Logtail和业务容器挂载到相同的NAS上,使Logtail和业务容器的日志数据共享,以此实现日志采集。下面是两种采集方式的各自特点:1. SideCar模式。比较灵活、适合水平扩容,适用于数据量较大的场景;2. 单独部署Logtail的Deployment。资源消耗比较低、但灵活性以及伸缩性不强,适用于整体集群数据量较少的场景(建议整体日志量不超过每秒10M)。1. Sidecar NAS采集方式通过 链接 使用PV&PVC的方式配置挂载Nas的nas-pvc步骤一 创建pv步骤二 创建pvc步骤三 根据下面的yaml模板创建含有logtail的Pod,进行单个Pod的内部采集sideCar模式实验yaml内容:apiVersion: batch/v1kind: Jobmetadata: name: nginx-log-sidecar1-demospec: template: metadata: name: nginx-log-sidecar-demo spec: # volumes配置 volumes: - name: nginx-log persistentVolumeClaim: claimName: nas-pvc containers: # 主容器配置 - name: nginx-log-demo image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest command: ["/bin/mock_log"] args: ["–log-type=nginx", “–stdout=false”, “–stderr=true”, “–path=/var/log/nginx/access.log”, “–total-count=1000000000”, “–logs-per-sec=100”] volumeMounts: - name: nginx-log mountPath: /var/log/nginx # Logtail的Sidecar容器配置 - name: logtail image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest env: # user id - name: “ALIYUN_LOGTAIL_USER_ID” value: “${your_aliyun_user_id}” # user defined id - name: “ALIYUN_LOGTAIL_USER_DEFINED_ID” value: “${your_machine_group_user_defined_id}” # config file path in logtail’s container - name: “ALIYUN_LOGTAIL_CONFIG” value: “/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json” # env tags config - name: “ALIYUN_LOG_ENV_TAGS” value: “pod_name|pod_ip|namespace|node_name|node_ip” - name: “pod_name” valueFrom: fieldRef: fieldPath: metadata.name - name: “pod_ip” valueFrom: fieldRef: fieldPath: status.podIP - name: “namespace” valueFrom: fieldRef: fieldPath: metadata.namespace - name: “node_name” valueFrom: fieldRef: fieldPath: spec.nodeName - name: “node_ip” valueFrom: fieldRef: fieldPath: status.hostIP # 和主容器共享volume volumeMounts: - name: nginx-log mountPath: /var/log/nginx # 健康检查 livenessProbe: exec: command: - /etc/init.d/ilogtaild - status initialDelaySeconds: 30 periodSeconds: 30 restartPolicy: “Never"SLS控制台采集配置设置如下图:日志路径与被采集容器的日志所在路径一致注意:由于NAS路径已经挂载到了Logtail容器上,所以不需要打开docker文件的按钮采集上来的系统默认字段含义:source: pod容器内部IP__tag__:hostname: pod名称__tag__:path: 日志路径__tag__:receive_time: 采集时间__tag__:user_defined_id: 用户自定义标识__tag__:namespace: pod所属namaspace__tag__:node_ip: pod所在Node的IP地址__tag__:node_name: pod所属Node的name__tag__:pod_ip: pod容器内部IP__tag__:pod_name: pod名称用户参数:2. 一个Logtail采集所有POD的NAS数据注意项:副本数spec.replicas只能为1,不能更多,多了会重复采集。首先,创建一个logtail的deployment,以下是本次使用的模板:apiVersion: apps/v1kind: Deploymentmetadata: name: logtail-deployment namespace: kube-system labels: k8s-app: nas-logtail-collecterspec: replicas: 1 selector: matchLabels: k8s-app : nas-logtail-collecter template: metadata: name: logtail-deployment labels: k8s-app : nas-logtail-collecter spec: containers: # Logtail的配置 - name: logtail image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest env: # aliuid - name: “ALIYUN_LOGTAIL_USER_ID” value: “${your_aliyun_user_id}” # user defined id - name: “ALIYUN_LOGTAIL_USER_DEFINED_ID” value: “${your_machine_group_user_defined_id}” # config file path in logtail’s container - name: “ALIYUN_LOGTAIL_CONFIG” value: “/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json” volumeMounts: - name: nginx-log mountPath: /var/log/nginx # volumes配置 volumes: - name: nginx-log persistentVolumeClaim: claimName: pvc-test-nginx__注意:__这里的 claimName: pvc-test-nginx 以及mountPath: /var/log/nginx 是将logtail的/var/log/nginx挂载了Nas下的/nginx文件夹相关参数设置请参考方案1中的表格说明logtail运行成功之后,可以在SLS控制台根据模板中的ALIYUN_LOGTAIL_USER_DEFINED_ID创建对应的机器组,请参考方案1中的表格说明。这里新建2个Pod来测试采集是否成功,其中一个POD的模板为:apiVersion: v1kind: Podmetadata: name: “test-nginx-2"spec: containers: - name: “nginx-log-demo” image: “registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest” command: ["/bin/mock_log”] args: [”–log-type=nginx", “–stdout=false”, “–stderr=true”, “–path=/var/log/nginx/access.log”, “–total-count=1000000000”, “–logs-per-sec=100”] volumeMounts: - name: “nas2” mountPath: “/var/log/nginx” volumes: - name: “nas2” flexVolume: driver: “alicloud/nas” options: server: “Nas挂载地址” path: “/nginx/test2” vers: “4.0"另一个Pod将 /var/log/nginx 挂载在了 /nginx/test1 目录下;结合logtail的挂载情况,现在两个Pod分别挂载在 /nginx/test1 和 /nginx/test2,而logtail挂载在了 /nginx 下。最后配置logtail的采集配置因为logtail也挂载了相同的Nas,所以logtail只需要采集自身文件夹下的日志就可以了,这里的是否为docker文件选项关闭。注意:由于NAS路径已经挂载到了Logtail容器上,所以不需要打开docker文件的按钮本文作者:元乙阅读原文本文为云栖社区原创内容,未经允许不得转载。 ...

February 27, 2019 · 2 min · jiezi

【kafka KSQL】游戏日志统计分析(3)

接上篇文章 【kafka KSQL】游戏日志统计分析(2),本文主要通过实例展示KSQL的连接查询功能。创建另一个topicbin/kafka-topics –create –zookeeper localhost:2181 –replication-factor 1 –partitions 4 –topic prop-normalized往新topic中写入数据bin/kafka-console-producer –broker-list localhost:9092 –topic prop-normalized>{“user__name”:“lzb”, “prop__id”:“id1”}从prop-normalized主题创建StreamCREATE STREAM PROP_USE_EVENT \ (user__name VARCHAR, \ prop__id VARCHAR ) \ WITH (KAFKA_TOPIC=‘prop-normalized’, \ VALUE_FORMAT=‘json’);重新设置ROWKEY为user__nameCREATE STREAM PROP_USE_EVENT_REKEY AS \ SELECT * FROM PROP_USE_EVENT \ PARTITION BY user__name;查询完成3局对局且没有使用过道具的所有玩家查询出所有玩家的对局情况,并创建表USER_SCORE_TABLE(前面已经创建过了):CREATE TABLE USER_SCORE_TABLE AS \ SELECT username, COUNT() AS game_count, SUM(delta) AS delta_sum, SUM(tax) AS tax_sum \ FROM USER_SCORE_EVENT \ WHERE reason = ‘game’ \ GROUP BY username;查询出所有玩家的道具使用情况,并创建表USER_PROP_TABLE:CREATE TABLE USER_PROP_TABLE AS \ SELECT username, COUNT() \ FROM PROP_USE_EVENT_REKEY \ GROUP BY username;使用LEFT JOIN进行左关联查询:SELECT s.username AS username \FROM USER_SCORE_TABLE s \LEFT JOIN USER_PROP_TABLE p \ON s.username = p.username; ...

January 9, 2019 · 1 min · jiezi

【kafka KSQL】游戏日志统计分析(1)

【kafka KSQL】游戏日志统计分析(1)以游戏结算日志为例,展示利用KSQL对日志进行统计分析的过程。启动confluentcd ~/Documents/install/confluent-5.0.1/bin/confluent start查看kafka主题列表bin/kafka-topics –list –zookeeper localhost:2181创建接受游戏结算日志的topicbin/kafka-topics –create –zookeeper localhost:2181 –replication-factor 1 –partitions 4 –topic score-normalized使用生产者命令行工具往topic中写日志bin/kafka-console-producer –broker-list localhost:9092 –topic score-normalized> {“cost”:7, “epoch”:1512342568296,“gameId”:“2017-12-04_07:09:28_高手1区_200_015_185175”,“gameType”:“situan”,“gamers”: [{“balance”:4405682,“delta”:-60,“username”:“0791754000”}, {“balance”:69532,“delta”:-60,“username”:“70837999”}, {“balance”:972120,“delta”:-60,“username”:“abc6378303”}, {“balance”:23129,“delta”:180,“username”:“a137671268”}],“reason”:“xiayu”}使用消费者命令行工具查看日志是否正常写入bin/kafka-console-consumer –bootstrap-server localhost:9092 –topic score-normalized –from-beginning;; 可以看到{“cost”:7, “epoch”:1512342568296,“gameId”:“2017-12-04_07:09:28_高手1区_200_015_185175”,“gameType”:“situan”,“gamers”: [{“balance”:4405682,“delta”:-60,“username”:“0791754000”}, {“balance”:69532,“delta”:-60,“username”:“70837999”}, {“balance”:972120,“delta”:-60,“username”:“abc6378303”}, {“balance”:23129,“delta”:180,“username”:“a137671268”}],“reason”:“xiayu”}启动KSQL客户端bin/ksql http://localhost:8088可以看到ksql启动后的图标,和操作终端。ksql终端查看kafka topic列表ksql> show topics;打印topic中的消息PRINT ‘score-normalized’;可以看到:Format:STRING19-1-5 下午11时59分31秒 , NULL , {“cost”:7, “epoch”:1512342568296,“gameId”:“2017-12-04_07:09:28_\xE9\xAB\x98\xE6\x89\x8B1\xE5\x8C\xBA_200_015_185175”,“gameType”:“situan”,“gamers”: [{“balance”:4405682,“delta”:-60,“username”:“0791754000”}, {“balance”:69532,“delta”:-60,“username”:“70837999”}, {“balance”:972120,“delta”:-60,“username”:“abc6378303”}, {“balance”:23129,“delta”:180,“username”:“a137671268”}],“reason”:“xiayu”}其中:第一个逗号19-1-5 下午11时59分31秒表示消息时间。第二个逗号NULL为消息的Key,因为是从kafka-console-producer推送的,默认为NULL。后面的就是推送过来的消息内容。从topic score-normalized创建一个StreamCREATE STREAM SCORE_EVENT \ (epoch BIGINT, \ gameType VARCHAR, \ cost INTEGER, \ gamers ARRAY< \ STRUCT< \ username VARCHAR, \ balance BIGINT, \ delta BIGINT \ > \ >, \ gameId VARCHAR, \ tax BIGINT, \ reason VARCHAR) \ WITH ( KAFKA_TOPIC=‘score-normalized’, \ VALUE_FORMAT=‘JSON’);删除一个STREAMDROP STREAM stream_name ;如果有查询语句在查询该流,则会出现错误:Cannot drop USER_SCORE_EVENT. The following queries read from this source: []. The following queries write into this source: [CSAS_USER_SCORE_EVENT_2, InsertQuery_4, InsertQuery_5, InsertQuery_3]. You need to terminate them before dropping USER_SCORE_EVENT.需要用TERMINATE命令停止这些查询语句,然后再删除流:TERMINATE CSAS_USER_SCORE_EVENT_2;TERMINATE InsertQuery_4;从最早记录开始查询ksql> SET ‘auto.offset.reset’ = ’earliest’;从Stream中查询所有数据ksql> SELECT * FROM SCORE_EVENT;可以看到:1546702389664 | null | 1512342568296 | situan | 7 | [{USERNAME=0791754000, BALANCE=4405682, DELTA=-60}, {USERNAME=70837999, BALANCE=69532, DELTA=-60}, {USERNAME=abc6378303, BALANCE=972120, DELTA=-60}, {USERNAME=a137671268, BALANCE=23129, DELTA=180}] | 2017-12-04_07:09:28_高手1区_200_015_185175 | null | xiayu其中:第1列为记录的时间戳。第2列为记录的key。第3列以后就是消息中的各个字段的值,对应创建流时的顺序。倒数第2列的null,是因为消息中tax字段不存在。统计2017-12-04日的对局总数;; 增加一个game_date字段,用于统计CREATE STREAM SCORE_EVENT_WITH_DATE AS \ SELECT SUBSTRING(gameId, 0, 10) AS game_date, * \ FROM SCORE_EVENT; SELECT game_date, COUNT() \ FROM SCORE_EVENT_WITH_DATE \ WHERE game_date = ‘2017-12-04’ AND reason = ‘game’ \ GROUP BY game_date;目前KSQL还不支持类似下面的查询:SELECT COUNT() \ FROM SCORE_EVENT \ WHERE gameId LIKE ‘2017-12-04_%’;统计参与对局的总玩家数(去重)因为一条日志中包含多个玩家的对局信息,所以想法把每个玩家拆分成单独的事件整合各个玩家的事件到一个统一的流USER_SCORE_EVENT:CREATE STREAM USER_SCORE_EVENT AS \ SELECT epoch, gameType, cost, gameId, tax, reason, gamers[0]->username AS username, gamers[0]->balance AS balance, gamers[0]->delta AS delta \ FROM SCORE_EVENT; INSERT INTO USER_SCORE_EVENT \ SELECT epoch, gameType, cost, gameId, tax, reason, gamers[1]->username AS username, gamers[1]->balance AS balance, gamers[1]->delta AS delta \ FROM SCORE_EVENT; INSERT INTO USER_SCORE_EVENT \ SELECT epoch, gameType, cost, gameId, tax, reason, gamers[2]->username AS username, gamers[2]->balance AS balance, gamers[2]->delta AS delta \ FROM SCORE_EVENT; INSERT INTO USER_SCORE_EVENT \ SELECT epoch, gameType, cost, gameId, tax, reason, gamers[3]->username AS username, gamers[3]->balance AS balance, gamers[3]->delta AS delta \ FROM SCORE_EVENT;统计各个玩家总的对局数、输赢总数、贡献的总税收,并以此创建一个表USER_SCORE_TABLE:CREATE TABLE USER_SCORE_TABLE AS \ SELECT username, COUNT(*) AS game_count, SUM(delta) AS delta_sum, SUM(tax) AS tax_sum \ FROM USER_SCORE_EVENT \ WHERE reason = ‘game’ \ GROUP BY username;查看USER_SCORE_TABLE所有数据:ksql> SELECT * FROM USER_SCORE_TABLE;1546709338711 | 70837999 | 70837999 | 4 | -240 | 01546709352758 | 0791754000 | 0791754000 | 4 | -240 | 01546709338711 | a137671268 | a137671268 | 4 | 720 | 01546709352758 | abc6378303 | abc6378303 | 4 | -240 | 0查询某个玩家的对局数、输赢总数、贡献的总税收:ksql> SELECT * FROM USER_SCORE_TABLE WHERE username = ‘70837999’;输出:1546709338711 | 70837999 | 70837999 | 4 | -240 | 0统计玩家总数(去重)添加一个傀儡列用于统计:CREATE TABLE USER_SCORE_WITH_TAG AS \ SELECT 1 AS tag, * FROM USER_SCORE_TABLE;统计去重后的玩家总数SELECT tag, COUNT(username) \FROM USER_SCORE_WITH_TAG \GROUP BY tag;续KSQL WINDOW 功能。 ...

January 6, 2019 · 2 min · jiezi

使用Docker快速部署ELK分析Nginx日志实践(二)

Kibana汉化使用中文界面实践一、背景笔者在上一篇文章使用Docker快速部署ELK分析Nginx日志实践当中有提到如何快速搭建ELK分析Nginx日志,但是这只是第一步,后面还有很多仪表盘需要配置,而对于大部分人来说,英文并不是那么好,但Kibana都是英文界面,这就阻碍了笔者熟悉Kibana的一些操作;所以笔者思考能不能将其汉化,在搜索引擎中找到了一些文章,发现汉化相对来说成本还算比较低,因此进行了一番实践,整个操作流程即便是将前人的汉化包拿过来使用,但使用的过程汉化包的作者并没有过多的讲解,本文主要是讲解如何使用汉化包以及操作过程的记录。笔者上一篇文章使用Docker快速部署ELK分析Nginx日志实践URL地址:https://segmentfault.com/a/11…二、操作概述汉化包下载运行环境安装汉化效果演示三、汉化包下载笔者所使用的汉化包项目名称为Kibana_Hanization,在Github上进行了开源,URL地址如下https://github.com/anbai-inc/Kibana_Hanization在上一篇文章当中笔者已经将/Users/song/dockerFile/挂载在容器的/data当中,因此可以直接在宿主机中通过git拉取汉化包,然后去容器里面运行它,参考命令如下cd /Users/song/dockerFile/ && git clone https://github.com/anbai-inc/Kibana_Hanization.git四、运行环境安装安装汉化包,需要完成三个步骤,首先需要有执行汉化包里面工具的Python2.7环境,然后需要找到Kibana的安装目录,最后才能执行安装,具体操作如下4.1 安装Python2.7笔者直接运行汉化包的时候发现此汉化工具依赖于Python2.7,而ELK中默认安装的是Python3,因此笔者需要先安装Python2.7的运行环境,操作如下首先需要拉取Python仓库地址apt update然后执行安装,参考命令如下apt install python2.74.2 查找安装位置安装好Python的运行环境之后,笔者还需要找到kibana的安装位置,参考命令如下所示find / -iname kibana命令执行后返回的结果/opt/logstash/x-pack/modules/azure/configuration/kibana/opt/logstash/x-pack/modules/arcsight/configuration/kibana/opt/logstash/modules/netflow/configuration/kibana/opt/logstash/modules/fb_apache/configuration/kibana/opt/kibana/opt/kibana/src/core_plugins/kibana/opt/kibana/node_modules/x-pack/plugins/ml/server/models/data_recognizer/modules/apache2/kibana/opt/kibana/node_modules/x-pack/plugins/ml/server/models/data_recognizer/modules/nginx/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/lib/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/lib/metrics/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/server/routes/api/v1/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/views/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/components/kibana/opt/kibana/node_modules/x-pack/plugins/monitoring/public/directives/kibana/opt/kibana/node_modules/@kbn/pm/src/utils/fixtures/kibana/opt/kibana/bin/kibana/etc/logrotate.d/kibana/etc/init.d/kibana根据返回结果和以往的经验,大致猜测出安装位置在/opt/kibana下,在得到安装目录之后,现在笔者需要进入此前在宿主机通过git下载的汉化包目录,因为运行elk容器的时候已经将宿主机目录挂载进去,因此容器中可以进入,参考吗命令如下cd /data/Kibana_Hanization4.2 汉化包安装执行汉化命令python2.7 main.py /opt/kibana/返回结果文件[/opt/kibana/optimize/bundles/kibana.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/commons.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/login.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/ml.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/monitoring.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/timelion.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/vendors.bundle.js]已翻译。文件[/opt/kibana/optimize/bundles/apm.bundle.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/ui_setting_defaults.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/translations/en.json]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/docker_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/elastic_cloud.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/on_prem_elastic_cloud.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/on_prem.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/netflow/common_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/kubernetes_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apache_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/redis_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apm/apm_server_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apm/apm_client_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/nginx_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/system_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/system_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/apache_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/nginx_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/redis_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/mysql_metrics/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/server/tutorials/mysql_logs/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/common/tutorials/filebeat_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/common/tutorials/metricbeat_instructions.js]已翻译。文件[/opt/kibana/src/core_plugins/kibana/public/dashboard/index.js]已翻译。文件[/opt/kibana/src/core_plugins/timelion/index.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/line.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/area.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/heatmap.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/horizontal_bar.js]已翻译。文件[/opt/kibana/src/core_plugins/kbn_vislib_vis_types/public/histogram.js]已翻译。文件[/opt/kibana/src/ui/public/chrome/directives/global_nav/global_nav.js]已翻译。恭喜,Kibana汉化完成!笔者执行这条命令时间大约在10秒钟左右。五、汉化效果演示经过上一步操作,已经完成了汉化包的安装,现在笔者进入Kibana的主页来验证汉化的效果,Kibana主页的URL地址如下http://localhost:5601/app/kibana#/home?_g=()但在实际汉化后发现并没有完全汉化,笔者所使用的ELK版本为6.4.0,效果如下图所示而汉化包中介绍的汉化效果效果却如下图所示笔者猜测可能是自己使用的ELK版本比较新,而汉化包还没用跟上节奏所导致,不过效果已经很棒了;笔者接着又打开了几个页面,发现汉化效果大都在80%左右,视图创建URL地址如下http://localhost:5601/app/kibana#/visualize/new?_g=()在浏览器中打开视图创建页面后,展现汉化如下图所示作者:汤青松微信:songboy8888日期:2018-08-31

September 1, 2018 · 1 min · jiezi