feat(log): 为 sniff 增加一个 log 信息 (#3863)

[flowerinsnowdh]

添加了一个 sniffLog 字段到 log 中，允许它在嗅探到域名后输出一段日志

[someonewating]

牛，这个效率太高了。
把我提的feature request也贴在这里提供一些上下文信息: #3864

[flowerinsnowdh]

你们说有这个功能需求嘛，我不知道，总之我先提交个 PR 在这里，请大佬们判断

[Fangliding]

感觉有一些 break 比如这样的话snifflog默认被关闭了 当然可以改成loglevel=info或以上的时候自动打开这个选项 但是这样又会让log输出的地方改掉 当当然还可以选择要不要输出在access log里 但是这样又会多复杂度 也不好 log应该是诊断用途而后是审计 所以这种事最好还是别
显示origindest和protocol个人觉得可取 不过这个格式还可以改 现在是这样 有点奇怪

Destination tcp:104.26.12.31:80 sniffed: http1 -> ip.sb

而且ctx也没了

[flowerinsnowdh]

感觉有一些 break 比如这样的话snifflog默认被关闭了

确实，本以为向下兼容，结果忘了这一点

---

当然可以改成loglevel=info或以上的时候自动打开这个选项 但是这样又会让log输出的地方改掉

首先排除这种方法

---

当当然还可以选择要不要输出在access log里 但是这样又会多复杂度 也不好 log应该是诊断用途而后是审计 所以这种事最好还是别

我这次提交...好像就是解决这个问题来的来着...？

---

不过这个格式还可以改 现在是这样 有点奇怪

本来我也是奔着让几位核心大佬改改再合并的，忘记说了，我是我们组里写日志信息写得最烂的一个💦

这个得来个人帮忙改一下

---

那...考虑好采取哪种方法了吗？还有更好的见解嘛，还是说还需要更多人来讨论讨论

---

而且ctx也没了

好吧，说实话我才意识到那一堆信息是上下文，我一直以为那是 log 内部的内容，所以...弱弱地问一句，它很重要嘛，我还真不知道

[someonewating]

hi @Fangliding ，技术上我不懂，但从出发性上我可以补充一下。

诚然，我提这个feature request最开始是为了在grafana中统计特定url的访问次数。是出于审计目的。😃但设想一个诊断用途：在set up xray的过程中，我需要判断一个对某一url的请求是如何被xray处理的。这个时候如果能够看到url，将可以极大的提升log的可读性。否则我必须先自己把url对应的ip通过dns查询出来，然后再依照ip比较log记录。这首先带来了额外工作量，其次我认为另一个问题在于dns解析。xray有自己的dns处理机制，而有些url可能会被污染。我觉得会有一种可能性是客户机查询出的ip和xray查询出的ip不一致。

另外我明白你的“tproxy收到的是ip所以就显示ip”。这个feature request可能确实和设计理念有点不一致，但我还是觉得在log里看到url会对troubleshooting很有帮助。无论怎样，我都理解并支持你们的决定。

[yuhan6665]

我的观点：千万不要再加 log type 了 下次把 DNS log 类型也可以删掉
access log 可以加入更多信息 尽量不要开关选项 多一点日志不是大问题

[RPRX]

我的观点：千万不要再加 log type 了 下次把 DNS log 类型也可以删掉
access log 可以加入更多信息 尽量不要开关选项 多一点日志不是大问题

赞同，毕竟 Go 写的软件就该大道至简

[flowerinsnowdh]

我的观点：千万不要再加 log type 了 下次把 DNS log 类型也可以删掉 access log 可以加入更多信息 尽量不要开关选项 多一点日志不是大问题

不用结构不会冗余代码嘛，每次都要重复写日志内容嘛？

我是面向对象编程出身，眼下正式写类的好时节，往年在这个时节，我一个人半个月就能 new 出一千个对象，我想我们 XTLS 所有代码贡献者加在一起得有一千多人吧，要是把他们组织起来写类，两个月的时间，new 出一百万个对象，肯定没问题