开发「定位线上问题」小工具总结-编程知识

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

文章目录

- 1. 写在最前面
- - 1.1 背景
  - 1.2 思路
- 2. 如何快速解决问题
- - 2.1 分析问题
  - 2.2 补救问题
  - - 2.2.1 思路
    - 2.2.2 实现
- 3. 碎碎念

1. 写在最前面

1.1 背景

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

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

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

1.2 思路

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

分析问题三步走：

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

修复问题小工具：

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

2. 如何快速解决问题

2.1 分析问题

解析全局唯一的 id

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

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

2.2 补救问题

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

2.2.1 思路

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

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 格式
```
cat billing.log  | grep success > data.csv
```

其次，写一个可以逐行读取 csv 日志的分析脚本

#!/bin/bashwhile IFS= read -r log_line; dotimestamp=$(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_unixecho $log_line# echo "时间差: $time_diff 秒"fi
done <data.csv