Last Updated on 2025-02-16 by likun.gong

近几个月有点恍惚，回想一下好像没做什么，简单列一下做的内容

1. AWS CloudWatch 的告警触发，在告警不恢复的情况，默认不会再触发第二次，需要使用 Step Function 来定期检查状态，不恢复时再次通知
   https://aws.amazon.com/cn/blogs/china/use-aws-step-functions-to-implement-continuous-amazon-cloudwatch-alarms/
2. 告警聚合，避免告警轰炸，同时在告警方面，也要避免告警单点，或者要有对应的告警升级机制。告警升级机制也许是比较合理的，多人同时告警，可能会导致大家互相认为对方会处理
3. AWS CloudFront 迁移方案，新的 CloudFront 的域名可以用 *.example.com 替代的，它的匹配逻辑是先精确匹配，后续会模糊匹配
   https://aws.amazon.com/cn/blogs/china/smoothly-migrate-alternative-domain-names-to-other-accounts/
4. Gitlab CI 测试，大致了解了 Runner 的各种类型，当时一直被 Instance 类型的 Runner 迷惑，后续才发现 Instance 类型的 Runner 是在这个 Instance 上再通过 Docker Container 运行 Runner，而我的需求是把这个 EC2 变成 Runner，所以采用 ssh 类型就好了
   The instance executor is an autoscale-enabled executor that creates instances on demand to accommodate the expected volume of jobs that the runner manager processes.
5. AWS 成本根据 tag 来细分，需要在 cost 中配置对应的 tag 分账才会生效，默认是没有的
6. CloudWatch exporter 测试，用来获取所有队列的监控信息，Prometheus 再抓取数据，从而可以利用 PromQL 来实现比 CloudWatch 更复杂的告警语句
   我们想实现死信队列的消息数监控，并且队列名是变化的，使用 CloudWatch 一直没找到模糊查询的 SQL 写法
7. K8S 大型集群中，需要注意 CoreDNS 的性能和指标
8. 对于网关等关键入口，可以增加请求成功率的监控，这个指标能快速发现问题
9. Karpenter 组件的升级，v1.0 版本大调整，升级难度增加很多，但同时也增加了对 Karpenter 的熟悉
   IAM Role 的变更比较麻烦，安装的时候和官方啊的步骤有些差异，导致升级的难度增加
10. GitOps 实践，ArgoCD 安排上了