郝玉杰的专栏

通过将日志文本向量化（如使用TF-IDF向量化），然后应用K-Means算法对日志进行聚类，从而将相似的日志归为一类，实现自动分类。它能够将日志数据嵌入到低维向量空间中，从而更好地表示日志的语义信息和结构信息，为模型的分类和异常检测提供了更有效的特征表示。它能够对海量日志数据进行无监督学习，从而生成统一的日志表示，为后续的日志分类和分析提供了良好的基础。使用了Drain，这是一种在线日志解析方法。它能够将原始的日志数据解析为结构化的日志事件，提取出关键的特征信息，为后续的模型分析提供更清晰、更有用的数据。

这是我开发的工具的中间的样子.

（3）关于，为什么这两个事件的名字不一样，还是能被tracecompass解析这件事，可能要看tracecompass的代码，才能直正得到答案。perf转为ctf只是它一个扩展的功能，所以，它需要做得更多，以防止疏漏，所以，就多出了通用的记录头这部分，如下图。所以，开始之前，有许多问题在困扰着我，其中一个是为什么LTTng的meta与perf的meta定义并不同，或者，tracecompass的绘图机制，是另一种机制，例如，只要发现线程切换，就绘制。所以，本文的标题的主语是TraceCompass，

现在的重要收获是，对方的代码书写方式，如果有_class后缀，说明是meta的定义，如果没有，则在数据面。一是因为Spammy_Event简单，如下，另一个是因为从compass中看到，它有许多实例。然后增加两个field定义，之后将新生成的event类，加入到stream_class。跳过一些为测试而准备的代码后，将要看到如何插入数据。现在能理解class与meta是等价的。## 查找 Spammy_Event。从Spammy_Event开始。如上图，生成事件，和压入数据。然后，压入自定义事件的数据。

正在并行做几件事。在编译过程中，突然想到，还是再详细研究一下之前的例程。一是详细找了一下，除了前述这例子，没有其它的有价值的，对眼前这件事情来说。然后也花了一些时间，进一步了解babeltrace，发现，也没有多少有用的价值。所以，还是重新看一下代码：meta是如何被创建的。

因为我们的nanolog每一行（业务代码中）都相当于一个meta，lttng C api这种 C语言宏，预定义的方式，让我担心，是不现实的。开发工具，对于我们这些码农底层来说，是相当可笑的一件事。去网上找了找同类，发现有几个同仁，也稍研究了一些相关的内容。之所以，说曾经，是因为我太了解这个行当和当下的上下文了。所以，代表我个人，向这些曾经研究过一二的同仁表达敬意。

事情正在朝着不可控的方向狂奔。。。系统工师师，其实只有一个任务：将复杂的系统简单化；将乱成一团的分工，明确化；降低每个人面对的复杂度。归根到底系统工程师要处理的是复杂度：简化复杂度。与庖丁解牛类似。但现在的情况，是正在向北极狂奔。尽管我马快，车夫好，但我现在唯一担心的，不是去不去楚国的问题，而是身上的衣服能不能度过北极的问题。本来，我们根本不需要研究nanolog的，我们只需自己划格子。有人出了格，我们能用证据说明：你出格了。我们的任务就完成了。

背景是了解完大概的Nanolog之后，还需要准备实现将nanolog转为ctf。最开始的方向，的确是按之前的计划，采用lttng usr lib。写了一个工程，后面可能用上。但lttng lib相对难用，有时间我们详述。简言之，过多地与C语言的宏绑定。我是不喜欢这种编码方式的，不灵活。所以，因为前面虽然GPT强调应该基于lttng，但查看文章也发现，babeltrace不仅有读和转换，还有写入的ctf的能力。所以，抽时间，还是临时调研一下。故有本文。

前面的工作，已做打下令人有信心的基础。

但是要注意的是nanolog的线程id，并不是线程ID。不过，要注意的是,logFile需要删除重做。如果不删除，文件会被重新打开，从头开始重写。文件名中的路径被删除了。，之后，程序的运行轨迹简化了许多。在这里也卡了一小会，因为terminal中，没有输出。也就是意味着，我们在这里分析时，meta信息，已加载了。当前的目标，是找到解压时， meta 的信息。否则不会指出是哪个文件的哪一行，这里是我疏忽了。这样我们第一次看到一个log的输出所在的位置。之后我们可以向前研究，这个结果是如何得到的。

如前。建立工程进行跟踪后，发现自己对Nanolog的理解还是太少了。其过程，还是相对比较复杂。以及有一些信息，这前的分析中，没有注意到。本节，不向前推进，进行一定的总结与学习的准备。另外，这里先不得不说抱歉，因为工时很紧张，只能问了GPT一些内容，一会贴在下面。国内我发现，只要是这类底层的工作，很少有人问津，所以，虽然内网有一些关于nanolog的内容，大多与我要做的事情无关。大多是介绍性的工作。客观说，不如前面我分析的内容更加细致。

如果目标是转nanolog为CTF格式，最重要的应该是meta的定义的转换的问题了。目前我是稍有气馁。感觉这不是一个好的方向。如果领导能给连续的时间，完全开发自定义的binary，原本不需要面对这些困难。但是，我们不能考虑这些事情。目前能做的，是思考如何完成这个不太可能完成的任务。

下面我们尝试了解，解压的过程，是如何得到文件头部的meta信息的。

如下图，消息头（似乎尾），描述了logid，根据这个id，也就能对应上这段binary内存的meta定义了（前面registerInvocationSite，注册的）。这个方面，还是我比较看重的，前面我提到，现在存在的一个bug与之相关，如果在解压某条出错时，打印文件名和行号，这问题，也就不是一个问题了。写C语言编译前端时，给我印象深刻的一部分是，我们需要记录，当前的位置，以便于在出错时，报告出错的位置。这里暂略，如下图，因为分配的大小很小，所以，直接返回了。如上图，能够看到文件名与行号，与调用方对应。

这个主函数，我们看到内容并不多/***/uint32_tfilename,linenum,severity,format,array);uint32_t#endifuint32_t该函数，我们看到内容并不多。

如前所述，nanolog的server端，相对而言是比较简单的。当然，这个“简单”是与客户端相对而言。实际上，很容易猜出来，在用户面那个，是将数据从client搬来，kernel那个操作IO.其中，与aioCb相关的内容很多，这里我不去分析了。也就是server数据接收线程，受制于异步IO的读写。当然把nanolog集成到自己的项目中，会发现，多了两个线程。这是一个需要优化的点。所以，我们先来分析相对简单的Server端。一个在用户面，一个大多时间在kernel中。前面许多相关的代码，与串行化相关。

注意，这里的断点，很可能不停，如果出现在这样的情况，一定要手工重编runtime目录的内容，直到./sample/libNanoLog.a 与runtime下的md5相同了。这里定义了一个全局变量，所以，在main进入前，就在磁盘上生成了这个空文件。手工执行的结果如下，不看代码，还真不知道，被放到/tmp/logFile了。特别是根目录，自动放了一个文件，叫compressedLog。即然我们看到了，不如来研究一下，为什么会生成这样的一空文件。我一直以为是这个文档，解了半天，没解开，看了代码才知道。

最好的文档是代码，最好的老师是编译器和调试器和toolchain中其它的工具。runtime，这是运行库所在的位置。一会我们再讲。sample，这是我们准备开始的位置。

学习一种新的技术，最好的办法是先不要看，先要思考自己的需求，如果自己来实现，应当如何做。最好写在纸上。然后再找现成的轮子。这时，不要被这些轮子影响。

前面的贴文做了一些工作，下面开始准备编程。方向选择了LTTng C API。

这里我想解释一下我的目标。因为原来的工程中，已有log，我可以将userspace的probe插入到代码的关键位置，但是这样我需要承担老板认为我改坏了代码的风险。嗯，这个对于有的公司不是问题，但有的场景你需要面对hard person。所以，我希望直接将现在的log转为CTF。这个地方，一方面，我详细思考了一下，另一方面，也问了GPT之神之类的，我觉得旁观者清，它的想法是对的。本来我应该绘一张图：这里我写这些文字，是因为至少在一些中文的博主的案例来看，大家基于babeltrace2的居多。

调研了TrackCompass后，感觉并不理想。另一个工具是KernelShark。在接连搞坏ubuntu 20.04和22.04两个虚拟机后，我痛下决心，下载了新的ubuntu24.04.01，来编译kernelshark。也不清楚我是不是这样做太过于执着。聪明人有时确会执着，但蠢人也会。现在还不清楚。。。是哪个。

实际示例：perf , trace compass, sdt,ctf

收集自己编译内核的一些信息版本：5.15.126为什么选这个版本：该版本的lttng可以正常工作。

试想一家能为整个中国和世界，提供性能分析的全生命周期的公司：从工具，到kernel的配置和应用面的适配。这是完全有必要，也有可能的。

之前我一直例用的是vmware workstation 17.5.1, 一直存在NAT服务占用率过高，我的小破ThinkPad本的风扇一直在嗡嗡叫。今天找了一下，找到同名文章，在这里目前这里能下载。csdn上有人说，等虚拟机连上后，就停了NAT，这种方法，如果你直接将IP设置为固定，然后也不停，不重启，是可以的。但新装一台的时候要开，重启机器后要开，否则网络是不能的。还有csdn上主的要改 /etc/hosts的内容这个，应该也是什么作用都没有的。我试过了，没有效果。

虽然我的人生并不是可控的，但这些年我的方向基本上还是在并行计算相关的底层，算是有几分幸运。虽然学了许多知识，但我清楚，有一样技术，我感兴趣，世界也很需求，但是好像人们并不是真正关注和理解。未来的世界需要的是一种随时停止的纤程。这个一会我再解释。我与kimi进行了激烈的讨论，了解了一些问题。先说结论：最终它的建议是，我们可以试试boost::fiber。

思考了一下，决定单独记录一下这个话题。因为这里我花费了许多时间来知道，原来线程名是有长度限制的。也是为了以后来完善。

新装的Trace Compass，import 了正常的日志，界面没有变化。

perf 代替lttng来抓取tracecompass可读取log

因为种种原因，需要手工编译网上有几篇，但一方面，试过不成；版本也太旧。所以，这里我重写一个。最后我会压个包，放到资源里。里面包含原始包和编译脚本。