瞎逼逼:谈谈容器日志采集

本文为日志采集漫谈,并不涉及技术选型,没有开源产品比对,望周知。

因为我并不是日志采集系统的开发人员,本文现学现炒,班门弄斧,如有问题欢迎留言(轻喷)。

故事还得从本周我搞了个 panic 开始说起,在我发布失败要排查为什么失败了时,我惊讶的发现我竟然要上容器才能看到 panic 日志,我工作这么久还是很少见到这种场面的,经过和基建同学的深入畅谈,我要上容器这件事情合不合理抛开不谈,但我意识到,虽然大家都有日志采集,但似乎每家公司的实现却都略有差异,因此今天就来讲讲关于日志采集的一些个人想法。

在过去的文章中,我们提到过好几次关于系统的稳定性建设,而稳定性建设的第一步,就是要采集数据,关于采集数据的每一个环节,我们都可以花很多篇幅去讲解,今天我们要介绍的「日志(Log)」就是其中的一环。(另外两个重要的方向是「链路追踪(Trace)」和「度量(Metrics)」)

- 阅读剩余部分 -

瞎逼逼:研发效能度量的得与失

之前曾经说过关于更新成本较大,之后如果有一些只是思考而不是落地实践后验证的产物的话更新可能会快一点,因此有了本期——以后就叫「瞎逼逼」系列了。

「瞎逼逼」系列不严谨,只是个人的一些简单粗暴学习后的粗浅的看法,请注意。

故事开始:工时计件制

众所周知,程序员不是一个计件工种,但程序员的工资又高,因此,老板们总得有一个考核办法,能够让牛马们心悦诚服的接受自己的工作成果。

最低端的不懂技术的老板,会像工厂组长那样,研究一个程序员每天的打卡时间:这个公式可能是「下班时间 - 上班时间 - 午休时间 = 工作时长 = 你对工作的上心程度」,如果粒度更细的话,可以计算你每次进出门的打卡记录差值,也可以在厕所装上计时器,再完美的扣除「带薪拉屎」的时间。

- 阅读剩余部分 -

2023 Web 开发年度观察报告

本来并不是很想写这类文章,很明显我这几年所有文章都聚焦在解决方案和落地经验,因此大家也可以看出,这是篇《有背景》的文章——当我接到这个需求的时候,我数了数我去年写的七篇文章,和行业趋势有个半毛钱关系。——此处插入一首阳光开朗大男孩。
本文不含娱乐圈八卦,但可能带主观吐槽,此外由于对文中提到的内容并没有深入理解,可能会有失偏颇,关注点和选材也多为「本人」感兴趣的部分,如果有误请各位大佬轻喷指正。
本人不跟风任何热点,纯属观众,能把这篇文章写完已经实属不易了(抹泪)。

年度数据观察

在全部开始之前,首先向大家推荐下几个我每年都会看的年度统计报表,主打凑个热闹:

当然,Golang 也有自己的 H2 统计:https://go.dev/blog/survey2023-h2-results

这些统计可以帮助你更好的了解到行业画像和最新热度,即使不怎么追新也可以在最短的时间在这些报告中了解到一些本来可能不认识的技术点。

- 阅读剩余部分 -

禁用第三方 Cookie 战记:我的第三方 Cookie 怎么办

本文适用人群:受到第三方 Cookie 影响,想要一些第三方 Cookie 解决方案的战友

本文可能会是我插图最多的文章之一,因为要解释清楚各种概念,可能需要引用很多张图片辅助消化。

尽管 Google 在 2022 / 2023 疯狂铺垫自己要禁用第三方 Cookie,大家马上改造,但实际上大部分人的工作还是在死线前后死亡冲刺。Google 官方宣称禁用第三方 Cookie 是为了「减少跨网站跟踪,同时确保让每个人都能免费访问在线内容和服务的功能」,但实际上好处还没感受到,却带来了一大堆麻烦。

Story Start

- 阅读剩余部分 -

DNS 科普·DNS 安全

上回我们说到 DNS 的基本知识以及 DNS 劫持的科普,那么 DNS 安全上又有哪些措施呢?

加密通信

如同 HTTP 通信一样,默认的 DNS 查询同样也是明文的,那么必然也可能遭受到攻击,比如下图中表示了一次中间人攻击(图源 cloudflare):

dns-traffic-unsecured.jpg
那么同样的,我们也可以通过加密流量的方式来保证数据的可靠性。对于 DNS 来说,主要有 DoT 和 DoH 两种。

- 阅读剩余部分 -

DNS 科普·从 DNS 到 DNS 劫持

本文为科普向,文字描述较为浅显易懂,不适合想要深入了解的读者。

Get Started

在了解 DNS 劫持是怎么进行之前,我们需要先了解 DNS 是怎么进行的。这里回到一道经典的面试题:

当你在浏览器里输入 www.baidu.com 时做了哪些事情?

这道题之所以经典,是因为千人千面,你能从「前端」、「后端」、「运维」、「Devops」这几种工种中得到截然不同的答案。

而今天讨论的就是这个问题的第一步:「DNS」。

- 阅读剩余部分 -

由黑转白——群晖的最后一次折腾

折腾群晖以来写过了好几篇文章,这次买了白群晖,因此这应该是黑群晖的最后一篇文章了,故事是这样的。

16883043150658.jpg

痛定思痛,连夜买了个白群晖——痛,非常痛,为双十一刚过而扭曲变形。从 PDD 买了 923+。

下文会介绍:

  • 我是怎么把黑群晖修好的
  • 怎么把黑群晖升级到 7.2
  • 为什么买了 923+,数据迁移
  • 周边设备

- 阅读剩余部分 -

从接口设计看分层微服务架构

故事的背景来源于,今天产品提了一个需求:对某个模块更新了一种文案,理论上来说,其实这是一个 k-v 结构,比如我有一个 getTexts 接口,返回如下:

[
    { title: '你好', desc: '世界' },
    { title: '效果不错', desc: '追加一条' } // 本次追加
]

- 阅读剩余部分 -

聊聊系统设计中的缓存

好久没更新了,本来想更新《前端是不是真的死了》,但是正好工作中发生了一些讨论,所以就改成先更新缓存了。
本文适宜对象:不太常设计缓存的各类工程师。

背景故事

今日的一个场景是:有一段国家信息数据,结构大概是:[{ region: 'CN', code: 12345, text: '中国' }] 这样的一个国家数组(实际字段不太一样),而在此之前这段信息存储在了一个提供给前端的外部接口中,你是一个提供给前端的 BFF,想基于这些数据进行二次处理。

- 阅读剩余部分 -

对于前端测试的一点杂谈

之前本来在 12 月就应该写这一篇文章的,大致是同事需要做 SDK 开发,我要求必须要有对应测试,但对于怎么去设计测试比较迷茫,本来早在 19 年就写过一篇如何构造一些有意义的测试,但从某种角度来说这更偏后端一些,对于前端的测试来说有一些不同。
然后被裁了,本来不想写了,但之前帮做模拟面试以及被面试时其实都有提到一些内容,所以这里简单谈下我对前端测试的一些看法。
新读者注意:本人屁话较多,不喜勿喷,上角点叉。(我好脆弱啊哥哥.jpg)

什么时候我们需要测试

如果你的回答是:「当然是什么时候都需要测试」——那么恭喜你,你还没有接受过现实排期和业务的毒打(这里指的是国内互联网的情况)。

- 阅读剩余部分 -