受到 我写了一个堪称愚蠢的小工具 鼓舞,遂决定把 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
zapper 128 天前
赶早不如赶巧,刚好要用到,喂到嘴边了
|
2
Anakin078 128 天前
nc -lvvp 8000
|
3
adrianzhang 128 天前
请把你的愚蠢小工具都放出来看看。
|
4
lizhisty 128 天前
@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 老哥,这个命令似乎不行啊 |
5
shuxhan 128 天前 1
挺有意思的
|
6
amet OP @adrianzhang 你好,帖子中的[“一堆”]( https://yufanonsoftware.me/make) 是一个超链接。不过我觉得这些工具里最蠢的莫过于 [ddrpa/chainsaw]( https://github.com/ddrpa/chainsaw),是用来解决 `nohup *** > app.log 2>&1 &` 问题的。
|
7
amet OP @Anakin078 我一开始也是用的 netcat ,不过后面希望做到一种“中间人”的效果,即这个请求能被打印出来,同时还能继续被发送到原本的目的地去。顺便还做了点输出结果美化的工作。
|
8
amet OP @lizhisty 看起来像是 9999 端口已经被原程序占用了?你可以让 netcat 换一个监听端口,然后,如果使用 NGINX 的话,可以使用 location 配合 proxy_pass 让请求被转发到 netcat 那里去。
|
9
lsk569937453 128 天前
https://github.com/lsk569937453/local-echo-server 。花了一个小时撸了一个 rust 版本的,欢迎大家使用。
|
10
adrianzhang 128 天前
@amet 都挺好玩的小玩意。顺带提一嘴,日志处理的实践,基本上都是传专门的日志服务器,很少会在本地生成几个 GB 的日志。你这个工具适用于不规范的 dev 环境,stg&prod 中没有使用场景。如果发现你这个工具有很多人经常用,那说明出了大问题。
|
11
adrianzhang 128 天前 2
@lsk569937453 卷的起飞
|
12
catsoul 127 天前 1
说实话我就喜欢这些 simple stupid tools ( simple stupid 是说用 tool 的人)
|
13
abolast 127 天前
看起来 op 也是运维
|
14
amet OP @adrianzhang 还有广大的软件开发市场是由中小规模的公司瓜分的,这些公司承接的项目(甚至包括我见过的一些重要的城市基础设施),如果从最佳实践的角度来看(只是看了点 HN 、Thoughtworks 什么的,不敢妄言),确实是十分惊险的。做到那些(不管是日志还是其他)需要:
1. 项目达到一定规模,时间和金钱能够覆盖这样做的成本 2. 业主、项目负责人等能够理解这样做的意图 3. 开发人员认识到这样做的必要性 还有些其他什么七七八八的原因,只能说这条路还有些漫长。 我不能阻止人们把灯泡放进嘴巴里,但是可以做个方便把灯泡取出来的工具(这个比喻有点不恰当,但也差不多意思了)。 好在从我目前的处境来看,2 和 3 多少是比较可行的,所以我也在 README.md 里说了,看到谁再“整活”就“揍”他。 |
15
adrianzhang 127 天前
@amet 不,并不是这样。日志集中分析处理是互联网标配,证据就是 ELK 等工具的流行,另一个逻辑证据是,应用的日志分析是版本升级等功能的基础,也是商业分析基础数据。所以,除非是特别不正经的网络公司(不靠互联网用户挣钱的公司),都应该实行日志集中处理与分析。
|
16
Jeremial 127 天前 1
可以看看 traefik/whoami 这个, docker 部署很方便.
还支持各种选项 |
17
ZColin 127 天前 1
|
18
amet OP @adrianzhang 感谢你的回复,不过我的论点基于「广大的软件开发市场」而不是「互联网产品」。
社交 APP 是软件,负责收取停车费用的也是软件,监测传感器群的也是软件,后者一般不需要各种分析来决定下一步怎么走,它们最主要目的是记录和重建已经发生的问题,避免重蹈覆辙。 如果你建设一个日志服务平台或采购云服务,用户(业主)就会问「为什么我的数据要传输到互联网上/通过互联网发送到你这里?」。如果你为每个软件项目创建自己的,比如 ELK 这样经典而又基础的服务,也许会发现相比于要解决的问题,有时它们占用了太多的资源。 |
19
adrianzhang 127 天前
@amet 我不明白你为什么一定觉得我不知道离线软件和在线软件。你非要证明你的软件有用武之地前景广阔??
|
20
adrianzhang 127 天前
@amet 你告诉我有多少离线软件市场需要处理本地几个 GB 的日志?占离线软件绝对份额的低功耗设备本身存储容量就不大。其他都是在线软件的天下,而且智能化趋势都看懂了,未来完全离线的市场只会越来越小。
|
21
amet OP @adrianzhang 不好意思,之前我将你的 #15 回复理解为「因为汽车工业很发达了,所以道路设施不必考虑自行车」这种论调,此外我还见过一些夸夸其谈的「互联网」开发者,可能不自觉将你带入了。
如果我的理解有偏差,我先道歉。 我不知道之前的发言是否有让你产生一种没见过世面(确实,这个我承认)或是老顽固或是傲慢的感觉。我玩票的项目里,技术方案第一件事就是考虑能不能 Serverless 。集中式日志、CI/CD 、对象存储,以及非实体层面的开发规范、设计准则什么的,相信我,我能够拍板的地方,如果有助于提高 生产效率(开发、运维、运营工作) / 系统稳定性(可用服务时间、可维护性) / 用户满意度,是一定会使用的。 我的 #14 和 #18 观点来自我的工作经历。将这种「不正经」视为了常态现象,有一些心理预期,就好像多雨地区生活久了的人不管在哪里,出门都会习惯带伞而不是太阳镜一样。 此外我并没有觉得这个小工具应该有什么「广阔前景」,这也是为什么我称其为“最愚蠢”和开篇就说「希望没人会用到」这种话的原因。 后面的评论我也一并回复,我确实见过 4GB+ 的不连接互联网(或者说在某种程度上禁止将这些信息通过互联网传输)的系统产生的日志。这个系统不由我负责设计/实现,后续也与我没有瓜葛,我只是当时帮忙看看问题并写了 chainsaw 提供点帮助而已,我的团队如果产生了这种问题,就会被我喷 X 。 万物在线互联的愿景很好,也许很快就会到来,但是在那之前肯定是有问题解决问题,总不能干等着吧。 |
22
caoyang5689 127 天前 1
确实有意思, 在开发中还是很实用和有价值的。
|
23
adrianzhang 127 天前 1
@amet #21
我跟你交流一直不够顺畅的原因在于,你总是用身边统计学证明合理性,而我在告诉你一个更高的视角,更广阔的视角去看待这个工具所处的市场。你的自我否定看似用一个所谓的“愚蠢”标题就表达了,但你对我的回复字里行间都透露着 bonding in your previous view ,一直在告诉我身边统计学是什么什么样子,你真的在第一时间就自我否定后看看别人的建议了吗?拜托!你得好好想想自己为什么要去否定别人而不是仔细看看别人的视角。恕我直言,你这种沟通方式十有八九是因为内心的自卑。 顺便告诉你,国内著名运营商我待过,著名投行我待过,著名互联网公司待过,著名顶级外企也待过,著名大型风口国企集团我也待过。从我所经历的一切看,你#21 描述见过的那点东西只是沧海一粟。国内著名运营商里面也有大把的系统就是这么烂,就是有大量日志存在本地,但这是不规范!再说一遍,不规范!不利于商业不利于运营。存在即合理说的是,因为有历史原因所以它存在,但并不是说现存的一切就该保持原样继续不规范下去。你有开发这个软件并继续跟我较劲的功夫和时间,不如去想想怎么规范运营你的业务,从我的经验中学到点什么。 |