日志系统相关

 日志中心存储上的优化？ 

写入吞吐优化

　　节点负载路由，根据节点负载数据写低负载节点

　　索引冷热分离，热数据使用ssd

稳定性优化

　　小集群

　　代理层查询线程级别隔离

　　增加协调节点级别超时（19s）

 

索引冷热分离如何实现的以及效果如何？

节点负载路由如何实现的以及效果如何？

小集群如何选择？

目前集群容易出现的问题是什么以及如何处理？

存储量上的优化有哪些？

内存上的优化有哪些？

cpu上的优化有哪些？

查询剪枝是如何实现的？

 

https://console.guance.com/logIndi/log/all?lak=LogIndi&activeName=Log&w=wksp_5280dbc3ea114fdfb8419dd5565bd4ca&time=1726112828981,1726113728981&index=default&cols=time,container_name,message&viewType=view

日志抽取他们用的是grok语法，正则？

索引不是针对指定字段维度，而且针对数据维度，感觉不太合理

 

https://clickvisual.net/zh/clickvisual/08logagent/logagent.html#clickvisual-agent-%E6%8E%A5%E5%8F%A3%E6%9F%A5%E8%AF%A2%E6%97%A5%E5%BF%97%E6%B5%81%E7%A8%8B

这种分布式日志查询agent是不是只有小公司适用？大公司有没有应用场景

 

 

 

https://www.alibabacloud.com/help/zh/sls/product-overview/comparison-of-monitoring-and-analysis-platforms

日志平台的难点： 

 监控平台的挑战：稳定性、性能、成本

 

 

 

https://loggie-io.github.io/docs/user-guide/enterprise-practice/architecture-and-evolution/

如何选择日志平台架构？ 

https://app.diagrams.net/?src=about#Heric-caiyao%2Fdarw_io%2Fmain%2Flog_platform_structure.drawio#%7B%22pageId%22%3A%22YfjnFncdKknPi8jD7Qkr%22%7D

架构需要根据实际情况选择，但是基本的节点都是有的，就是看怎么部署这些节点，主要是资源上的考虑，如何部署各个节点就类似于微服务的概念，微服务需要考虑相同属性的放在一起，比如稳定性要求、程序特征(IO密集 or 存储密集)、资源评估的便利度、计费的便利度等，注意这里不能简单的按照日志规模，比如流量、条数这些简单的指标来选择架构，可以作为一个基础参考条件，比如流量大的时候稳定性要求、程序特征、计费这些问题会更突出。

日志适配+存储写入模块要不要使用Flink？

优点：

前期接入比较方便，能快速出效果

缺点：

Flink框架会隐藏很多的逻辑，我们能控制的比较少，这样对于后期维护还有优化成本会比较高，比如debug不方便、jvm内存管理不方便、Flink框架基建一般没有原生Java服务丰富(比如发布、监控)等

所以目前看如果公司对于Flink没有很好的基建，建议不使用Flink，自己实现成本也不高，毕竟日志场景使用Flink感觉还是大材小用

loggie的核心思路

微内核、简化架构： agent和处理层统一架构，核心代码简单，稳定性高，方便维护

 

持续降本：B站日志平台3.0演进之路：  https://www.bilibili.com/read/cv24473211/

美团高性能终端实时日志系统建设实践： https://tech.meituan.com/2022/11/03/logan-real-time-log.html

 

阿里云 SLS产品分析：

标准型Standard Logstore: 使用什么存储？
查询型Query Logstore: 不支持sql分析，使用什么存储？
支持将查询型Logstore升级为标准型Logstore： 涉及存储迁移？
不支持将标准型Logstore降级为查询型Logstore： 为啥？
Logstore的计费方式，包含按写入数据量计费和按使用功能计费： 这里的使用功能是不是需要跟logstore类型有关系，比如sql分析的功能这个必须要求是标准型
写入流量：
读取流量：读取流量怎么算出来？
读写次数：写入次数和流量单独计费？
加工流量：
投递流量：
存储量：
日志服务每天更新一次该数据，不是实时更新：都是T+1，实时更新成本更高？还是说有一些计费需要T+1才有数据？
日志服务在采集日志时，会自动压缩日志数据量，压缩率为10%~20%：我们可以参考，但是什么时候解压这个待看下
日志服务计算型功能收费计划逐步通过OCU进行计量：底层是用Flink这类的大数据资源？所以使用大数据的计费方式，这些计算型功能都包括哪些？是否都能明确计算出来准确cu使用，大数据是如何计算任务cu使用的
CPU核心数、内存大小和IOPS三个维度分别计算三个OCU数量，然后取三个OCU数量的最大值： 取最大合理一些，现在日志中心用的是按照比例来的，不合理
上传到日志服务并配置其中两个字段的索引：是不是只有索引了才能查询，非索引的不支持查询。sls是如何做索引的
SLS的热存储和低频存储分别使用的是什么存储引擎：
低频存储也会有索引成本么：有
SLS的索引是怎么实现的？是和原始数据完全分开存储？
包括时序数据（压缩后）的存储量和时序数据： 时序数据用的底层存储引擎是同样的么？
升级后，默认启用当前字段索引的统计功能，该功能仅适用于新写入的日志：索引服务和日志服务双写？
存储空间-时序存储： 时序日志用的是啥存储？和普通的日志存储有什么区别
例如原始数据量为10 GB，则上传到日志服务会产生2 GB（压缩率20%）的写流量： 压缩后传输
例如原始日志量为1 GB，写入到日志服务并开启全文索引，则索引流量为1 GB： 索引计费跟底层使用技术无关，而是跟要索引的日志量有关
索引流量-日志索引-查询型：查询型和标准型的索引为啥计费分开？
扫描流量： 扫描流量是什么？ 查询的时候使用的？
为什么会产生活跃Shard租用费用： 还会对性能计费，同样的存储量写入性能高，计费高
SQL独享版： 能够精确控制查询的资源消耗才能对这种进行计费，如何精确控制查询的资源消耗？是否跟使用的底层存储有关系
每个Shard支持5 MB/s的数据写入和10 MB/s的数据读取： 如何精准控制这个写入和读取流量的？
字段别名的作用是什么？

 

阿里云： 

阿里云 10 PB+／天的日志系统设计和实现： https://www.infoq.cn/article/wgiy55h3raqdy0ci-823
亿级异构任务调度框架设计与实践： https://xie.infoq.cn/article/4e456013db1faa28d3c8d8247?utm_source=related_read_bottom&utm_medium=article

字节跳动 EB 级日志系统设计与优化实践: https://juejin.cn/post/7383880021821587468

腾讯: 企业微信万亿级日志检索系统: https://mp.weixin.qq.com/s/opxvlddsSQctb3nwcxaW_g