基于 CAT 新增链路追踪和告警通知
CAT 是美团点评开源的实时应用监控平台，提供了 Tracsaction、Event、Problem、Business 等丰富的指标项。 在官方的 Issue 遇到以下几个问题： 能不能支持链路追踪？ 如何配置告警？ 能不能接入钉钉、飞书机器人推送？ 为什么 CAT 部署这么麻烦？ 基于上面的需求，笔者 fork 了官方最新的源码进行二次开发，并打包镜像到 Docker Hub，方便大家使用。 Github 地址：传送门 Docker Hub 地址：传送门 改造内容 新增链路追踪支持，您可以通过日志打印的 TraceId 查找整个请求路径的 HTTP 请求、RPC 调用、Log4j2 日志、SQL 语句和 Cache 执行耗时。 支持邮件、钉钉、微信、飞书机器人推送。不需要额外实现告警接口，直接开箱即用，您只需要在后台配置相关的 Token 即可。如下图，触发告警后，钉钉将推送相关信息，您可以点击 查看告警 触达异常堆栈，也可以点击 告警规则 设置告警阈值，避免多次干扰。 支持 Jira Software 自动录单。当生产故障触发告警时，自动录入 Jira Soft...
深入浅出 Elasticsearch：底层存储实现
基础知识Elasticsearch 是 Elastic Stack 核心的分布式搜索和分析引擎，底层使用 Lucene 存储引擎实现，对外提供 RESTful API，支持 JSON 接口和 DSL 查询。随着 Elastic 公司的发展，组成了 Elastic Stack，由 Logstash、Beats、Elasticsearch 和 Kibana 四大核心产品组成。 目前除了 Elasticsearch，开源的搜索引擎有： Apache Solr：Apache 开源，基于 Lucene 构建，依赖 Zookeeper 部署，相对 ES 部署、监控、多租户配置比较复杂。 OpenSearch：AWS 开源，承诺永久免费，基于 Elasticsearch 的分支版本，集成了 ES 和 Kibana 的全部功能。 ClickHouse：俄罗斯开源，支持 SQL 查询，提供丰富的数据分析功能，适用于 OLAP 场景，全文检索能力不如 Elasticsearch。 Doris：百度开源，支持 SQL 查询，适合实时 OLAP 场景，但社区活跃度和性能不如 Elasticsearch...
MySQL 存储 emoji 报错问题排查
问题描述我们使用 MySQL 在特定业务场景（帖子、评论、个人签名）存储 emoji 表情。Server 配置和建表语句统一使用 utf8mb4，仍然抛出如下错误：java.sql.SQLException: Incorrect string value: '\xF0\x9F\x92\x94' for column 'name' at row 1。 原因分析MySQL 的 utf8 编码最多支持 3 个字节，而 emoji 表情需要占用 4 个字节，在早期的版本并没有实现真正意义上的 utf8 字符集。MySQL 从 5.5.3 版本开始支持 utf8mb4 字符集。 我们检查了 Server 的版本和配置，确定字符集用的是 utf8mb4，也检查了客户端连接 Server 的参数，也没发现其他异常。 将代码部署到自建的 MySQL 环境，可以正常存储，但是部署到云数据库 MySQL，就会报错，基本上判断是云厂商配置的问题。 因云数据库的环境不支持在 Server 端配置 character-set-client-handshake 或者 init...
MySQL 时区相差 5 小时问题排查
问题描述最近经业务部门反馈，我们有个 APP 升级后，在 2023-01-09 22:47 发现，当前账号的最近登录时间为 2023-01-10 03:47，相差了 5 个小时。 第一轮排查：我们第一印象会认为是刚升级的代码出了问题，有可能是日期格式化没处理好，也有可能是 JSON 序列化没有指定时区，经过 Git diff 排查，我们并没有修改相关代码。 第二轮排查：可能是有人动了生产配置！排除了配置中心的改动，也检查了 K8s 的 Deployment 是否正确设置了 TZ=Asia/Shanghai，依然无果。 第三轮排查：提取线上部署的 jar，经过对比，我们发现 MySQL 驱动从原来的 5.1.45 升级到了 8.0.22 版本。 原因分析生产数据库的配置是 time_zone=SYSTEM（对应 system_time_zone=CST，CST 时区没有标准，我们在使用 Java 客户端连接默认会把 CST 解析为时区+3，也就是当时事故出现的 5 小时误差）。 应用配置连接数据库的 jdbc-url 没有显示设置时区。MySQL驱动如果升...
基于 Sentinel 新增规则存储和监控回看
Sentinel 是阿里巴巴开源的流量治理平台，提供了流量控制、熔断降级、系统负载保护、黑白名单访问控制等功能。 在实际的生产应用中，我们遇到以下几个问题： Sentinel 控制台不支持流控规则持久化，需要自行扩展。 Sentinel 控制台的监控数据只保存到内存中，只能查看近 5 分钟的数据。 基于上面的问题，笔者 fork 了官方最新的源码进行二次开发，并打包镜像到 Docker Hub，方便大家使用。 Github 地址：传送门 Docker Hub 地址：传送门 改造内容 新增流控规则持久化支持，适配 Apollo、Nacos、Zookeeper 等组件。 新增监控数据持久化机制，适配 InfluxDB、Kafka、Elasticsearch 等组件，您可以通过时间控制回看历史数据，如下图。 部署教程微调应用配置在实际的生产需求，Sentinel 保存的规则和监控是需要持久化落盘的，因此，您可以在 sentinel-dashboard/src/main/resources/application.properties 接入外部组件。 规则存储类型支持：me...
基于 Arthas 新增权限控制和服务发现
Arthas 是阿里巴巴开源的在线诊断工具，提供了 Dashboard 负载总览、Thread 线程占用、Stack 堆栈查看、Watch 性能观测等功能。 在实际的生产应用中，我们遇到以下几个问题： Arthas 控制台没有权限控制，一旦访问 IP 暴露，就有安全问题。 Arthas 控制台需要提前知道 AgentId 才能访问，不适合 K8s 扩容管理。 基于上面的问题，笔者 fork 了官方最新的源码进行二次开发，并打包镜像到 Docker Hub，方便大家使用。 Github 地址：传送门 Docker Hub 地址：传送门 改造内容 新增服务发现支持，自动获取接入的应用列表 IP 和端口，无须手动输入 AgentId。 新增权限控制机制，授权用户输入用户密码登录后，在控制台只能操作已授权的应用。 部署教程FatJar 部署执行 mvn clean package 打包成一个 fat jar，参考如下命令启动编译后的控制台。 1java -Dserver.port=8080 -jar target/arthas-tunnel-server.jar Dock...
NGINX Ingress 金丝雀发布实践
背景我们的系统建设初期，使用腾讯云 CLB 负载均衡实现蓝绿发布，由于 CLB 的设计只能绑定腾讯云 CVM 服务器，对于 Serverless 集群架构很不友好。为解决这个问题，笔者尝试在腾讯云部署 NGINX Ingress Controller 实现金丝雀发布。 目标探索 NGINX Ingress Controller 实现金丝雀发布。 部署准备 Nginx 测试用例部署 nginx-v1 和 nginx-v2 两个工作负载作为测试用例，使用 openresty/openresty:centos 作为基础镜像。 nginx-v1 部署代码片段如下。 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710...
CODING 持续部署实践
背景CODING 是腾讯云提供的云原生应用平台，提供了可视化的编排工具，支持 GitOps、CI/CD、Helm、Kubernetes 等云原生技术。笔者所在的公司使用 Jenkins 构建，由运维团队负责管理 CI/CD，效率低下，腾讯云给我们推广了这个产品，趁这个机会，笔者决定研究下 CODING。 目标探索 CODING 流水线使用，验证 CI/CD 能力。 实战以 演示工程 为例，使用 Maven 构建工具，目录结构如下。 123456789eden-demo-cola |_ .coding/ |_ Jenkinsfile # CODING 流水线脚本 |_ settings.xml # 自定义Maven 配置文件 |_ docker/ |_ Dockerfile # Docker 构建文件 |_ entrypoint.sh # Docker 容器启动脚本 |_ ... |_ pom.xml # Maven 构建文件 设置 Git 代码仓库由于笔者的项目主要托管在 Github，使用关联代码仓库完成构建。 ...
MySQL 从库同步延迟解决方案
问题描述MySQL 主库使用云厂商较高配置，规格为 32U 128G 2.5T，数据空间实际使用 1.5 T，日志空间使用 0.5T，如下图。 MySQL 从库通过 K8s 自行搭建，使用 MySQL 原生镜像，规格为 4U 24G。 由于两者配置差距太大，MySQL 从库经过出现同步延迟或者同步报错的现象，MySQL 从库的 my.cnf 配置如下。 12345678910111213141516171819202122232425262728[mysqld]server_id=服务器唯一标识# 服务器默认字符集character_set_server=utf8# 表名是否忽略大小写：0 表示区分大小写，1 表示不区分大小写，2 表示 Windows 下不区分大小写lower_case_table_names=1 # 启用事件调度器：1 表示启用，0 表示禁用。event_scheduler=1 # 最大并发连接数max_connections=10000# 允许的最大连续连接错误次数max_connect_errors=200# 错误日志中记录的最大错误条目数max_err...
