搜索到
36
篇与
的结果
-
基于OpenResty的版本灰度发布方案 OpenResty是Nginx加上Lua脚本引擎，可以实现很多复杂的逻辑。OpenResty学习曲线可能有点陡，但学会了之后真的很香。可以用Lua实现各种复杂的灰度策略，甚至可以对接公司的配置中心、监控系统等。案例：结合Lua实现动态灰度单纯使用nginx，会遇到一个问题，就是每次调整灰度比例都要修改配置文件，然后reload Nginx。这在生产环境其实挺麻烦的，万一配置写错了，reload失败，那就尴尬了。推荐方案是结合OpenResty（Nginx + Lua），把灰度规则存在Redis里，这样就可以动态调整了。upstream backend_v1 { server 192.168.1.10:8080; } upstream backend_v2 { server 192.168.1.11:8080; } server { listen 80; server_name api.example.com; location / { set $backend "backend_v1"; access_by_lua_block { local redis = require "resty.redis" local red = redis:new() red:set_timeout(1000) local ok, err = red:connect("127.0.0.1", 6379) if not ok then ngx.log(ngx.ERR, "failed to connect redis: ", err) return end -- 从Redis获取灰度比例 local canary_percent, err = red:get("canary:percent") if not canary_percent or canary_percent == ngx.null then canary_percent = 0 end -- 生成随机数判断是否走新版本 math.randomseed(ngx.now()) local rand = math.random(100) if rand <= tonumber(canary_percent) then ngx.var.backend = "backend_v2" end red:close() } proxy_pass http://$backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } 这样的话，我们只需要在Redis里修改canary:percent的值，就可以实时调整灰度比例了，不需要reload Nginx。 设置灰度比例为10%redis-cli set canary:percent 10逐步放量redis-cli set canary:percent 30redis-cli set canary:percent 50redis-cli set canary:percent 100紧急回滚redis-cli set canary:percent 0 -
ssh常见故障排查及解决措施 关键排查方法客户端调试: 使用 ssh -v 参数查看详细连接过程服务器日志: 检查 /var/log/secure 或 journalctl -u sshd 获取服务器端错误权限验证: 系统性检查文件和目录权限密钥验证: 使用 ssh-keygen -y 验证密钥对匹配性预防措施定期备份密钥: 避免密钥丢失导致无法访问使用现代密钥算法: 推荐使用 ED25519 而非 RSA保持权限正确: 使用自动化脚本定期检查关键文件权限启用多种认证方式: 配置密码认证作为备用方案监控 SSH 日志: 及时发现异常登录尝试常见 SSH 认证失败原因问题类型错误信息解决方法私钥权限过开放UNPROTECTED PRIVATE KEY FILEchmod 400 私钥文件主目录权限错误bad ownership or modeschmod 755 ~ + chown user:user ~.ssh 目录权限错误Authentication refusedchmod 700 ~/.sshauthorized_keys 权限错误认证失败无明确提示chmod 600 ~/.ssh/authorized_keys密钥算法不支持key type not in PubkeyAcceptedAlgorithms修改 sshd_config 启用算法密钥不匹配认证失败验证并更换正确的密钥对私钥文件权限问题错误信息: WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0644 for 'xxxxx.pem' are too open. 问题分析:私钥文件权限为 0644（所有用户可读）SSH 安全机制要求私钥文件仅所有者可访问解决措施: chmod 400 /home/test/xxxx.pem密钥匹配性验证排查步骤:确认正确的私钥文件路径验证私钥与服务器公钥是否匹配验证命令:# 本地生成公钥指纹 ssh-keygen -y -f /home/test/xxxx.pem # 服务器端查看授权公钥 cat /home/ec2-user/.ssh/authorized_keys服务器端配置问题定位查看服务器 SSH 日志 (/var/log/secure)，可以发现的两个关键错误：目录权限错误: Authentication refused: bad ownership or modes for directory /home/ec2-user 密钥算法不支持: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]原因1：用户主目录权限配置错误 问题详情:/home/ec2-user 目录的所有权或权限不符合 SSH 安全要求。SSH 要求用户主目录及 .ssh 目录必须有严格的权限控制。SSH 权限要求:用户主目录: 755 权限，所有者为用户本人.ssh 目录: 700 权限，所有者为用户本人authorized_keys 文件: 600 权限，所有者为用户本人原因2：SSH 服务器禁用了 RSA 算法 问题详情:服务器 SSH 配置中未包含 ssh-rsa 算法客户端使用的是 RSA 类型的密钥版本 OpenSSH (8.8+) 默认禁用了 SHA-1 相关的 RSA 算法解决方案#在服务器端以 root 用户执行： # 1. 修复 ec2-user 主目录权限 chown ec2-user:ec2-user /home/ec2-user chmod 755 /home/ec2-user # 2. 修复 .ssh 目录权限 chmod 700 /home/ec2-user/.ssh chmod 600 /home/ec2-user/.ssh/authorized_keys chown -R ec2-user:ec2-user /home/ec2-user/.ssh # 3. 启用 ssh-rsa 算法支持 echo "PubkeyAcceptedAlgorithms +ssh-rsa" >> /etc/ssh/sshd_config # 4. 重启 SSH 服务 systemctl restart sshd
-
rsync常用脚本案例分享 案例1：网站文件同步我们需要将本地开发的网站文件同步到生产服务器。（这招也可以用在云计算磁盘需要缩容的过程中，毕竟云硬盘，多开1G都是要花钱的，利用率最大化才是省钱王道）# 基本同步命令 rsync -avz --delete /var/www/html/ root@192.168.1.100:/var/www/html/ # 排除不需要同步的文件 rsync -avz --delete \ --exclude='*.log' \ --exclude='cache/' \ --exclude='.git/' \ /var/www/html/ root@192.168.1.100:/var/www/html/这个命令会：递归同步整个网站目录保持文件属性和时间戳压缩传输数据删除目标目录中多余的文件排除日志文件、缓存目录和Git仓库案例2：数据库备份同步对于数据库备份文件的异地同步，我们通常需要更谨慎的处理。#!/bin/bash # 数据库备份同步脚本 BACKUP_DIR="/backup/mysql" REMOTE_HOST="backup-server.company.com" REMOTE_DIR="/data/mysql-backup" LOG_FILE="/var/log/backup-sync.log" # 执行同步 rsync -avz --progress \ --log-file=$LOG_FILE \ --timeout=300 \ --bwlimit=10000 \ $BACKUP_DIR/ root@$REMOTE_HOST:$REMOTE_DIR/ # 检查同步结果 if [ $? -eq 0 ]; then echo "$(date): 备份同步成功" >> $LOG_FILE else echo "$(date): 备份同步失败" >> $LOG_FILE # 发送告警邮件 echo "备份同步失败，请检查" | mail -s "备份告警" admin@company.com fi案例3：配置文件分发在集群环境中，经常需要将配置文件分发到多台服务器。#!/bin/bash # 配置文件分发脚本 CONFIG_DIR="/etc/app-config" SERVERS=("web01" "web02" "web03" "web04") for server in "${SERVERS[@]}"; do echo "正在同步配置到 $server..." rsync -avz --dry-run \ --exclude='*.bak' \ $CONFIG_DIR/ root@$server:$CONFIG_DIR/ # 确认无误后执行实际同步 read -p "确认同步到 $server 吗？(y/n): " confirm if [ "$confirm" = "y" ]; then rsync -avz \ --exclude='*.bak' \ $CONFIG_DIR/ root@$server:$CONFIG_DIR/ echo "$server 同步完成" fi done案例4：监控同步状态#!/bin/bash # rsync监控脚本 SYNC_LOG="/var/log/rsync-monitor.log" LOCK_FILE="/var/run/rsync-sync.lock" # 检查是否已有rsync进程在运行 if [ -f "$LOCK_FILE" ]; then echo "$(date): rsync进程已在运行" >> $SYNC_LOG exit 1 fi # 创建锁文件 echo $$ > $LOCK_FILE # 执行同步并记录时间 START_TIME=$(date +%s) echo "$(date): 开始同步" >> $SYNC_LOG rsync -avz --stats /source/ user@remote:/destination/ 2>&1 | tee -a $SYNC_LOG END_TIME=$(date +%s) DURATION=$((END_TIME - START_TIME)) echo "$(date): 同步完成，耗时 ${DURATION} 秒" >> $SYNC_LOG # 清理锁文件 rm -f $LOCK_FILE 案例5：配合inotify实现实时同步inotify是Linux内核提供的文件系统事件监控机制，可以监控文件的创建、修改、删除等操作。配合rsync使用，就能实现准实时的文件同步。#inotify-tools这个工具包 # CentOS/RHEL yum install inotify-tools # Ubuntu/Debian apt-get install inotify-tools#监控脚本 #!/bin/bash SRC_DIR="/var/www/html" DEST="user@remote_host:/var/www/html/" DELAY=5 SYNC_LOCK="/tmp/rsync.lock" inotifywait -mr --format '%w %f %e' -e modify,create,delete,move $SRC_DIR | while read DIR FILE EVENT do echo "检测到文件变化: $DIR$FILE ($EVENT)" # 如果已经有同步任务在等待，就跳过 if [ -f $SYNC_LOCK ]; then continue fi # 创建锁文件 touch $SYNC_LOCK # 延迟执行同步 ( sleep $DELAY echo "开始同步..." rsync -av --delete $SRC_DIR/ $DEST rm -f $SYNC_LOCK echo "同步完成" ) & done注意：inotify监控的文件数量是有限制的，可以通过调整内核参数来增加：{callout color="#17507D"}echo 8192 > /proc/sys/fs/inotify/max_user_watches{/callout}案例6：定时备份脚本#!/bin/bash # 完整的定时备份脚本 /usr/local/bin/auto-backup.sh # 配置参数 SOURCE_DIRS=("/var/www" "/etc" "/home") BACKUP_SERVER="backup.company.com" BACKUP_BASE="/backup/$(hostname)" LOG_DIR="/var/log/backup" RETENTION_DAYS=7 # 创建日志目录 mkdir -p $LOG_DIR # 获取当前时间 DATE=$(date +%Y%m%d_%H%M%S) LOG_FILE="$LOG_DIR/backup_$DATE.log" # 记录开始时间 echo "=== 备份开始: $(date) ===" > $LOG_FILE # 检查网络连通性 if ! ping -c 3 $BACKUP_SERVER > /dev/null 2>&1; then echo "错误: 无法连接到备份服务器 $BACKUP_SERVER" >> $LOG_FILE exit 1 fi # 备份每个目录 for dir in "${SOURCE_DIRS[@]}"; do if [ -d "$dir" ]; then echo "正在备份 $dir..." >> $LOG_FILE # 创建远程目录 ssh root@$BACKUP_SERVER "mkdir -p $BACKUP_BASE$(dirname $dir)" # 执行同步 rsync -avz --delete \ --exclude='*.tmp' \ --exclude='*.log' \ --exclude='cache/' \ --timeout=3600 \ --log-file=$LOG_FILE \ $dir/ root@$BACKUP_SERVER:$BACKUP_BASE$dir/ if [ $? -eq 0 ]; then echo "$dir 备份成功" >> $LOG_FILE else echo "$dir 备份失败" >> $LOG_FILE # 发送告警 echo "目录 $dir 备份失败" | mail -s "备份失败告警" admin@company.com fi else echo "警告: 目录 $dir 不存在" >> $LOG_FILE fi done # 清理旧日志 find $LOG_DIR -name "backup_*.log" -mtime +$RETENTION_DAYS -delete echo "=== 备份结束: $(date) ===" >> $LOG_FILE # 设置定时任务 # crontab -e # 0 2 * * * /usr/local/bin/auto-backup.sh案例7：代码部署脚本#!/bin/bash # 代码部署脚本 PROJECT_NAME="myapp" LOCAL_PATH="/var/jenkins/workspace/$PROJECT_NAME" SERVERS=("web01.company.com" "web02.company.com") REMOTE_PATH="/var/www/$PROJECT_NAME" BACKUP_PATH="/var/www/backup/$PROJECT_NAME" echo "开始部署 $PROJECT_NAME..." # 检查本地代码是否存在 if [ ! -d "$LOCAL_PATH" ]; then echo "错误: 本地代码路径不存在" exit 1 fi # 部署到每台服务器 for server in "${SERVERS[@]}"; do echo "正在部署到 $server..." # 创建备份 ssh root@$server " mkdir -p $BACKUP_PATH if [ -d $REMOTE_PATH ]; then cp -r $REMOTE_PATH $BACKUP_PATH/$(date +%Y%m%d_%H%M%S) fi " # 同步代码 rsync -avz --delete \ --exclude='.git/' \ --exclude='node_modules/' \ --exclude='*.log' \ $LOCAL_PATH/ root@$server:$REMOTE_PATH/ if [ $? -eq 0 ]; then echo "$server 部署成功" # 重启服务 ssh root@$server "systemctl restart $PROJECT_NAME" # 健康检查 sleep 5 if curl -f http://$server/health > /dev/null 2>&1; then echo "$server 服务启动正常" else echo "$server 服务启动异常，正在回滚..." # 回滚操作 LATEST_BACKUP=$(ssh root@$server "ls -t $BACKUP_PATH | head -1") ssh root@$server " rm -rf $REMOTE_PATH cp -r $BACKUP_PATH/$LATEST_BACKUP $REMOTE_PATH systemctl restart $PROJECT_NAME " fi else echo "$server 部署失败" fi done echo "部署完成"案例8：#同步状态监控 #!/bin/bash # rsync状态监控脚本 MONITOR_LOG="/var/log/rsync-monitor.log" ALERT_EMAIL="admin@company.com" check_rsync_status() { local log_file=$1 local max_age_hours=2 if [ ! -f "$log_file" ]; then echo "告警: 同步日志文件不存在" return 1 fi # 检查日志文件是否太旧 if [ $(find "$log_file" -mmin +$((max_age_hours * 60)) | wc -l) -gt 0 ]; then echo "告警: 同步日志超过 $max_age_hours 小时未更新" return 1 fi # 检查是否有错误 if grep -q "rsync error\|failed\|No such file" "$log_file"; then echo "告警: 同步过程中发现错误" return 1 fi return 0 } # 检查各个同步任务 SYNC_LOGS=("/var/log/web-sync.log" "/var/log/db-sync.log" "/var/log/config-sync.log") for log in "${SYNC_LOGS[@]}"; do if ! check_rsync_status "$log"; then echo "$(date): $log 检查失败" >> $MONITOR_LOG # 发送告警邮件 tail -50 "$log" | mail -s "Rsync同步告警: $(basename $log)" $ALERT_EMAIL fi done
-
针对部分特定场景非常好用的命令推荐 下面这些工具，在特定场景下，能极大改善工作效率。对付海量文件和日志ripgrep（rg） 查找速度快，来自底层优势：Rust 实现 + SIMD 加速自动跳过 .gitignore 标记的垃圾文件多线程狂扫正则前缀表优化示例：rg "OutOfMemoryError" /var/log/ #按语言过滤 rg "timeout" --type java系统优化类fd —— find 语法的救赎 简化find命令冗长的参数配置fd '*.log' fd log | xargs grep "error"bat —— cat 的高颜值进化 特点：自动语法高亮自动分页Git diff 配色可以换主题less +F —— 实时日志查看的隐藏 Boss less +F application.log实时追踪随时退出想翻历史就翻/ 搜索超丝滑iotop —— 谁在往磁盘暴力输出？ 线上系统突然卡住时，第一反应往往是：“是不是写磁盘了？”iotop 一跑：iotop哪个进程在疯狂刷 I/O，一秒立现。再配合：strace -p PID通常十分钟能锁定罪魁祸首。dstat —— 把系统四大件一次性摊开 vmstat、iostat、netstat 虽然都好，但分开看信息太散。dstat -cdnmCPU、磁盘、网络、内存一屏展示。 排查性能问题时能省一堆来回跳命令的时间。pv —— 管道操作的“进度条神器” 压一个 40GB 的日志，你肯定体验过那种：“它到底是卡住了，还是在努力？我怎么一点底都没有？”pv 会给你一个心理安慰：pv huge.log | gzip > huge.log.gz实时速度、耗时、剩余时间，全部告诉你。ncdu —— 帮你抓出磁盘空间的黑洞 du 沉得住气，但速度慢。 ncdu 直接图形化展示文件大小，效果非常爽。ncdu /你能瞬间看到哪些日志像吹气球一样膨胀。很多线上磁盘爆掉的问题就是靠它找出的。网络问题侦探工具nmap —— 检查端口开放情况的利器 扫服务器端口：nmap -sV 10.0.0.12部署错误、端口冲突都能很快看出来。tshark —— 无界面的 Wireshark 线上服务器没图形界面时，它就是唯一的抓包依靠。tshark -i eth0 -f "port 8080" 想抽 HTTP 请求头：tshark -Y "http.request" -T fields -e http.host -e http.user_agent适合查微妙的网络抖动或协议异常。iperf3 —— 网络玄学问题的终结者 很多时候服务连接超时并不是代码问题，而是——链路抖了。# 服务器： iperf3 -s #客户端： iperf3 -c 10.0.0.12看到带宽从 1Gbps 掉到 50Mbps 的那一瞬间，我就知道不是程序锅，是交换机要加班了。
-
journalctl——systemd日志查询工具详解 journalctl是systemd日志系统的查询工具。当你某个服务启动失败或出现错误时，系统会提示你使用这个工具来排查。使用grep、awk这类工具对日志进行处理时，可能遇到下面的情况导致排查困难。日志文件太大，grep半天没反应想看某个时间段的日志，结果要写一堆复杂的正则表达式系统重启后，之前的日志找不到了想看某个服务的完整日志链路，结果要翻好几个不同的文件基础用法直接使用journalctl命令，会看到系统从启动开始的所有日志。不过这样看起来会很乱，而且信息量巨大。加个-f参数，就像tail -f一样，可以实时显示最新的日志。当怀疑某个服务有问题的时候，开着这个命令，然后去操作一下，立马就能看到相关的日志输出。按时间查看日志#查看今天的日志 journalctl --since today #或者看昨天的： journalctl --since yesterday #看某个时间段的 journalctl --since "2024-01-15 14:00:00" --until "2024-01-15 15:00:00"按服务查看日志#只看nginx服务的日志 journalctl -u nginx #实时监控某个服务： journalctl -u nginx -f #有时候一个服务重启了好几次，你想看它的历史记录： journalctl -u nginx --since "1 hour ago"进阶技巧按优先级过滤#只显示错误级别的日志 journalctl -p err查看内核日志journalctl -k该命令等同于dmesg，但是journalctl的输出格式更友好，而且可以结合其他参数使用。按进程ID查看 有时候你知道某个进程有问题，可以直接按PID查看：journalctl _PID=1234查看启动信息 想看系统启动过程中发生了什么：journalctl -b如果系统重启过多次，你想看上一次启动的日志：journalctl -b -1这个功能在排查系统启动异常时特别有用。高级功能JSON格式输出 有时候你需要程序化处理日志，可以用JSON格式：journalctl -u nginx -o json这样输出的每一行都是一个JSON对象，方便后续处理。查看磁盘使用情况 journal日志会占用磁盘空间，你可以查看当前使用情况：journalctl --disk-usage如果空间不够，可以清理旧日志：journalctl --vacuum-time=7d只保留最近7天的日志。导出日志 有时候需要把日志发给其他人分析：journalctl -u myapp --since today > app_logs.txt反向查看日志 从最新的日志开始看：journalctl -r这个在查看最近发生的问题时很有用。配置优化持久化存储 默认情况下，有些系统的journal日志是存储在内存中的，重启后就丢失了。要启用持久化存储：sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald限制日志大小 编辑/etc/systemd/journald.conf：SystemMaxUse=1G SystemMaxFileSize=100M这样可以避免日志占用太多磁盘空间。常见问题和解决方案日志查看权限问题 有时候普通用户看不到某些日志，需要加入systemd-journal组：sudo usermod -a -G systemd-journal username日志时间显示问题 如果时间显示不对，可能是时区设置问题：journalctl --utc使用UTC时间显示。性能问题 如果journalctl查询很慢，可能是因为日志文件太大。可以考虑：清理旧日志调整日志级别使用更精确的过滤条件一些小技巧# 查看最近的错误日志，按时间倒序 journalctl -p err -r --since "1 hour ago" # 查看某个用户的所有日志 journalctl _UID=1000 # 查看系统启动耗时 systemd-analyze blame
