1
00:00:00,000 --> 00:00:00,266
大家好

2
00:00:00,333 --> 00:00:01,466
这里是 AsyncTalk

3
00:00:01,466 --> 00:00:02,766
今天我想跟大家来聊

4
00:00:02,766 --> 00:00:04,066
一个比较有趣的项目

5
00:00:04,133 --> 00:00:05,600
它实际上是一个日志服务

6
00:00:05,633 --> 00:00:07,900
这个日志服务其实 callback 到我们前面

7
00:00:07,900 --> 00:00:11,700
关于如何做正确的日志的一个节目

8
00:00:11,766 --> 00:00:14,266
我相信大家在自己的一些项目中

9
00:00:14,333 --> 00:00:15,433
假设说你是一个后端

10
00:00:15,466 --> 00:00:18,533
你肯定是要给自己的项目打一些日志的

11
00:00:18,600 --> 00:00:20,400
那这些日志它有助于

12
00:00:20,400 --> 00:00:22,033
你在将来去做一些 debug 

13
00:00:22,066 --> 00:00:23,533
做一些任务的追踪

14
00:00:23,600 --> 00:00:24,833
做一些各种各样的情况

15
00:00:24,866 --> 00:00:26,200
那这个日志的重要性

16
00:00:26,200 --> 00:00:28,033
大家绝对都已经了解到了

17
00:00:28,066 --> 00:00:30,366
但是对于如何做好日志这件事情

18
00:00:30,433 --> 00:00:34,066
我也相信这个吵了 20 多年的一个话题

19
00:00:34,133 --> 00:00:37,633
到今天仍然没有一个很好的解答

20
00:00:37,666 --> 00:00:41,266
到今天仍然是一个很难处理的问题

21
00:00:41,333 --> 00:00:43,166
今天我觉得我可以分享一个

22
00:00:43,166 --> 00:00:45,866
关于我自己在用的 log 服务

23
00:00:45,900 --> 00:00:47,133
我觉得它很好

24
00:00:47,200 --> 00:00:49,466
也非常的 AI 时代

25
00:00:49,500 --> 00:00:50,800
那就是 Axiom 

26
00:00:50,866 --> 00:00:51,566
Axiom 这个项目

27
00:00:51,633 --> 00:00:53,600
它其实就是一个日志

28
00:00:53,633 --> 00:00:55,566
那我可以和大家去 share 一下

29
00:00:55,566 --> 00:00:56,900
这个 Axiom 的项目

30
00:00:56,966 --> 00:00:58,100
可以在这里边看到

31
00:00:58,100 --> 00:01:00,400
我的一个日志的情况

32
00:01:00,433 --> 00:01:02,266
这边比如说它打了一个

33
00:01:02,266 --> 00:01:04,500
在这个 component 那个 info 

34
00:01:04,500 --> 00:01:07,100
以及 start CC event cost enqueue 

35
00:01:07,100 --> 00:01:07,466
 这样一个事件

36
00:01:07,500 --> 00:01:09,266
那里边有一些什么 user ID

37
00:01:09,266 --> 00:01:10,566
以及这些参数

38
00:01:10,633 --> 00:01:11,933
可以看到这边其实

39
00:01:11,933 --> 00:01:13,633
还是有蛮多的一些内容的

40
00:01:13,666 --> 00:01:15,733
那这个日志其实就是通过

41
00:01:15,733 --> 00:01:17,933
我部署的服务那边采集过来的

42
00:01:18,000 --> 00:01:19,000
但我的部署的服务化

43
00:01:19,033 --> 00:01:20,600
它是支持的接口

44
00:01:20,633 --> 00:01:23,133
会把一些 tracing 的 task 数据

45
00:01:23,133 --> 00:01:24,200
给传到服务上面

46
00:01:24,233 --> 00:01:25,400
同样这个 Axiom 

47
00:01:25,400 --> 00:01:27,066
它来接收我们的日志

48
00:01:27,100 --> 00:01:27,933
然后接收到日志

49
00:01:28,000 --> 00:01:29,933
我们就可以在这个后台看到这个日志

50
00:01:29,933 --> 00:01:31,866
以一种比较优美的方案

51
00:01:31,900 --> 00:01:33,200
因为它这个日志搜索

52
00:01:33,200 --> 00:01:35,066
我自己试过还是相当不错的

53
00:01:35,100 --> 00:01:37,800
这个界面我只能说我之前没有用到过

54
00:01:37,800 --> 00:01:40,366
这么漂亮的一个日志管理平台

55
00:01:41,533 --> 00:01:43,300
Kibana 还挺好用的

56
00:01:43,333 --> 00:01:45,000
但是 Kibana 你得自己部署

57
00:01:45,000 --> 00:01:46,300
是不是也挺麻烦的

58
00:01:46,333 --> 00:01:48,666
你还要部署 ES 之类的东西

59
00:01:48,666 --> 00:01:49,966
当这个量级大的时候

60
00:01:50,033 --> 00:01:52,066
这个搜索也会成问题

61
00:01:52,133 --> 00:01:54,900
但是 Axiom 它的项目并不在于搜索

62
00:01:54,933 --> 00:01:55,833
你可以看到上面

63
00:01:55,833 --> 00:01:57,400
它是有很多的 query 

64
00:01:57,433 --> 00:01:58,833
你可以通过 query 的形式

65
00:01:58,833 --> 00:02:00,400
来去拉一些数据

66
00:02:00,433 --> 00:02:02,666
那也可以自己建 dashboard 

67
00:02:02,733 --> 00:02:03,966
甚至也可以做 monitor 

68
00:02:04,000 --> 00:02:05,066
当然这个 data set 

69
00:02:05,066 --> 00:02:07,433
就是我的两个服务

70
00:02:07,466 --> 00:02:09,033
我这些服务我觉得到这里

71
00:02:09,033 --> 00:02:10,100
只能把它当做

72
00:02:10,100 --> 00:02:11,733
一个普通的日志服务来看

73
00:02:11,800 --> 00:02:13,766
但是 现在是 AI 时代

74
00:02:13,800 --> 00:02:15,633
可以去尝试看一下这个 MCP 

75
00:02:15,666 --> 00:02:18,033
它就变得非常的有趣了

76
00:02:18,066 --> 00:02:19,833
在这个 MCP 集成的情况下

77
00:02:19,866 --> 00:02:21,600
你就可以去通过

78
00:02:21,600 --> 00:02:23,066
比如你自己的 Claude

79
00:02:23,066 --> 00:02:23,766
 

80
00:02:27,800 --> 00:02:29,733
对 你就可以拿自然语言来

81
00:02:29,733 --> 00:02:32,366
跟它说你的日志有没有什么问题

82
00:02:32,433 --> 00:02:33,666
让它来去处理

83
00:02:33,700 --> 00:02:35,500
可以看到它接上这个 MCP 之后

84
00:02:35,533 --> 00:02:37,733
它就可以去拿你的 coding agent 

85
00:02:37,733 --> 00:02:39,400
来直接的去聊

86
00:02:39,466 --> 00:02:41,533
然后拿到一些信息

87
00:02:41,600 --> 00:02:43,566
那有没有更闭环的一些的方案呢

88
00:02:43,600 --> 00:02:44,833
那完全是有的

89
00:02:44,866 --> 00:02:46,033
因为像是 Claude 

90
00:02:46,033 --> 00:02:48,166
它实际上你在 Claude 你配置一个 MCP 

91
00:02:48,233 --> 00:02:50,466
它可以在 Claude code 里边来去使用

92
00:02:50,500 --> 00:02:52,000
当把它给切到

93
00:02:52,000 --> 00:02:54,533
我们自己的代码项目里边的时候

94
00:02:54,600 --> 00:02:56,833
我们同样可以去执行

95
00:02:56,866 --> 00:02:58,900
比如说我这里可以看好 MCP 

96
00:02:58,933 --> 00:03:00,466
那这里可以看到

97
00:03:00,466 --> 00:03:03,966
MCP Axiom 的 MCP Server 

98
00:03:03,966 --> 00:03:05,433
 已经连在了这里

99
00:03:05,500 --> 00:03:08,100
那它就可以自主的帮我去完成

100
00:03:08,100 --> 00:03:09,966
这样找错误日志

101
00:03:10,033 --> 00:03:11,300
然后自动 bugfix 

102
00:03:11,333 --> 00:03:13,366
甚至说自己加日志的事情

103
00:03:13,433 --> 00:03:15,466
那有没有更进一步的 harness 呢

104
00:03:15,500 --> 00:03:16,200
是有的

105
00:03:16,266 --> 00:03:19,300
比如说我们可以切到 code 这边

106
00:03:19,333 --> 00:03:20,966
因为它其实有个 routine 

107
00:03:21,033 --> 00:03:22,600
那之前我们也介绍过

108
00:03:22,633 --> 00:03:23,933
那在这个 routine 里边

109
00:03:23,933 --> 00:03:27,633
我们可以去调用 Axiom MCP Server 

110
00:03:27,666 --> 00:03:29,100
让它来去定期的

111
00:03:29,133 --> 00:03:30,700
比如说每天

112
00:03:30,700 --> 00:03:33,300
来去拉一些最新的生产上面的日志

113
00:03:33,333 --> 00:03:34,400
来去查一些问题

114
00:03:34,466 --> 00:03:36,033
来去处理一些问题

115
00:03:36,066 --> 00:03:38,300
它也是完完全全可以做到

116
00:03:38,333 --> 00:03:42,333
那有没有更进一步的 Harness 方案呢

117
00:03:42,400 --> 00:03:43,833
因为现在这个 routine 

118
00:03:43,833 --> 00:03:44,500
它是每天运行

119
00:03:44,533 --> 00:03:46,233
那最近其实我有在观察 

120
00:03:46,233 --> 00:03:47,900
 Superlog 这个项目

121
00:03:47,933 --> 00:03:48,966
Superlog 这个项目

122
00:03:48,966 --> 00:03:50,533
看起来它会更进一步

123
00:03:50,600 --> 00:03:52,300
对 Superlog 这个方案

124
00:03:52,300 --> 00:03:53,766
就看起来就更有意思了

125
00:03:53,800 --> 00:03:57,033
它会自主地去连接我们的代码仓库

126
00:03:57,066 --> 00:03:58,833
自主地去发 pull request

127
00:03:58,866 --> 00:03:59,600
但 Superlog 

128
00:03:59,600 --> 00:04:01,366
目前的 quota 量是比较少

129
00:04:01,433 --> 00:04:02,533
可以看我已经

130
00:04:02,533 --> 00:04:05,333
到了这个 free plan 的 limits

131
00:04:05,400 --> 00:04:07,300
所以我还在观察这个项目

132
00:04:07,333 --> 00:04:09,933
但大家有兴趣可以自己来去研究看一看

133
00:04:10,000 --> 00:04:13,066
我觉得 Superlog 这个方案还可以

134
00:04:13,100 --> 00:04:14,700
但只是我个人目前

135
00:04:14,700 --> 00:04:17,366
可能更倾向于 Axiom

136
00:04:17,433 --> 00:04:18,333
我觉得如果你自己

137
00:04:18,333 --> 00:04:20,200
有一些 hobby 的一些小项目

138
00:04:20,233 --> 00:04:22,633
一些用户量并没有那么大的项目

139
00:04:22,666 --> 00:04:24,066
你完全可以拿 Axiom 

140
00:04:24,066 --> 00:04:26,633
来去接入你的日志系统

141
00:04:26,666 --> 00:04:28,033
它也许可以去帮你

142
00:04:28,033 --> 00:04:29,766
更好的去维护你的项目

143
00:04:29,833 --> 00:04:30,233
OK 

144
00:04:30,266 --> 00:04:31,966
那我们今天的节目就到这里

145
00:04:32,033 --> 00:04:34,700
如果有什么更好的日志解决的管理方案

146
00:04:34,733 --> 00:04:36,066
或者说你对 Axiom 

147
00:04:36,066 --> 00:04:37,966
 这种日志服务的看法

148
00:04:38,033 --> 00:04:39,600
也欢迎在下面留言

149
00:04:39,633 --> 00:04:40,733
我们下期节目再见

150
00:04:40,800 --> 00:04:41,233
拜拜