背景
最近在实习的时候打算整一整我们混乱的日志系统。之前在别家企业实习的时候，有接触过日志系统。但是也就停留在知道了，当时还不会查询哈哈。 只是围观同事们查询，不过也知道了一些内容吧。所以我的实践便开始了
技术选择
目前的话是基本采用了ELK 三件套。可能也是两件套吧。elasticsearch + Kibana + filebeats
整体架构
大致结构是ES作为搜索引擎和索引系统，Kibana来进行面板的展示和搜索。采用了loguru日志库来进行日志的打印。 loguru还是很方便的，没用过的话可以去看一看怎么用。 输出的话就是stdout + 文件写入。由file beats来监听文件，然后转发到es。es索引完后，Kibana显示出来。我们的查询也在Kibana做。 值得说一下是filebeats 我是拿docker运行的，把因此会有一个挂载日志目录到容器内的一个过程。
使用方法
我的设想大概是自己首先维护一个日志工厂。 需要log的模块，生成自己的instance。 之后打印相关的内容。 由于loguru可以自己在.info里面加extra字段。这些字段会被map，因此我觉得还是非常方便的。然后就伏笔了。
问题
遇到的第一个问题大概就是我对loguru的细节不太了解。 我没有意识到一个问题， 当你使用log.info 的时候，这个log对应的实例究竟是哪个？ 起初我并没想到这个问题，因为我觉得每个log和服务是绑定的。 但是在运行过程中，遇到了在终端会重复很多条相同输出的问题，但是文件内容是正常的。 后面问了一下Claude，大概是因为没有将各个实例和隔离开吧，但是为什么文件正常呢，检查了一下发现是因为在写文件的时候有做一次过滤，只有命名对上了才能写入文件，原来是这样。
第二个问题是字段爆炸，这个问题其实到现在也没有很好的解决。因为我们有很多服务，基本上是遵守了ecs的设计。但是每个服务会有自己独特的业务相关字段。因此，加上我们有如此多的服务。所以导致在Kibana进行查询的时候特别的痛苦😣。 后面又根据服务名做了一个二级的区分，但是依然存在字段爆炸多的问题。目前的解决办法是从场景入手解决字段问题，我们先想出使用的场景，根据场景去设计字段。
第三个问题其实还是字段的问题，不知道什么字段是关键数据呢。感觉一顿打之后，没有什么用，可能来自我对日志的理解还是不够深刻。而且也缺乏相关的经验，估计跟几次日志就老实了
现状
现状就是目前的日志系统基本都改成了新系统，使用elk统一管理和查询。我觉得比之前直接重定向stdout好多了，而且便于管理一点。但是我觉得还是需要考虑一下后续的设计的。如何设计字段这个问题，还是没有一个很好的答案，待我学习更多知识，下次再聊。