做黑盒监控引发的思考

经常听到运维前辈说到方法论这个词, 之前觉得很高深, 后来想想, 其实也就是经验多了, 把对某类事务的处理沉淀或者抽象为一种统一的方法. 就像下面我要说一个例子来讲一讲

线上有个基于gitlab二次开发的使用的模块要正式应用到公有云环境, 做为sre，如何对gitlab的clone --> commit --> push进行黑盒监控?

当然, 可以通过gitlab本身的一些性能指标进行采集分析, 但这些性能指标可能是分散的, 无法准确地反应clone –> commit –>push这条操作是否存在异常, 那么更好的办法就是模拟这3个操作, 不间断地对gitlab进行改操作, 如果gitlab在某个环节出现问题导致命令不成功, 则必然会产生报警.

监控目的

实现对gitlab的黑盒监控

实现流程

1. 在gitlab上新建一个监控使用git仓库, 用于不断操作
2. git clone该仓库, 验证是否正常
3. git add 一个时间戳文件, 然后使用git commit进行提示, 验证是否正常
4. git push到仓库, 验证是否正常

如果在预设的超时时间(当然，这个时间由运维根据情况而定, 跟gitlab性能有一定关系)内这几个步骤都没问题的话,那基本上可以说gitla服务是正常

伪代码

#!/bin/bash

cd "$(dirname $0)" || exit 1
WORKSPACE="$(pwd)"
GIT_URL="[email protected]"
TIME_OUT=5

function check_gitstatus(){
    start_time=$(date +%s)
    timeout $TIME_OUT \
    git clone $GIT_URL > $WORKSPACE/git_clone.log 2>&1 && \
    cd $WORKSPACE/code-commit-tpmonitor-auto && \
    [ -f $WORKSPACE/code-commit-tpmonitor-auto/timestamps.time ] && \
    gap=$(cat timestamps.time) && \
    echo ${start_time} > timestamps.time && \
    git add timestamps.time && \
    git commit -m "${start_time}" > $WORKSPACE/git_commit.log 2>&1 && \
    git push > $WORKSPACE/git_push.log 2>&1
    if [ "$?" -eq "0" ]; then
        echo "gap_time:$[${start_time}-${gap}]"
        echo "run_time:$[$(date +%s)-${start_time}]"
        rm -rf $WORKSPACE/code-commit-tpmonitor-auto 
        echo rnt:0
    else
        echo rnt:1
    fi
}

function main(){
    rm -rf $WORKSPACE/code-commit-tpmonitor-auto
    check_gitstatus
}

main "$@"

有人可能会好奇为何需要计算一个gap_time,这其实也是在监控gitlab的一个性能

想像这么一种情况, 使用git clone下来的文件如果不是我上一次push的, 那么其实也是有问题, 有可能是push虽然成功了, 但接着使用clone时发现clone下来的文件居然没有包含上次push的文件, 那么就有可能gitlab来不及处理海量的小文件导致出现性能问题.

通过计算一个gap_time是非常有必要了, 每一次都push一个文件, 这个文件非常简单, 只包含一行时间戳, 在下一次clone下来时用当前时间跟这个文件里的时间戳进行比较, 假如这个脚本每隔5分钟运行一次, 那么这个这个时间差值一定会在5分钟左右, 那么就可以添加一个报警规则: 这个时间差如果超过6分钟, 则说明有问题.

通过添加一个这样的监控脚本, 稳定运行一年多的时间内成功地提前发现了几次gitlab故障, 及时处理后并没有影响客户.

这里要注意一点的是, 开始这个脚本是每次都是新生成的时间戳文件, 一直都在push, 会造成这个仓库的文件越来越多, 因此时间久了之后, git clone的时间会变长, 出现过几次命令执行时间超过timeout的值而造成的误报, 而gitlab本身是没有问题的， 所以后来不提交新的文件, 从始至终仓库里只有一个文件, 文件内的时间戳不一样，就是现在的版本

另外还有一个使用的例子是线上的实时日志搜索模块的监控, 同样是采用了这个策略, 添加一个额外的时间戳字段来反应日志搜索是否达到实时.

另外, 黑盒监控还会使用到Prometheus的blackbox来做, 但如果是比较复杂的涉及多个业务流程的话, blackbox的支持还是比较难适配的, 所以blackbox一般都用在单一接口的监控上.

所以有时候是需要使用一种不常规的方式来配合做到业务稳定性, 方法论里面的思想还是很有帮助的.

参考文章:

转载请注明原作者: 周淑科(https://izsk.me)