我也写了一个堪称愚蠢的小工具（用来打印接收到的 HTTP 请求）

[amet]

受到 我写了一个堪称愚蠢的小工具 鼓舞，遂决定把 23 年写的一个工具发出来，ddrpa/corgi 可以用来打印收到的 HTTP 请求。

这个工具本质上是对下面这段脚本的扩展：

listen_port () {
	while true
	do
		{
			echo -e 'HTTP/1.1 200 OK\r\n'
		} | nc -l -v $1
		echo '\r\n'
	done
}

支持的功能有：

$ ./corgi -h
usage: corgi [-h|--help] [-p|--port <integer>] [--max-printable-size <integer>]
             [--pretty] [--fetch "<value>"]

             Corgi HTTP Request Logger, version 1.1.0

Arguments:

  -h  --help                Print help information
  -p  --port                监听指定端口. Default: 8000
      --max-printable-size  请求体最大打印长度（ 0
                            表示不截断），JSON 和 URLEncoded
                            表单不受影响）. Default: 256
      --pretty              特定类型请求体输出美化
      --fetch               转发请求到指定地址

对接调试接口时，可以在代码有错误（或一行代码都没写）的情况下知道对方发送了什么。

效果演示（监听 8000 端口，打印收到的 HTTP 请求）：

$ ./corgi -p 8000 --pretty

2023/07/06 16:27:32 corgi is waiting on :8000
2023/07/06 16:27:38 POST /proxy?url=/iot/alipayApi/faceAuth/getAlipayUserInfo HTTP/1.1
RemoteAddr: [::1]:57382
Host: localhost:8000
cookie: Cookie_1=value
authorization: Bearer Igp5d444444444444444
user-agent: PostmanRuntime/7.32.3
accept: */*
accept-encoding: gzip, deflate, br
content-type: application/x-www-form-urlencoded
content-length: 98
postman-token: 9a00e0be-f921-4605-b2f3-b577c1e263c2
connection: keep-alive

payload={"username":"admin","password":"wecsnuigb43j@_f"}
method=PATCH

为什么说这个工具很愚蠢，因为：

1. 双方把对接文档写清楚，或使用 Swagger 之类的工具的话，就不需要这样调试了；
2. 我发现有的项目都进预发布环节了，才发现对接有误。因此这个工具是 Golang 编写的，方便直接从 GitHub Release 页面下载二进制文件到预发布环境；

要是您觉得这个小工具愚蠢的比较清澈的话，我还有一堆。

[zapper]

赶早不如赶巧，刚好要用到，喂到嘴边了

[Anakin078]

nc -lvvp 8000

[adrianzhang]

请把你的愚蠢小工具都放出来看看。

[lizhisty]

@Anakin078 root@VM-12-17-debian:~/LycheeServer/deploy/docker-compose# nc -lvvp 9999
retrying local 0.0.0.0:9999 : Address already in use
retrying local 0.0.0.0:9999 : Address already in use
retrying local 0.0.0.0:9999 : Address already in use


老哥，这个命令似乎不行啊

[shuxhan]

挺有意思的

[amet]

@adrianzhang 你好，帖子中的[“一堆”]( https://yufanonsoftware.me/make) 是一个超链接。不过我觉得这些工具里最蠢的莫过于 [ddrpa/chainsaw]( https://github.com/ddrpa/chainsaw)，是用来解决 `nohup *** > app.log 2>&1 &` 问题的。

[amet]

@Anakin078 我一开始也是用的 netcat ，不过后面希望做到一种“中间人”的效果，即这个请求能被打印出来，同时还能继续被发送到原本的目的地去。顺便还做了点输出结果美化的工作。

[amet]

@lizhisty 看起来像是 9999 端口已经被原程序占用了？你可以让 netcat 换一个监听端口，然后，如果使用 NGINX 的话，可以使用 location 配合 proxy_pass 让请求被转发到 netcat 那里去。

[lsk569937453]

https://github.com/lsk569937453/local-echo-server 。花了一个小时撸了一个 rust 版本的，欢迎大家使用。

[adrianzhang]

@amet 都挺好玩的小玩意。顺带提一嘴，日志处理的实践，基本上都是传专门的日志服务器，很少会在本地生成几个 GB 的日志。你这个工具适用于不规范的 dev 环境，stg&prod 中没有使用场景。如果发现你这个工具有很多人经常用，那说明出了大问题。

[adrianzhang]

@lsk569937453 卷的起飞

[catsoul]

说实话我就喜欢这些 simple stupid tools （ simple stupid 是说用 tool 的人）

[abolast]

看起来 op 也是运维

[amet]

@adrianzhang 还有广大的软件开发市场是由中小规模的公司瓜分的，这些公司承接的项目（甚至包括我见过的一些重要的城市基础设施），如果从最佳实践的角度来看（只是看了点 HN 、Thoughtworks 什么的，不敢妄言），确实是十分惊险的。做到那些（不管是日志还是其他）需要：

1. 项目达到一定规模，时间和金钱能够覆盖这样做的成本
2. 业主、项目负责人等能够理解这样做的意图
3. 开发人员认识到这样做的必要性

还有些其他什么七七八八的原因，只能说这条路还有些漫长。

我不能阻止人们把灯泡放进嘴巴里，但是可以做个方便把灯泡取出来的工具（这个比喻有点不恰当，但也差不多意思了）。

好在从我目前的处境来看，2 和 3 多少是比较可行的，所以我也在 README.md 里说了，看到谁再“整活”就“揍”他。

[adrianzhang]

@amet 不，并不是这样。日志集中分析处理是互联网标配，证据就是 ELK 等工具的流行，另一个逻辑证据是，应用的日志分析是版本升级等功能的基础，也是商业分析基础数据。所以，除非是特别不正经的网络公司（不靠互联网用户挣钱的公司），都应该实行日志集中处理与分析。

[Jeremial]

可以看看 traefik/whoami 这个, docker 部署很方便.
还支持各种选项

[ZColin]

好用爱用 多来点

[amet]

@adrianzhang 感谢你的回复，不过我的论点基于「广大的软件开发市场」而不是「互联网产品」。

社交 APP 是软件，负责收取停车费用的也是软件，监测传感器群的也是软件，后者一般不需要各种分析来决定下一步怎么走，它们最主要目的是记录和重建已经发生的问题，避免重蹈覆辙。

如果你建设一个日志服务平台或采购云服务，用户（业主）就会问「为什么我的数据要传输到互联网上/通过互联网发送到你这里？」。如果你为每个软件项目创建自己的，比如 ELK 这样经典而又基础的服务，也许会发现相比于要解决的问题，有时它们占用了太多的资源。

[adrianzhang]

@amet 我不明白你为什么一定觉得我不知道离线软件和在线软件。你非要证明你的软件有用武之地前景广阔？？

[adrianzhang]

@amet 你告诉我有多少离线软件市场需要处理本地几个 GB 的日志？占离线软件绝对份额的低功耗设备本身存储容量就不大。其他都是在线软件的天下，而且智能化趋势都看懂了，未来完全离线的市场只会越来越小。

[amet]

@adrianzhang 不好意思，之前我将你的 #15 回复理解为「因为汽车工业很发达了，所以道路设施不必考虑自行车」这种论调，此外我还见过一些夸夸其谈的「互联网」开发者，可能不自觉将你带入了。

如果我的理解有偏差，我先道歉。

我不知道之前的发言是否有让你产生一种没见过世面（确实，这个我承认）或是老顽固或是傲慢的感觉。我玩票的项目里，技术方案第一件事就是考虑能不能 Serverless 。集中式日志、CI/CD 、对象存储，以及非实体层面的开发规范、设计准则什么的，相信我，我能够拍板的地方，如果有助于提高 生产效率（开发、运维、运营工作） / 系统稳定性（可用服务时间、可维护性） / 用户满意度，是一定会使用的。

我的 #14 和 #18 观点来自我的工作经历。将这种「不正经」视为了常态现象，有一些心理预期，就好像多雨地区生活久了的人不管在哪里，出门都会习惯带伞而不是太阳镜一样。

此外我并没有觉得这个小工具应该有什么「广阔前景」，这也是为什么我称其为“最愚蠢”和开篇就说「希望没人会用到」这种话的原因。

后面的评论我也一并回复，我确实见过 4GB+ 的不连接互联网（或者说在某种程度上禁止将这些信息通过互联网传输）的系统产生的日志。这个系统不由我负责设计/实现，后续也与我没有瓜葛，我只是当时帮忙看看问题并写了 chainsaw 提供点帮助而已，我的团队如果产生了这种问题，就会被我喷 X 。

万物在线互联的愿景很好，也许很快就会到来，但是在那之前肯定是有问题解决问题，总不能干等着吧。

[caoyang5689]

确实有意思， 在开发中还是很实用和有价值的。

[adrianzhang]

@amet #21
我跟你交流一直不够顺畅的原因在于，你总是用身边统计学证明合理性，而我在告诉你一个更高的视角，更广阔的视角去看待这个工具所处的市场。你的自我否定看似用一个所谓的“愚蠢”标题就表达了，但你对我的回复字里行间都透露着 bonding in your previous view ，一直在告诉我身边统计学是什么什么样子，你真的在第一时间就自我否定后看看别人的建议了吗？拜托！你得好好想想自己为什么要去否定别人而不是仔细看看别人的视角。恕我直言，你这种沟通方式十有八九是因为内心的自卑。

顺便告诉你，国内著名运营商我待过，著名投行我待过，著名互联网公司待过，著名顶级外企也待过，著名大型风口国企集团我也待过。从我所经历的一切看，你#21 描述见过的那点东西只是沧海一粟。国内著名运营商里面也有大把的系统就是这么烂，就是有大量日志存在本地，但这是不规范！再说一遍，不规范！不利于商业不利于运营。存在即合理说的是，因为有历史原因所以它存在，但并不是说现存的一切就该保持原样继续不规范下去。你有开发这个软件并继续跟我较劲的功夫和时间，不如去想想怎么规范运营你的业务，从我的经验中学到点什么。