Reficul

可能是由于高温的原因，前段时间我的 TrueNAS 的磁盘阵列挂了。 我的阵列由四块磁盘组成，采用了 Raid1+0 的架构，这样可以保证只要不同时挂掉 Mirror 中的两块磁盘，就不会丢失数据。但是这次我的阵列突然出现了 3 块磁盘同时 S.M.A.R.T 自检失败，其中两块磁盘出现了掉盘的情况。虽然好在掉盘情况没有同时发生在同一个 Mirror 之中，不过也是足够吓人了。虽然后面经过十分痛苦的控制变量后排除了磁盘问题，锁定是 SATA 线的问题（线换了两次都是坏的，也是够倒霉的）。 考虑到磁盘都在同一个机箱内，温度、掉电等异常情况都是同时发生的，即使采用了 RAID1 冗余数据也未必安全。

痛定思痛，考虑再把数据同步一份到云上做异地灾备就被提上了日程。这样的话，就算本地彻底玩完也可以从云上把数据重新恢复过来。考虑到本地已经采用了 RAID1+0 阵列，因此实际需要从云上恢复的概率很低了，所以灾备方案最首要考虑的是长期可延续性和性价比。这样的话，各家网盘首先因为未来运营上的不确定性排除掉了。在考虑性价比的话，就只需要找一家足够便宜的对象存储罢了。

这个过程中，踩了不少坑，希望能帮助到一些人。

kube-apiserver 莫名其妙报 KubeAPIErrorsHigh 告警，CPU/Memory/Disk 都是好的。结果一路查下去似乎进了不知道有多深的兔子洞，坑深到这个问题从 2018 年到至今都没有完成彻底的修复。爬了很多楼，过程中学到了一些东西，这个文章全当做一个记录，假如有其他倒霉蛋看到这边也碰到了这个问题，希望这个文章能帮助到你。

这是一个八九年前的真实故事，请原谅我的旧事重提。 2009年的初见之后的第3年，我选择了AFK。

之所以今天突然旧事重提，是因为看到有人对《阿甘正传》中阿甘突然选择了在某一天停止了持续几年的长跑的一则解读；又大抵是在因为距离上次删掉所有矫情文章封笔已经有13年了，这段时间内喷薄欲出的无病呻吟已经积攒到了一个程度吧。

0x00

本文旨在对如何设计监控方面提供一些意见性的指导和建议。

本文章翻译自Prometheus官方文档：Best Pratices-INSTRUMENTATION

Go是一门语法以Less is More为哲学的语言，以简单易学为设计目标，致力于写出比Java还千人一面的符合工程要求的语言。GC、没有泛型、简单到没有的错误处理等等，都使得我这种不会管理内存，智商跟不上泛型，只要Try就Catch不到的小学生能够每天拼接一下字符串，勉强过得了生活的样子。但是，不信任用户的同义词就是只信任自己：“不让你用是怕你搞砸，至于我？我怎么可能搞砸？”。为了方便那些Go Author，他们早就给自己开好了后门。但是这些技巧最大的作用就是茶余饭后的装逼资本了，毕竟在项目里用了很可能就被买腿了。但是话说回来，黑魔法一般作为禁招也能够帮你绝处逢生，离开你地球就停转，从而保住饭碗。

Golang是一门工程语言，语法元素很少很容易掌握。从而，只要不是太扯的人写出来的代码理应相差不大，并能够很快被人理解。泛型在现代编程语言中被广泛使用，这里不谈Go缺失泛型是否是一种糟糕的设计，纯粹前段时间在gvisor的代码中看见一种实现泛型的方式比较新奇，因此拿来记录一下。

Shodowsocks是一个小有名气的代理工具，主要致力于减小流量特征，从而达到GFW无法对其进行定向的封杀的目的。Shadowsocks有多种语言的实现，本着学习一下原理的心态，看了一下其用Go版本的实现细节。

在Golang的基础中我们知道在用append的时候，或者Slice底层数组小于需求容量的时候，Go会自动重新分配内存，随之带来的有一次值拷贝。在数据量小或函数调用不频繁的时候对性能的损失并不明显，但是如果在高频率调用或者数据量大的时候，性能损失不能忽略不计。

最近在碰到一个很奇怪的问题，Go get工具在下载golang.org/x/tools下源代码的时候总是失败，但是以前并没有这个问题。Chrome已经使用了Shadowsocks穿墙，但是直接访问这个URL后发现在显示Nothing to see here之后就跳转到了文档页面。本以为是Google Code关闭带来的影响。不过时间过去了一周，并没有改善，奇怪的是老外对此并没有哀嚎遍野。为此有必要看一下go get到底发生了啥了。

第二次开始填坑，没有压力真没有动力。老是觉得这样不行那样不行，直到To Do List的堆栈爆了还没动一点点，那还不如开始动手做。上次的进度是认识了实模式，并成功进入了32位模式下，启用了分段的内存管理，打开了保护模式，然后用指针操作了个Demo就草草结束了。