搜索到
113
篇与
的结果
-
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 的那一瞬间，我就知道不是程序锅，是交换机要加班了。
-
容器间通信延迟高的排查流程 故障现象单个服务很快，但组合起来速度就慢。具体表现：{callout color="#EACDD1"}页面加载从2秒延迟到5秒接口响应延迟明显偶尔出现超时错误数据库查询正常应用资源正常（CPU、内存等）带宽充足{/callout}问题定位1.抓包分析进入api网关容器（本例中使用nginx容器作为入口网关），对相应端口的数据进行抓包分析。 # 抓包命令 docker exec nginx tcpdump -i eth0 -nn -tttt 'tcp port 8080' -w /tmp/capture.pcap #tcpdump: 使用网络抓包工具 tcpdump #-i eth0: 指定监听的网络接口为 eth0 #-nn: 不解析主机名和端口号（直接显示IP和数字端口） #-tttt: 使用完整格式的时间戳（年月日时分秒） #'tcp port 8080': 过滤条件，只捕获 TCP 协议且目标或源端口为 8080 的流量 #-w /tmp/capture.pcap: 将捕获的数据包写入到容器内的 /tmp/capture.pcap 文件，而不是显示在终端 # Wireshark分析结果 时间线： 00:00.000 请求到达nginx 00:12.000 nginx → service-a (12ms延迟) 00:18.000 service-a收到 (6ms) 00:25.000 service-a → service-b (7ms) 00:45.000 service-b收到 (20ms !!!) 00:78.000 service-b处理完成 (33ms) 00:98.000 service-a收到响应 (20ms !!!) 00:105.000 nginx收到 (7ms) 00:130.000 返回给用户 (25ms) 总计：130ms 2.发现问题容器间通信延迟异常高，尤其是 service-a 和 service-b 之间。3.分析问题为什么容器间通信会有20ms延迟？{callout color="#EACDD1"}正常情况：同一主机的容器通信应该<1ms我们的却有20-30ms原因：Docker默认使用Bridge网络模式数据要经过：容器 → veth → bridge → NAT → veth → 容器每一层都有损耗网络路径：容器A → veth0 → docker0网桥 → iptables规则(300+条) → NAT转换 → veth1 → 容器B 损耗来源：veth虚拟网卡：3-5ms网桥转发：2-3msiptables遍历：5-8msNAT转换：1-2msconntrack查表：1-2ms总损耗：12-20ms{/callout}docker网络模式对比1.bridge模式（默认）# 测试 docker run -d --name app1 alpine sleep 3600 docker run -d --name app2 alpine sleep 3600 docker exec app1 apk add iputils docker exec app1 ping -c 100 app2 # 结果 rtt min/avg/max/mdev = 0.082/0.125/0.245/0.031 ms 特点：延迟：0.08-0.25ms（容器间）吞吐量：950Mbps优点：隔离性好缺点：性能一般2.Host模式docker run -d --name app-host --network host alpine sleep 3600 docker exec app-host ping -c 100 127.0.0.1 # 结果 rtt min/avg/max/mdev = 0.015/0.022/0.045/0.008 ms特点：延迟：0.015-0.045ms吞吐量：10Gbps优点：性能最好缺点：端口冲突、安全性差3.Overlay模式（跨主机）docker network create -d overlay testnet docker run -d --name app1 --network testnet alpine sleep 3600 # 在另一台主机 docker run -d --name app2 --network testnet alpine sleep 3600 # 测试 docker exec app1 ping -c 100 app2 # 结果 rtt min/avg/max/mdev = 0.245/0.512/1.245/0.156 ms特点：延迟：0.5-30ms（取决于网络）吞吐量：700Mbps（VXLAN损耗）优点：跨主机、K8s支持缺点：性能较差、CPU占用高4.Macvlan模式docker network create -d macvlan \ --subnet=192.168.1.0/24 \ -o parent=eth0 macnet docker run -d --name app1 --network macnet --ip 192.168.1.100 alpine docker exec app1 ping -c 100 192.168.1.101 # 结果 rtt min/avg/max/mdev = 0.052/0.085/0.156/0.022 ms 特点：延迟：0.05-0.15ms吞吐量：950Mbps优点：性能好、独立IP缺点：配置复杂性能对比模式延迟（ms）吞吐量隔离性易用性适用场景Bridge0.08-0.25950Mbps好高开发测试Host0.02-0.0510Gbps差高单体应用Overlay0.5-30700Mbps好中k8s集群Macvlan0.05-0.15950Mbps好低独立IP结论：性能：Host > Macvlan > Bridge > Overlay易用：Bridge = Host > Overlay > Macvlan生产推荐：看场景选择优化方案方案1，内核参数调优cat >> /etc/sysctl.conf <<EOF # TCP优化 net.ipv4.tcp_congestion_control = bbr net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_slow_start_after_idle = 0 # 缓冲区 net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.ipv4.tcp_rmem = 4096 87380 134217728 net.ipv4.tcp_wmem = 4096 65536 134217728 # 连接跟踪 net.netfilter.nf_conntrack_max = 262144 # 队列 net.core.netdev_max_backlog = 5000 net.core.somaxconn = 4096 EOF sysctl -p测试结果：{callout color="#EACDD1"}优化前：延迟：30ms吞吐量：942MbpsCPU：45%优化后：延迟：26.5ms (-12%)吞吐量：1.05Gbps (+11%)CPU：42% (-7%){/callout}评价： 效果一般，但零成本，推荐做。方案2，简化iptables规则# 发现问题 iptables -L -n | wc -l # 输出：347行规则！ # 每个数据包都要遍历这347条规则 # 优化：禁用Docker的iptables管理 cat > /etc/docker/daemon.json <<EOF { "iptables": false, "ip-forward": true } EOF systemctl restart docker # 手动添加最小规则集 iptables -A FORWARD -i docker0 -o docker0 -j ACCEPT iptables -A FORWARD -i docker0 ! -o docker0 -j ACCEPT # 现在只有50条规则测试结果：{callout color="#EACDD1"}优化前：iptables规则：347条延迟：26.5ms优化后：iptables规则：50条延迟：22.2ms (-16%){/callout}评价： 效果明显，但要小心配置错误导致网络不通。方案3：使用自定义网络# Docker默认bridge性能差 # 自定义网络更好 docker network create \ --driver bridge \ --opt com.docker.network.bridge.name=br-prod \ --opt com.docker.network.driver.mtu=1500 \ prod-network # 使用自定义网络 docker run -d --name app --network prod-network myapp # 可以直接用服务名通信 docker exec app1 ping app2 # 无需IP测试结果：{callout color="#EACDD1"}默认bridge：DNS解析：5-10ms延迟：0.125ms自定义network：DNS解析：1-2ms延迟：0.098ms (-22%){/callout}评价： 简单有效，强烈推荐。方案4：增加conntrack表（效果：解决抖动） 高并发时连接跟踪表会满 # 导致丢包和延迟抖动 echo 262144 > /proc/sys/net/netfilter/nf_conntrack_max # 永久生效 cat >> /etc/sysctl.conf <<EOF net.netfilter.nf_conntrack_max = 262144 net.netfilter.nf_conntrack_buckets = 65536 EOF sysctl -p测试结果（10000并发）：{callout color="#EACDD1"}优化前：丢包率：15%延迟：30-80ms（抖动大）优化后：丢包率：0%延迟：22-24ms（稳定）{/callout}评价： 高并发场景必做。方案5：使用ipvlan# ipvlan绕过网桥，直接三层路由 docker network create -d ipvlan \ --subnet=192.168.100.0/24 \ -o parent=eth0 \ -o ipvlan_mode=l2 \ ipvlan-net docker run -d --name app --network ipvlan-net --ip 192.168.100.10 myapp测试结果：{callout color="#EACDD1"}Bridge模式：rtt min/avg/max/mdev = 0.082/0.125/0.245/0.031 msipvlan模式：rtt min/avg/max/mdev = 0.045/0.068/0.115/0.018 ms改善：-46%{/callout}评价： 效果很好，但需要管理IP地址。
-
OpenResty OpenResty系统信息OpenResty在表ngx.conf里提供了六个功能接口，可以获取自身的一些信息：debug：是否算Debug版本prefix：工作目录，即启动时“-p”参数指定的目录nginx_version：大版本号，即内部NGINX的版本号nginx_configure:编译的使用的配置参数subsystem：当前所在的子系统，取值为“http”或“stream”ngx_lua_version：当前所在子系统的版本号注意： prefix和nginx_configure这两个接口是函数的形式。接口的示例代码如下：ngx.say(nginx.config.debug) ngx.say(nginx.config.prefix()) ngx.say(nginx.config.nginx_version) ngx.say(nginx.config.nginx_configure()) ngx.say(nginx.config.subsystem()) ngx.say(nginx.config.ngx_lua_version())OpenResty运行日志函数ngx.log(log_level)记录罗OpenResty的运行日志，用法类似Lua的标准库函数print，可以接受任意多个参数，记录任意信息。print()=ngx.NOTICEngx.log的第一个参数是日志级别。ngx.STDERR：日志直接打印到标准输出，最高级别的日志ngx.EMERG：发生了紧急情况（emergency），需要立即处理ngx.ALERT：发生了严重错误，可能需要报警给运维系统ngx.CRIT：发生了严重错误（critical）ngx.ERR：普通的错误，业务中发生了意外ngx.WARN：警告信息，业务正常，但可能需要检查警告的来源ngx.NOTICE：提醒信息，仅仅算告知，通常可以忽略ngx.INFO：一般的信息ngx.DEBUG：调试可用的信息，只有debug版本才会启用业务逻辑关键点INFO或者WARN，捕获error级别的错误信息OpenResty时间日期对于Web服务来说，能够随时获取正确的时间与日期是非常重要的。OpenResty为此提供罗很多时间日期相关的函数，可以满足绝大多数场景的应用。这些时间日期函数不会引发昂贵的系统调用（ngx.updatetime除外），几乎没有成本。所以在应用程序中应对尽量使用它们操作时间而不是使用Lua标准库里的os。当前时间ngx.say(ngx.today()) #本地时间，格式是“yyyy-mm-dd” ngx.say(ngx.localtime()) #本地时间，格式是“yyyy-mm-dd hh:mm:ss” ngx.say(ngx.utctime()) #utc时间，格式是“yyyy-mm-dd hh:mm:ss”时间戳ngx.time ngx.now时间戳
