线上nginx日志无切割引起的祸

状况:lnmp环境下nginx反向代理服务器,部分网站无法访问,重启服务器后ok

拿到权限后安装zabbix监控,负载Ok ,

IO报警:

Disk I/O is overloaded on xss152

使用命令工具查看io状况,top下78%wa........................

[[email protected] /]#  iostat -x 1 10 
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.27    0.00    0.59   21.81    0.00   77.33

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               9.58   152.95  128.06   63.60  1136.57  1732.58    14.97    12.19   63.58   4.44  85.00
dm-0              0.00     0.00  137.10  216.57  1130.05  1732.58     8.09    25.40   71.82   2.40  84.99
dm-1              0.00     0.00    0.08    0.00     0.65     0.00     7.67     0.00    2.45   2.23   0.02
dm-2              0.00     0.00    0.06    0.00     0.51     0.00     8.00     0.00    2.65   2.39   0.02

%util长期达到99%................

查看服务器本身状况,在nginx日志目录下发现,日志无切割,常年积累下来已经达到可怕的大小

-rw-r--r--  1 nobody root  4959870331 5月  18 11:38 access.log.1
[[email protected] logs]# du -sh
37G	

so,先写nginx日志切割,其后强制执行一次.

[[email protected] logrotate.d]# vim /etc/logrotate.d/nginx
/usr/local/nginx/logs/*log{
    daily
    rotate 7
    compress
    notifempty
    nocompress
    postrotate
    /bin/kill -USR1 `cat /usr/local/nginx/logs/nginx.pid` 2> /dev/null || true
endscript
}

强制执行一次,然后查看Io情况.

logrotate -f /etc/logrotate.d/nginx
[email protected] logrotate.d]#  iostat -x 1 10 

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.27    0.00    0.58   20.70    0.00   78.45
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.25    0.00    0.75    0.00    0.00   99.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     3.00    0.00    2.00     0.00    40.00    20.00     0.02    9.00   5.00   1.00
dm-0              0.00     0.00    0.00    5.00     0.00    40.00     8.00     0.05    9.60   2.00   1.00
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-2              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-3              0.00     0.00    0.00    5.00     0.00    40.00     8.00     0.05    9.60   2.00   1.00

TOP下

[[email protected] logrotate.d]# top

top - 11:57:35 up  2:20,  3 users,  load average: 0.00, 0.00, 0.26
Tasks: 142 total,   1 running, 141 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.3%sy,  0.0%ni, 99.3%id,  0.3%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   3917212k total,  3762456k used,   154756k free,  2144812k buffers
Swap:  8388600k total,        0k used,  8388600k free,   774492k cached

0.3%wa  zabbix警报解除.搞定!!

该服务器搭建于2014年,上一任管理员写了nginx切割脚本,但是没有后面由于nginx网站增添,没有添加到脚本,引起nginx日志一直无切割.

时间: 2024-07-30 00:52:44

线上nginx日志无切割引起的祸的相关文章

FPM打包工具制作线上nginx的RPM包

一.安装FPM打包工具 1.FPM是ruby的模块,先安装FPM依赖的包 [[email protected] ~]#  yum -y install ruby rubygems ruby-devel rpm-build 2.因国内网络环境,访问http://rubygems.org/站点时不稳定,所以增加国内toabao提供的一个镜像站点,把原来的站点移除 [[email protected] ~]#  gem sources -a https://ruby.taobao.org/ [[ema

nginx日志定时切割

关于nginx日志定时切割.一般有两种方案,第一用logrotate,它是一个linux系统日志的管理工具.它可以切割.压缩等其他软件的日志文件软件:logrotate是基于crontab运行的,所以这个时间点是由crontab控制的,具体可以查询crontab的配置文件/etc/anacrontab.第二种用shell脚本定时切割. 第一种方案:logrotate 1.安装logrotate,我这里是centos直接用:yum -y install logroate 2.安装成功后.配置log

线上nginx访问日志切割脚本

1.说明 随着时间的增加,nginx 的访问日志会越来越大,下图是新部署的线上 zabbix 监控网站运行了十几天左右产生的访问日志达到213M. 所以必须进行日志分割,要求如下: 1.每天的日志单独生成一个文件 2.保留30天的访问日志 2.编写脚本 vim /usr/local/nginx/logs/nginx_log_rotate.sh #! /bin/bash logs_path="/usr/local/nginx/logs/" log_name="access.lo

线上Nginx状态码为400解决

今天某公司对接我公司的一个api业务.当天下午客户在自己的线上业务平台下发送了第一个POST请求,结果我方在前端Nginx收到了状态码为400的响应.之前没有遇到过,google后得出结论,怀疑是客户系统在发送HTTP请求时,发送的请求头(Request Header)太大导致的.又想到客户公司是做安全的公司.所以在请求其他系统的时候,会多加一些加密参数到http请求头中. Nginx的http请求头由下面参数控制: client_header_buffer_size    默认  1k; la

Nginx 日志文件切割

Nginx 是一个非常轻量的 Web 服务器,体积小.性能高.速度快等诸多优点.但不足的是也存在缺点,比如其产生的访问日志文件一直就是一个,不会自动地进行切割,如果访问量很大的话,将 导致日志文件容量非常大,不便于管理.当然了,我们也不希望看到这么庞大的一个访问日志文件,那需要手动对这个文件进行切割. 在 Linux 平台上 Shell 脚本丰富,使用 Shell 脚本加 crontab 命令能非常方便地进行切割,但在 Windows 平台上就麻烦一些了,刚才弄了好长时间,就在这里记录整理一下.

Nginx日志文件切割

Nginx 是一个非常轻量的 Web 服务器,体积小.性能高.速度快等诸多优点.但不足的是也存在缺点,比如其产生的访问日志文件一直就是一个,不会自动地进行切割,如果访问量很大的话,将 导致日志文件容量非常大,不便于管理.当然了,我们也不希望看到这么庞大的一个访问日志文件,那需要手动对这个文件进行切割. 在 Linux 平台上 Shell 脚本丰富,使用 Shell 脚本加 crontab 命令能非常方便地进行切割 日志文件切割要求 由于 Nginx 的日志都是写在一个文件当中的,因此,我们需要每

一种线上服务日志切分与压缩方法

1.业务背景 对于线上业务而言,打印日志是一个系统运行状况的全面体检,日志打得约详细,越容易查找问题,但是机器磁盘是有限的,这时候很容易将磁盘撑爆.所以打印日志多少要选取一个平衡,打印适量的日志,只在关键环节,容易出错的地方打印日志即可.但是随着业务量的提升,即使我们控制了打印日志的频率,但日志文件的容量也在大量扩大.如果我们对日志文件的处理方式不当,日志文件将打到磁盘上线,新业务就再也刷不出来任何日志了. 因此,我们对日志的处理一般分为三个步骤: 打印当天日志,历史日志重命名为带日期格式,以示

线上nginx proxy buffer导致的性能问题

最近有一个项目访问量突然变大,但发现前端的nginx负载会很高,导致出现4xx和5xx的异常,响应时间也变长了.今天有时间,解决了一下.下面记录一下解决思路和方法.我们这个项目部署在azure.最前端是azure 的负载均衡器(lb),lb后面是2台nginx主机,型号是D2v3(2核8G).在我们实际使用中,一台nginx主机rpm达到30k,cpu,内存,网络都是没有任何压力的.所以一台主机支持的最大访问量应该远远大于30k.但今天这个项目rpm撑到3k的时候,系统负载就很高了.这个项目后端

线上nginx的一次“no live upstreams while connecting to upstream ”分析

先描述一下环境,前段的负载均衡转发给nginx,nginx再转发给后端的应用服务器. nginx配置文件如下: upstream ads { server ap1:8888 max_fails=1 fail_timeout=60s; server ap2:8888 max_fails=1 fail_timeout=60s; } 出现的现象是: 日志里面每隔一两分钟就会记录一条类似 *379803415 no live upstreams while connecting to upstream