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

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 能找回自己,积极学习感兴趣的技术,保持空杯的心态。就这样啦,今天又是早下班失败的一天!

  • 买定离手,落子无悔,我在哪里,我的背后就是退路。
  • 能用金解决的事情,就别用人情,能用汗水解决的问题,就别用眼泪。
  • 人们总是把那条没有选择的路想象得开满鲜花。
相关推荐
代码吐槽菌2 小时前
基于SSM的毕业论文管理系统【附源码】
java·开发语言·数据库·后端·ssm
豌豆花下猫2 小时前
Python 潮流周刊#78:async/await 是糟糕的设计(摘要)
后端·python·ai
YMWM_2 小时前
第一章 Go语言简介
开发语言·后端·golang
码蜂窝编程官方2 小时前
【含开题报告+文档+PPT+源码】基于SpringBoot+Vue的虎鲸旅游攻略网的设计与实现
java·vue.js·spring boot·后端·spring·旅游
hummhumm3 小时前
第 25 章 - Golang 项目结构
java·开发语言·前端·后端·python·elasticsearch·golang
J老熊3 小时前
JavaFX:简介、使用场景、常见问题及对比其他框架分析
java·开发语言·后端·面试·系统架构·软件工程
AuroraI'ncoding3 小时前
时间请求参数、响应
java·后端·spring
好奇的菜鸟3 小时前
Go语言中的引用类型:指针与传递机制
开发语言·后端·golang
Alive~o.03 小时前
Go语言进阶&依赖管理
开发语言·后端·golang
许苑向上3 小时前
Dubbo集成SpringBoot实现远程服务调用
spring boot·后端·dubbo