背景 2020 年 12 月初，Kubernetes 在其最新的 Changelog 中宣布，自 Kubernetes 1.20 之后将弃用 Docker 作为容器运行时。 弃用 Docker 带来的，可能是一系列的改变，包括不限于： 容器镜像构建工具 容器 CLI 容器镜像仓库 容器运行时 专题文
背景 近期发现自己实验用的 Prometheus 性能出现瓶颈, 经常会出现如下告警: PrometheusMissingRuleEvaluations PrometheusRuleFailures 之后慢慢排查发现是由于 Prometheus 的某些 series 的高基数(High Cardin
背景 前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失（页面上显示不出来）。 一个是应用基础信息丢失。 再一个是应用 JVM 数据丢失。 接口维度的监控数据丢失。 修复 基础信息 首先是第一个基础信息丢失的问题，页面上其实显示的是我们的一个聚合指标istio_re
背景 今天收到业务团队反馈线上有个应用往 Pulsar 中发送消息失败了，经过日志查看得知是发送消息时候抛出了 java.lang.InterruptedException 异常。 和业务沟通后得知是在一个 gRPC 接口中触发的消息发送，大约持续了半个小时的异常后便恢复正常了，这是整个问题的背景。
背景 最近真是和 Pulsar 杠上了，业务团队反馈说是线上有个应用消息重复消费。 而且在测试环境是可以稳定复现的，根据经验来看一般能稳定复现的都比较好解决。 定位问题 接着便是定位问题了，根据之前的经验让业务按照这几种情况先排查一下： 通过排查：1,2可以排除了。 没有相关日志 存在异常，但最外层
背景 最近接手维护了公司的指标监控系统，之后踩到坑就没站起来过。。 本次问题的起因是我们配置了一些指标的删除策略没有生效： - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum" 与这两个容易引
背景 前段时间业务研发反馈说是他的应用内存使用率很高，导致频繁的重启，让我排查下是怎么回事； 在这之前我也没怎么在意过这个问题，正好这次排查分析的过程做一个记录。 首先我查看了监控面板里的 Pod 监控： 发现确实是快满了，而此时去查看应用的 JVM 占用情况却只有30%左右；说明并不是应用内存满了
背景 前两章中我们将应用部署到了 k8s 中，同时不同的服务之间也可以通过 service 进行调用，现在还有一个步骤就是将我们的应用暴露到公网，并提供域名的访问。 这一步类似于我们以前配置 Nginx 和绑定域名，提供这个能力的服务在 k8s 中成为 Ingress。 通过这个描述其实也能看出 I
背景 前段时间给 VictoriaLogs 提交了一个 PR： https://github.com/VictoriaMetrics/VictoriaMetrics/pull/4934 本来一切都很顺利，只等合并了，但在临门一脚的时候社区维护人员问我可否给 git commit 加上签名。 于是我就
背景 最近有一个需求需要自定义一个多继承abc.ABC与django.contrib.admin.ModelAdmin两个父类的抽象子类，方便不同模块复用大部分代码，同时强制必须实现所有抽象方法，没想按想当然的写法实现多继承时，居然报错metaclass conflict： In [1]: impo
背景 之前在一次不规范HTTP请求引发的nginx响应400问题分析与解决 中写过客户端query参数未urlencode导致的400问题，当时的结论是： 对于query参数带空格的请求，由于其不符合HTTP规范，golang的net/http库无法识别会直接报错400，而nginx和使用uwsgi
背景 最近有个业务场景需要服务端(简称S)与客户端(简称C)设计一套基于UDP的通信协议--要求尽可能快的前提下可容忍一定丢包率，得以比较深入地学习和了解UDP通信和实践，在开发调试期间先后碰到了C端UDP发包无响应、响应Host Unreachable、响应Port Unreachable、再次C
背景 作为程序员，应该都听说过NAT(Network Address Transfer，网络地址转换)这一技术名词，并或多或少大概知道其原理与作用--NAT是用于解决IPv4地址不够用，保证我们能够在IPv6普及前依然可以正常使用互联网而广泛使用的一个技术，其原理正如其名称所示：其可以将私网IP通过
背景 最近接触docker的网络配置方式，发现其默认会创建一个docker0的Linux Bridge，宿主机上运行的容器可以通过连接该birdge实现与外网的通信，根据bridge这个命名很自然的认为这就是一个传统意义上的硬件网桥的软件实现，然而进一步探究后发现并非如此，Linux Bridge其
背景 一个安静的晚上，突然接到小伙伴电话线上CDN回源异常，具体表现为请求量飙升，且伴有少量请求404，其中回源请求量飙升已经持续两天但一直未被发现，直到最近404请求触发了告警后分析log才同时发现回源量飙升这一问题。 触发问题的原因很快被发现并修复上线，这里分享一下跟进过程中进一步学习到的CDN
背景 nginx 499在服务端推送流量高峰期长期以来都是存在的，间或还能达到告警阈值触发一小波告警，但主观上一直认为499是客户端主动断开，可能和推送高峰期的用户打开推送后很快杀死app有关，没有进一步探究问题根源。 然而近期在非高峰期也存在499超过告警阈值的偶发情况，多的时候一天几次，少的时候
## 背景 最近一组业务redis数据不断增长需要扩容内存，而扩容内存则需要重启云主机，在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障，这里记录分享一下。 ## 业务redis高可用架构 该组业务redis使用的是一主一从，通过sentinel集群实现故障时的自动主
## 背景 线上启用memcached(以下简称mc)作为热点缓存组件已经多年，其稳定性和性能都经历住了考验，这里记录一下踩过的几个坑。 ## 大key存储 某年某月某日，观察mysql的读库CPU占比有些异常偏高，去check慢查询log，发现部分应有缓存的慢sql居然存在几秒执行一次情况，不符合
## 背景 最近有一个业务场景需要用Python自行实现一个简单的LRU cache，不可避免的接触到了弱引用这一概念，这里记录一下。 ## 强引用 Python内存回收由垃圾回收器自动管理，当一个对象的引用计数归0时，其内存就可能被回收掉，而引用计数器的数值其实就是代表有多少个强引用指向该对象，我
## 背景 近期一个大版本上线后，Python编写的api主服务使用内存有较明显上升，服务重启后数小时就会触发机器的90%内存占用告警，分析后发现了本地cache不当使用导致的一个内存泄露问题，这里记录一下分析过程。 ## 问题分析 ### LocalCache实现分析 该cache大概实现代码如下
