Prometheus 监控最佳实践
本文是 Prometheus 的一份文档，提供了一系列侵入代码做监控时的建议。
- 监控任何东西，能想到的。一个程序中的每个部分都至少有一些指标可以让我们看到它们工作地肿么样。
- 侵入代码的监控就跟日志一样，可以做到就在代码那个文件做初始化。
- 一般监控的东西可以是：
- 在线服务: 推荐采集的指标：qps/qpm, errors, latency. 如果有客户端可以在 c/s 两端都采集。
- 离线服务: 推荐采集的指标：in_progress_num, processed_num, last_processed_time. 如果系统不是一直都在工作，建议发心跳工作包给服务，服务简单处理下时间啊什么的，确保它是一直是响应着的。
- Batch Job：它可能只是一次性的任务。推荐使用 pushgateway 推数据给 prometheus。采集的指标可以是：运行了多久，每一步花了多久，什么时候结束，成功还是失败。如果这个 batch job 以固定频率运行，建议转成 offline-processing。
- Library: 推荐采集的指标 …
Poetry - 一种非常规的 Python 依赖管理工具
Poetry 项目借鉴 cargo/composer 的经验，在给 Python 配置元信息的时候，你只需要定义 pyproject.toml，使用相应的 poetry build, poetry publish 等命令可构建 wheel 并发布到 PyPI。
- 每次要写一个新的包，都要配 setup.py MANIFEST.in setup.cfg Pipfile 这些确实很烦人。不再需要写 setup.py 这个文件确实是个加分项。
- 跟 Pipfile 的区别：Pipefile 说白了就是 requirements.txt 的升级版，poetry 有更大的野心：想把所有项目元信息配置相关的部分都包揽了。
更新：
- 2018-04-20: 用一阵子再来反馈。
Helm Cheatsheet
本文是 Kubernetes 部署工具 Helm 的使用指南，描述了它的基本使用场景。
- 使用前提：
- 有 Kubernetes cluster，本地 kubectl 都配置好了可以连上需要的集群，可以使用
kubectl config current-context查看是否正确。 - minikube 不需要额外配置
- coreos 需要有 socat 安装。
- 有 Kubernetes cluster，本地 kubectl 都配置好了可以连上需要的集群，可以使用
- Helm init:
- 在 minikube 中使用 Helm 无所谓啦，用默认配置就成，没有安全方面的考量；否则是需要额外做一些安全方面的配置，例如 rbac，tls 等等。
- helm init 会在 k8s 中启动 tiller
- 重置 helm：
helm reset- helm …
The Kubernetes Helm Architecture
这篇文章简要地介绍了 Helm 的架构。
- Helm 打包，上传，安装，卸载，升级 Charts, Chart 可以被应用到 Kubernetes 集群上，创建出应用程序来。
- Helm 有最重要的 3 个概念：
- chart：创建程序所必须的信息。
- config：程序的配置。
- release：根据 chart+config 创建出来的运行实例。
- Helm 的 2 个组件：
- Helm Client：在本机做开发，管理仓库，以及发布 Chart。
- Tiller Server：运行在 cluster 中，可以跟 Kubernetes apiserver 通信，将 chart …
如何使用 Federation 管理多个 Kubernetes Clusters
这篇文档介绍了为什么以及如何使用 Federation 管理 Kubernetes 集群。
- 多个小集群联邦比一个大集群来的安全一些，俗话说鸡蛋不要放一个篮子。万一挂了一个 region，其它的还能正常运行。
- 资源可在集群间互相访问，简单来说，某个 deployment 可以在其它 clusters 里面。
- 自动帮你配好了 dns & load balancers，简单来说，一个域名的流量可以分派到多个 clusters 中的后端服务。
- 单个集群有节点上限，k8s v1.8 可以支持到 5000 个节点，使用联邦可以把这个数字乘上去。
- hybrid cloud: 一个集群用 google 家的，另一个集群用 amazon 家的。除了鸡蛋篮子这个考量，也有人不想锁死一家的技术。
- 一个 kubernetes cluster 建议在一个 az 中 …
Dapper - Google Tracing System
这篇论文介绍了 Google Tracing System 的架构和使用情况。Google 在 black-box 和 annotation 方案中选择了后者。它准确率更高，但也因海量数据引入维护复杂的问题。论文花了2/3的篇幅介绍系统的运行情况。Dapper 的维护团队说几乎所有的 Google 的生产环境的程序可能都植入了 Dapper。
- 这个系统使用一系列ID标记调用链，每个服务调用记录根节点ID，父节点ID，自身ID，主机，时间戳。用户请求是调用链的根节点。一次服务调用会有至少两次日志记录，开始+结束。
- 允许服务添加业务数据（注解）到日志（有个数限制）。
- 记开头的原因与服务器时间不同步有关。
- 追踪触发点：进程内的上下文有追踪容器，异步调用和同步调用使用两个公共的库，该两个库都保证异步调用上会带上追踪信息。
- 性能损耗：可以选择性地关停，或做采样。损耗非常低，不纳入采样 9 ns, 否则 40ns 左右 …
PyPI 切新版发生的事故报告
这个报告阐述了为什么 PyPI 切新版造成了一个半小时内 pip install 都失败的事故，又是一起测试时啥都好一上线就崩溃的案例。简单来说，本来打算所有 https://pypi.python.org/packages/.... 都切换到 https://files.pythonhosted.org/packages/...，但是发生了无限 302 跳转外加 404 外加 500；发生的原因是 pypi.python.org 到 pypi.org 的 CDN shielding 配置有问题，结果请求被转回了老服务，而老服务又有跳转到新服务的规则。紧急修复还造成了 500，404 等情况。龟叔 的评价是这篇写的真好懂。。。
顺便说个趣事，pypi 的故障让龟叔使出了 sudo …
如何快速写出一份架构文档
这份模板给出了软件架构文档的基本框架。
- 一般从 introduction 说起，把设计目标，设计的范围说清楚
- 然后把系统约束说清楚，有什么会制约当前的设计，未来会怎么改进
- 从经典的四视图切入系统设计：Use-Case View，Logical View，Process View，Deployment View。
- Use-Case: 说一些用例，这些用例最好能覆盖到所有的组件；这个视图能把各个视图串在一起
- Logical：软件如何在逻辑上分层，这一层还不考虑物理的分布
- Process：比较物理了，可以谈到进程，线程，节点，集群，或者时下比较流行的 Pod 等等。
- Deployment：如何部署应用，一般现在做 CI，CD 这块有很多现成的工具。
- 最后把可能的安全，性能等边角问题说清楚。
