开发「定位线上问题」小工具总结

1. 写在最前面

1.1 背景

同事给处理各种线上问题以及处理紧急要交付的需求版本的我,紧急插入了一个线上的问题:

问题说明:发现从 2023.12.25 号开始,XX 产品上传的计费文件,偶现有超过 12 小时才进入计费存储系统。当前 XX 产品的计费逻辑为「超过 12h」,即忽略计费统计,简而言之,XX 产品已经有接近一个月的计费问题了!

注:XX 产品是一个正在处于打磨期的产品,无计费上报的监控链路、无集中日志存储、无计费服务维护人员,即一个计费「三无」产品

1.2 思路

本着「办法总比困难多的思路」,就算再难解决,作为接锅的人,也得想办法解决。

分析问题三步走:

  • 单个的日志文件可以解析出全局唯一的 id
  • 全局唯一的 id,可以定位出生成该文件的机器 ip
  • 定位问题 --- 机器的 ip 中上传日志的服务可以分析,出文件的生成时间和文件的上传时间

修复问题小工具:

  • 批量扫描线上所有机器,然后拉起被丢弃的日志文件,恢复数据。

2. 如何快速解决问题

2.1 分析问题

  • 解析全局唯一的 id
markdown 复制代码
> 注:开发小心得,为了避免给自己埋坑,在开发需要复杂解析的文件时,建议提供一个解析小工具!
  • 分析 id 所属机器
  • 发现计费侧反馈的文件,从 2024.01.11 ~ 2024.01.12 一直断断续续的有上传,并且已经超过了 12h

结论:仔细分析了计费的逻辑,发现根因是之前设计的上传触发逻辑有两种,一个当前时间大于文件最后更新时间的 10m ,一个是文件的大小需要大于 1M。而这个产生这个问题的客户使用的方式比较独特,他使计费文件的断断续续的有更新,且总大小仍然小于 1M。

2.2 修复问题

虽然计费出现了小插曲,但是该收的钱还是得收!但是由于野生的计费系统,没有办法查日志,想要分析从 2023.12.15 到 2024.1.17 号那些文件超过 12 小时上报了,这个问题就变成急需解决的问题了?

2.2.1 思路

遇事不要慌,沉着冷静的分析下,是否有什么规律可以看。日志上传成功的格式:

yaml 复制代码
2024-01-12 06:21:19 info billing_u: xxx serives upload file xyz_0_streamSubscription_1_1704991273078

分析如上日志,发现两个有效性

  • 2024-01-12 06:21:19 字段是文件上传的时间,北京时间
  • 1704991273078 字段是文件产生的时间,UTC 时间的时间戳

咦,将两个字段转化到相同的时区,然后比较不就可以得出产生到上传的时间的差值了嘛?这很有道理

2.2.2 实现

在 shell 上我就是个渣渣,不过,我有 chatgpt,快速入门 shell 不是梦。「只要你的问题描述的够精确,chatgpt 可以帮你解决 80% 的问题」

  • 首先,将待分析的文件中关心的日志上传成功的记录转成 csv 格式

    matlab 复制代码
    cat billing.log  | grep success > data.csv
  • 其次,写一个可以逐行读取 csv 日志的分析脚本

    bash 复制代码
    #!/bin/bash
    
    while IFS= read -r log_line; do
        timestamp=$(echo "$log_line" | awk '{print $1, $2}')
        number=$(echo "$log_line" | grep -oE '[0-9]+$')
        generateTime=$(($number / 1000))
    
        # 将时间戳转换为Unix时间戳
        timestamp_unix=$(TZ=UTC date -d "$timestamp" +%s)
    
        # 计算时间差
        time_diff=$((timestamp_unix - generateTime))
    
        if [ $time_diff -gt 43200 ]; then
            # 输出结果
            # echo $generateTime
            # echo $timestamp_unix
            echo $log_line
            # echo "时间差: $time_diff 秒"
        fi
    done <data.csv

    注:新学的 shell 语法如下,

    TZ=UTC date -d "$timestamp" +%s 将 2024-01-12 06:21:19 转成北京时间转为 UTC 的时间戳

    while IFS= read -r log_line; do

    ·····

    done <data.csv

  • 最后,使用运维执行脚本的工具逐个机器执行如上脚本拉取有问题的文件名。

执行效果如下图所示:

3. 碎碎念

2023 年忙着救火,再加上工作年限日益增加,开始变得有些倦怠了,希望 2024 能找回自己,积极学习感兴趣的技术,保持空杯的心态。就这样啦,今天又是早下班失败的一天!

  • 买定离手,落子无悔,我在哪里,我的背后就是退路。
  • 能用金解决的事情,就别用人情,能用汗水解决的问题,就别用眼泪。
  • 人们总是把那条没有选择的路想象得开满鲜花。
相关推荐
神奇小汤圆5 小时前
浅析二叉树、B树、B+树和MySQL索引底层原理
后端
文艺理科生5 小时前
Nginx 路径映射深度解析:从本地开发到生产交付的底层哲学
前端·后端·架构
千寻girling5 小时前
主管:”人家 Node 框架都用 Nest.js 了 , 你怎么还在用 Express ?“
前端·后端·面试
南极企鹅5 小时前
springBoot项目有几个端口
java·spring boot·后端
Luke君607975 小时前
Spring Flux方法总结
后端
define95275 小时前
高版本 MySQL 驱动的 DNS 陷阱
后端
忧郁的Mr.Li6 小时前
SpringBoot中实现多数据源配置
java·spring boot·后端
暮色妖娆丶7 小时前
SpringBoot 启动流程源码分析 ~ 它其实不复杂
spring boot·后端·spring
Coder_Boy_7 小时前
Deeplearning4j+ Spring Boot 电商用户复购预测案例中相关概念
java·人工智能·spring boot·后端·spring
Java后端的Ai之路7 小时前
【Spring全家桶】-一文弄懂Spring Cloud Gateway
java·后端·spring cloud·gateway