袋鼠云日志,日志分析没那么容易

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 袋鼠云日志,一款高性能可扩展的日志集中、搜索和分析产品
从决定做袋鼠云的那一天,我就在思考,做为一家云计算和大数据的技术服务公司,做什么样的产品能给客户提供价值?


从2012年开始,我一直在做一个移动日志分析产品,类似于友盟和TalkingData,不过因为各种原因,这个产品主要为阿里集团内部的各个App提供服务,基本上成为了集团内部标配的工具,每天处理日志量超过1000亿条,顺利渡过了几次双十一大屏的大考,在稳定性和数据准确性方面都经受了挑战。


但除了数据量和电商业务中的交易链路跟踪和转化率的变态需求之外,移动日志分析从某种意义上来说还是简单的,因为日志数据的格式是预定义的,并且标准也由我们团队来制定。控制了源头,后续整个流动过程处理起来就相对容易。


2015年开始,我们也为阿里云的部分客户提供移动分析服务,经常碰到的一个问题就是,除了App,还有PC网页能一起分析么?说实话,这是一个合理的需求,所以今年友盟、CNZZ和缔元信的合并,变成友盟+,是一个非常自然的演进,但要真正做到跨屏数据的融合分析,就不是那么容易的事情了。


那么,除了移动App日志,PC Web日志,还有各种其他的日志,比如Linux的登录日志、Web服务器的Access Log、MySQL数据库的Error Log,Oracle数据库的Alert Log、应用程序打的各种Debug日志,等等。这些日志格式各异,分布在不同服务器的不同地方,如何集中、结构化、分析和展现这些数据,从中挖掘出更多的价值,是一件有挑战的事情。


2003年成立的Splunk应该是最知名的一家用搜索的思路来做日志产品的公司,但最初是以C/S架构做的,其云端产品虽然功能强大,但试用过后易用性只能说一版。而它的独立部署版本,据一些合作伙伴反馈,部署成本也很高。所以类似Sumo Logic、LogEntries、Logz.io等新兴的日志创业公司也是一个接一个,并且都获得了不错的融资。


而开源领域,ELK技术栈也是因为日志的需求而获得了极高的关注度,Elasticsearch、Logstash和Kibaba的组合,对于有一定技术实力的创业公司来说,部署一套不存在问题,但除了搜索功能之外,能用好的案例也不多,还需要投入人力来维护,对于创业公司也是不小的成本。


回到国内,之前有个做安全日志分析的日志宝,被360收购后已经停止运营。而最近在各个技术大会上露面较多的日志易,去年底号称获得了6000万的A轮融资,所以在百度上把Splunk关键字都买了。2015年8月份在36Kr上也有软文说日志易试用了Spark Streaming技术,并且正在开发基于机器学习的Log Reduce 技术。但到今天,实际上以日志易SaaS版的功能来说,完全没有用Spark的必要,Log Reduce也只是借鉴了Sumo Logic的一个概念而没有实际产品化出来。


所以说,日志分析没那么容易。真正要做好,像Splunk一样十几年了还需要面对不断推陈出新的对手。一通产品看下来,只有Sumo Logic真正的做到了创新,尤其是Log Reduce,也确实有技术含量,而不仅仅是一个术语,但实际的使用场景和效果如何,也还有待更多客户的验证。


那么袋鼠云日志能做些什么呢?首先,和所有的日志产品一样,如何更简单的完成日志的集中,统一搜索入口,对日志字段进行分析探索,基于日志的监控告警等都是最基本的需求。除此之外,袋鼠云日志当前版本也有两个独特的产品体验:


1. 日志实时Tail。 运维和开发同学在使用日志的时候,对日志文件执行tail -f file.log是最常用的操作,我们把这个功能也直接做到云日志中了,并且支持按主机、应用和日志类型进行筛选,也支持输入关键字做过滤。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

2. 自定义可视化大盘。 不是简单的添加固定模板拼出来的报表,而是可视化配置包括数据源和外观的完整的自定义大盘,并且可以全屏在显示器/电视机等屏幕上完美呈现。

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

当然,这只是我们创业四个月来发布的第一个公测版本,接下来一个月在简化日志接入和Web日志安全分析等方面也会快速实现。至于Spark on Elasticsearch实现关联分析也在规划中,但能否做到更好,也欢迎对这个方向有兴趣的同学们加入进来,一起做国内最好的日志产品,解放运维和开发,满足业务和老板,把日志这么不容易的事情,真正做到易用好用。


有兴趣了解的朋友,欢迎加我的微信NinGoo细聊。试用可以直接到http://www.dtstack.com注册。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
27天前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
|
9天前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。
|
19天前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
50 9
|
28天前
|
开发框架 .NET Docker
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
|
21天前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
56 0
|
21天前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
45 0
|
23天前
|
存储 消息中间件 监控
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统ELK、日志收集分析
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统、日志收集分析。日志级别从小到大的关系(优先级从低到高): ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF 低级别的会输出高级别的信息,高级别的不会输出低级别的信息
|
27天前
|
存储
【Azure Log A workspace】Azure上很多应用日志收集到Log A workspace后如何来分别各自的占比呢?
【Azure Log A workspace】Azure上很多应用日志收集到Log A workspace后如何来分别各自的占比呢?
|
27天前
|
API
【Azure 应用服务】当在Azure App Service的门户上 Log Stream 日志无输出,需要如何操作让其输出Application Logs呢?
【Azure 应用服务】当在Azure App Service的门户上 Log Stream 日志无输出,需要如何操作让其输出Application Logs呢?
|
28天前
|
存储 关系型数据库 MySQL
深入MySQL:事务日志redo log详解与实践
【8月更文挑战第24天】在MySQL的InnoDB存储引擎中,为确保事务的持久性和数据一致性,采用了redo log(重做日志)机制。redo log记录了所有数据修改,在系统崩溃后可通过它恢复未完成的事务。它由内存中的redo log buffer和磁盘上的redo log file组成。事务修改先写入buffer,再异步刷新至磁盘,最后提交事务。若系统崩溃,InnoDB通过redo log重放已提交事务并利用undo log回滚未提交事务,确保数据完整。理解redo log工作流程有助于优化数据库性能和确保数据安全。
111 0