注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

itoedr的it学苑

记录从IT文盲学到专家的历程

 
 
 

日志

 
 

Tengine的新特性  

2013-06-05 15:45:56|  分类: nginx编程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

基于nginx的开源web服务器,功能越来越强大,当然也得益于nginx的构架与精干。其中tfs更能适应云时代的特点。
其新增个性化特点如下:
能自动分配给CPU任务量
自动根据CPU数目设置进程个数和绑定CPU亲缘性;

Core functionality

指令

Syntax: worker_processes [num | auto]
Default: worker_processes auto
Context: core

worker_processes增加参数auto。当设置成autotengine将自动启动与cpu数量相同的worker进程。

Syntax: worker_cpu_affinity [mask1 mask2 mask3 ... | auto | off ]
Default: worker_cpu_affinity off
Context: core

worker_cpu_affinity增加参数autooff。当设置成auto时,tengine将根据worker的数量自动配置cpu绑定位图。绑定的顺序是按CPU编号从大到小。 如果worker数量大于cpu数量,则剩余的worker进程将按照CPU编号从大到小的顺序从编号最大的CPU开始再次绑定。例如:某CPU8核,

  • worker数量是4,则自动配置的绑定位图是10000000, 01000000, 00100000, 00010000

  • worker数量是8,则自动配置的绑定位图是10000000, 01000000, 00100000, 00010000, 00001000, 00000100, 00000010, 00000001

  • worker数量是10,则自动配置的绑定位图是10000000, 01000000, 00100000, 00010000, 00001000, 00000100, 00000010, 00000001, 10000000, 01000000

当设置成off时,tengine不会进行cpu绑定。

worker_cpu_affinityerror log最多显示64CPU的绑定情况。

Syntax: error_page code ... [default] [=[response]]
Default: -
Context: http, server, location, if in location

该指令用于设置如果出现指定的HTTP错误状态码,返回给客户端显示的对应uri地址。

  • 支持default,可以把上一级设置的error_page重新设定;

  • 修正error_page不能发现重复的code的问题,不能正常继承上一级设置的问题。

举例:

    http {
        error_page 404 /404.html;

        server {
            error_page 404 default;
        }
    }

server中的"error_page"指令将404的页面还原成系统默认。

Syntax: msie_padding [on | off]
Default: msie_padding off
Context: http, server, location

此指令关闭或开启MSIE浏览器的msie_padding特性,若启用选项,nginx会为response头部填满512字节,这样就阻止了相关浏览器会激活友好错误界面,因此不会隐藏更多的错误信息。Tengine中默认关闭此功能。

Syntax: request_time_cache [on | off]
Default: request_time_cache on
Context: http, server, location

设置成'off'时,Tengine将不使用时间缓存,$request_time$request_time_msec$request_time_usec将会得到更精确的时间。

Syntax: log_empty_request [on | off]
Default: log_empty_request on
Context: http, server, location

设置成'off'时,Tengine将不会记录没有发送任何数据的访问日志。默认情况下,Tengine会在访问日志里面记录一条400状态的日志。

Syntax: server_admin admin
Default: none
Context: http, server, location

设置网站管理员信息,当打开server_info的时候,显示错误页面时会显示该信息。

Syntax: server_info on | off
Default: server_info on
Context: http, server, location

当打开server_info的时候,显示错误页面时会显示URL、服务器名称和出错时间。

Syntax: server_tag off | customized_tag
Default: none
Context: http, server, location

自定义设置HTTP响应的server头,‘off’可以禁止返回server头。如果什么都不设置,就是返回默认Nginx的标识。



ngx_http_log_module

扩展日志模块,提供syslogpipe,以及日志采样。

开启syslog日志功能需要在编译是添加参数--with-syslog,否则syslog不会生效。

syslog模块兼容syslogd。使用syslog-ng需要修改配置文件以支持udpunix-dgram,并屏蔽unix-stream

    source s_sys {
        file ("/proc/kmsg" program_override("kernel: "));
        unix-dgram ("/dev/log");
        internal();
        udp(ip(0.0.0.0) port(514));
    };

指令

Syntax: access_log log_target [format [ratio=ratio] [buffer=size]] | off
Default: access_log logs/access.log combined ratio=1
Context: http, server, location

format(含)前面的各参数顺序固定,后面的参数可乱序。此格式兼容nginx原有access_log格式。

  • log_target
    兼容以前的log_file参数,并添加下面三种日志类型:

        file:/path/to/file
        syslog:facility[:[loglevel][:[target_ip:[target_port] | target_udgram_addr][:ident]]]
        "pipe:/path/to/exec parms"
  • ratio
    buffer参数前,指定tengine以固定的采样率记录日志。例如:ratio=0.0001,那么每经过10000条记录,tengine会记录一条。
    如果需要使用buffer参数而不需要设置日志采样,不能省略此参数,需要设置ratio=1
    下面介绍下支持的三种log_target

    • file
      nginxlog_file对应的类型;

    • syslog
      支持通过syslog方式记录日志;

          facility := auth | authpriv | cron | daemon | ftp | kern | lpr | mail | mark | news | security | syslog
                    | user | uucp | local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7
      
          loglevel := crit | err | error | emerg | panic | alert | warn | warning | info | notice | debug
          loglevel默认值 = info
      
          target_ip:[target_port]:日志输出目的主机的IP地址和端口,端口默认是UDP(514)。这里syslog只支持UDP协议
      
          target_udgram_addrunix dgram地址,默认为Unix dgram(/dev/log)。这里syslog只支持UNIX DGRAM协议
      
          ident: 自定义标志,可以用于应用信息

      例如:

          syslog:user:info:127.0.0.1:514:ident          user类型和info级别将日志发送给127.0.0.1:514UDP端口,并设置应用标记为ident
              syslog的输出样例:"May  4 15:44:15 local ident[26490]: XXXXXXXX"
          syslog:auth:err:10.232.4.28::ident            auth类型和err级别将日志发送到主机10.232.4.28:514UDP端口,并设置应用标记为ident
          syslog:user:info:/dev/log:ident               user类型和info级别将日志发送给本机Unix dgram(/dev/log),并设置应用标记为ident
          syslog:user::/dev/log:ident                   user类型和info级别将日志发送给本机Unix dgram(/dev/log),并设置应用标记为ident
          syslog:user:info::ident                       user类型和info级别将日志发送给本机Unix dgram(/dev/log),并设置应用标记为ident
          syslog:cron:debug:/dev/log                    cron类型和debug级别将日志发送到主机Unix dgram(/dev/log),并使用默认标记
              syslog的输出样例:"May  4 15:44:15 local NGINX[26490]: XXXXXXXX"
          syslog:user::127.0.0.1                        user类型和info级别将日志发送给127.0.0.1:514UDP端口,并使用默认标记
          syslog:user:debug                             user类型和debug级别将日志发送给本机Unix dgram(/dev/log),并使用默认标记
          syslog:user                                   user类型和info级别将日志发送给本机Unix dgram(/dev/log),并使用默认标记
    • pipe
      因为pipe命令行中含有空格的缘故,pipe需要使用双引号引用,命令行中的双引号需要转义。
      另外pipe进程的(user, group)遵循tengine指令user的配置,如果没有使用user指令配置的话,pipe进程将遵循tengine的默认用户设置,在编译时没有 制定的情况下,默认设置是(nobody, nobody)。请注意给与pipe进程适当的权限。

Syntax: error_log log_target [debug | info | notice | warn | error | crit]
Default: error_log logs/error.log
Context: core, http, server, location

error_log增加syslogpipe支持,使用同access_log

Syntax: syslog_retry_interval seconds
Default: syslog_retry_interval 1800
Context: core

建立连接失败后,下一次重试的时间间隔,单位:秒。

Syntax: log_escape on | off | ascii
Default: log_escape on
Context: core, http, server, location

  • 'on': access日志里面对特殊字符(除了保留或者非保留字符) 编码。

  • 'off': 对所有的特殊字符都不编码。

  • 'acsii': 只对不可见字符字符进行编码。



动态加载模块

  • 动态加载模块

描述

  • 这个模块主要是用来运行时动态加载模块,而不用每次都要重新编译Tengine.

  • 如果你想要编译官方模块为动态模块,你需要在configure的时候加上类似这样的指令(--with-http_xxx_module),./configure --help可以看到更多的细节.

  • 如果只想要安装官方模块为动态模块(不安装Nginx),那么就只需要configure之后,执行 make dso_install命令.

  • 动态加载模块的个数限制为128.

  • 如果已经加载的动态模块有修改,那么必须重起Tengine才会生效.

  • 只支持HTTP模块.

  • 模块 在Linux/FreeeBSD/MacOS下测试成功.

例子

worker_processes  1;

dso {
     load ngx_http_lua_module.so;
     load ngx_http_memcached_module.so;
}

events {
   worker_connections  1024;
}

指令



Syntax: path path

Default: none

Context: dso

path 主要是设置默认的动态模块加载路径。

例子:

path /home/dso/module/;

设置默认的动态模块加载路径为/home/dso/module/.



Syntax: load [module_name] [module_path]

Default: none

Context: dso

load命令用于在指定的路径(module_path),将指定的模块(module_name)动态加载到Nginx中。其中 module_pathmodule_name可以只写一个,如果没有module_path参数,那么默认path$(modulename).so.如果没有module_name参数,那么默认name就是module_path删除掉".so"后缀.

对于module_path的路径查找,这里是严格按照下面的顺序的

1 module_path指定的是绝对路径。 2 相对于dso_path设置的相对路径. 3 相对于默认的加载路径的相对路径(NGX_PREFIX/modules或者说configure时通过--dso-path设置的路径).

例子:

load ngx_http_empty_gif_module  ngx_http_empty_gif_module.so;
load ngx_http_test_module;
load ngx_http_test2_module.so;

将会从ngx_http_empty_gif_module.so.加载empty_gif模块。以及从 ngx_http_test_module.so加载ngx_http_test_module模块.第三条指令是从 ngx_http_test2_module.so加载ngx_http_test2_module模块.



Syntax: module_stub module_name

Default: none

Context: dso

这个指令主要是将你需要的动态模块插入到你所需要的位置(可以看conf/module_stubs这个文件),这个命令要很小心使用,因为它将会改变你的模块的运行时顺序(Nginx中模块都是有严格顺序的).而大多数时候这个命令都是不需要设置的。

例子:

    module_stub ngx_core_module;
    module_stub ngx_errlog_module;
    module_stub ngx_conf_module;
    module_stub ngx_events_module;
    module_stub ngx_event_core_module;
    module_stub ngx_epoll_module;
    module_stub ngx_openssl_module;
    module_stub ngx_http_module;
    module_stub ngx_http_core_module;
    .......................
    module_stub ngx_http_addition_filter_module;
    module_stub ngx_http_my_filter_module;

上面这个例子将会插入my_filter模块到addition_filter之前执行。



Syntax: include file_name

Default: none

Context: dso

include命令主要用于指定一个文件,这个文件里面包含了对应模块顺序(module_stub指令),有关于module_stub指令可以看下面的module_stubs部分.

例子:

include module_stubs

将会加载conf/modulestubs这个文件,这个文件主要是由(modulestub指令组成).

如何编译动态模块



如果你想要在安装完Tengine之后,编译官方模块为动态模块,那么你需要按照如下的步骤:

  • configure的时候打开你想要编译的模块.

    $ ./configure --with-http_sub_module=shared

  • 编译它.

    $ make

  • 安装动态模块.

    $ make dso_install

它将会复制动态库文件到你的动态模块目录,或者你也可以手工拷贝动态模块文件(文件是在objs/modules)到你想要加载的目录.



你能够使用dso_tool(Nginx安装目录的sbin)这个工具来编译第三方模块.

例子:

./dso_tool --add-module=/home/dso/lua-nginx-module

将会编译ngx_lua模块为动态库,然后安装到默认的模块路径.如果你想要安装到指定位置,那么需要指定--dst选项(更多的选项请使用dso_tool -h查看).

ngx_http_concat_module

该模块类似于apache中的mod_concat模块,用于合并多个文件在一个响应报文中。

请求参数需要用两个问号('??')例如:

http://example.com/??style1.css,style2.css,foo/style3.css

参数中某位置只包含一个‘?’,则'?'后表示文件的版本,例如:

http://example.com/??style1.css,style2.css,foo/style3.css?v=102234



location /static/css/ {
    concat on;
    concat_max_files 20;
}

location /static/js/ {
    concat on;
    concat_max_files 30;
}



concat on | off

默认: concat off

上下文: http, server, location

在配置的地方使模块有效(失效)



concat_types MIME types

默认: concat_types: text/css application/x-javascript

上下文: http, server, location

定义哪些MIME types是可以被接受



concat_unique on | off

默认: concat_unique on

上下文: http, server, location

定义是否只接受在[MIME types]中的相同类型的文件,例如:

http://example.com/static/??foo.css,bar/foobaz.js

如果配置为 'concat_unique on' 那么将返回400,如果配置为'concat_unique off' 那么将合并两个文件。



concat_max_files number

默认: concat_max_files 10

上下文: http, server, location

定义最大能接受的文件数量。



concat_delimiter string

默认:

上下文 'http, server, location'

定义在文件之间添加分隔符,例如

http://example.com/??1.js,2.js
如果配置为**concat_delimiter "\n"**响应会在1.js2.js两个文件之间插入一个换行符('\n')



concat_ignore_file_error 'on | off'

默认 'concat_ignore_file_error off'

上下文 'http, server, location'

定义模块是否忽略文件不存在(404)或者没有权限(403)错误



  1. 编译concat模块

    configure [--with-http_concat_module | --with-http_concat_module=shared]

    --with-http_concat_module选项,concat模块将被静态编译到tengine

    --with-http_concat_module=sharedconcat模块将被编译成动态文件,采用动态模块的方式添加到tengine

  2. 编译,安装

    make&&make install

  3. 配置concat的配置项

  4. 运行



一致性hash模块

描述

  • 这个模块提供一致性hash作为负载均衡算法。

  • 该模块通过使用客户端信息(如:$ip, $uri, $args等变量)作为参数,使用一致性hash算法将客户端映射到后端机器

  • 如果后端机器宕机,这请求会被迁移到其他机器

  • server id 字段,如果配置id字段,则使用id字段作为server标识,否则使用server ip和端口作为server标识,

    使用id字段可以手动设置server的标识,比如一台机器的ip或者端口变化,id仍然可以表示这台机器。使用id字段

    可以减低增减服务器时hash的波动。

  • server weight 字段,作为server权重,对应虚拟节点数目

  • 具体算法,将每个server虚拟成n个节点,均匀分布到hash环上,每次请求,根据配置的参数计算出一个hash值,在hash

    上查找离这个hash最近的虚拟节点,对应的server作为该次请求的后端机器。

  • 该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器,比如:

    consistent_hash $remote_addr:可以根据客户端ip映射

    consistent_hash $request_uri: 根据客户端请求的uri映射

    consistent_hash $args:根据客户端携带的参数进行映射

例子

worker_processes  1;

http {
    upstream test {
        consistent_hash $request_uri;

        server 127.0.0.1:9001 id=1001 weight=3;
        server 127.0.0.1:9002 id=1002 weight=10;
        server 127.0.0.1:9003 id=1003 weight=20;
    }
}

指令



Syntax: consistent_hash variable_name

Default: none

Context: upstream

配置upstream采用一致性hash作为负载均衡算法,并使用配置的变量名作为hash输入。

编译安装

  • configure的时候打开一致性hash模块,关闭使用选项--without-http_upstream_consistent_hash_module

    $ ./configure

  • 编译

    $ make

  • 安装模块

    $ make install

会话保持ngx_http_upstream_session_sticky_module



该模块是一个负载均衡模块,通过cookie实现客户端与后端服务器的会话保持, 在一定条件下可以保证同一个客户端访问的都是同一个后端服务器。

Example 1

# 默认配置:cookie=route mode=insert fallback=on
upstream foo {
   server 192.168.0.1;
   server 192.168.0.2;
   session_sticky;
}

server {
    location / {
        proxy_pass http://foo;
    }
}

Example 2

#insert + indirect模式:
upstream test {
  session_sticky cookie=uid domain=www.xxx.com fallback=on path=/ mode=insert option=indirect;
  server  127.0.0.1:8080;
}

server {
  location / {
    #insert + indirect模式或者prefix模式下需要配置session_sticky_hide_cookie
    #这种模式不会将保持会话使用的cookie传给后端服务,让保持会话的cookie对后端透明
    session_sticky_hide_cookie upstream=test;
    proxy_pass http://test;
  }
}

指令



语法:session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time] [mode=insert|rewrite|prefix] [option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]

默认值:session_sticky cookie=route mode=insert fallback=on

上下文:upstream

说明:

本指令可以打开会话保持的功能,下面是具体的参数:

  • cookie设置用来记录会话的cookie名称

  • domain设置cookie作用的域名,默认不设置

  • path设置cookie作用的URL路径,默认不设置

  • maxage设置cookie的生存期,默认不设置,即为session cookie,浏览器关闭即失效

  • mode设置cookie的模式:

    • insert: 在回复中本模块通过Set-Cookie头直接插入相应名称的cookie

    • prefix: 不会生成新的cookie,但会在响应的cookie值前面加上特定的前缀,当浏览器带着这个有特定标识的cookie再次请求时,模块在传给后端服务前 先删除加入的前缀,后端服务拿到的还是原来的cookie值,这些动作对后端透明。如:"Cookie: NAME=SRV~VALUE"

    • rewrite: 使用服务端标识覆盖后端设置的用于session stickycookie。如果后端服务在响应头中没有设置该cookie,则认为该请求不需要进行session sticky,使用这种模式,后端服务可以控制哪些请求需要sesstion sticky,哪些请求不需要。

  • option 设置用于session stickycookie的选项,可设置成indirectdirectindirect不会将session stickycookie传送给后端服务,该cookie对后端应用完全透明。direct则与indirect相反。

  • maxidle设置session cookie的最长空闲的超时时间

  • maxlife设置session cookie的最长生存期

  • fallback设置是否重试其他机器,当sticky的后端机器挂了以后,是否需要尝试其他机器

  • hash 设置cookieserver标识是用明文还是使用md5值,默认使用md5



语法: session_sticky_hide_cookie upstream=name;

默认值: none

上下文: server, location

说明:

配合proxy_pass指令使用。用于在insert+indirect模式和prefix模式下删除请求用于session stickycookie,这样就不会将该cookie传递给后端服务。upstream表示需要进行操作的upstream名称。




主动式后端服务器健康检查ngx_http_upstream_check_module



该模块可以为Tengine提供主动式后端服务器健康检查的功能。

该模块在Tengine-1.4.0版本以前没有默认开启,它可以在配置编译选项的时候开启:./configure --with-http_upstream_check_module

Examples

http {
    upstream cluster {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;

        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "GET / HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://cluster;
        }

        location /status {
            check_status;

            access_log   off;
            allow SOME.IP.ADD.RESS;
            deny all;
       }
    }
}

指令



Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]

Default: 如果没有配置参数,默认值是:interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp

Context: upstream

该指令可以打开后端服务器的健康检查功能。

指令后面的参数意义是:

  • interval:向后端发送的健康检查包的间隔。

  • fall(fall_count): 如果连续失败次数达到fall_count,服务器就被认为是down

  • rise(rise_count): 如果连续成功次数达到rise_count,服务器就被认为是up

  • timeout: 后端健康请求的超时时间。

  • default_down: 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。

  • type:健康检查包的类型,现在支持以下多种类型

    • tcp:简单的tcp连接,如果连接成功,就说明后端正常。

    • ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。

    • http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。

    • mysql: mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。

    • ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。

  • port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0



Syntax: check_http_send http_packet

Default: "GET / HTTP/1.0\r\n\r\n"

Context: upstream

该指令可以配置http健康检查包发送的请求内容。



Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]

Default: http_2xx | http_3xx

Context: upstream

该指令指定HTTP回复的成功状态,默认认为2XX3XX的状态是健康的。



Syntax: check_shm_size size

Default: 1M

Context: http

所有的后端服务器健康检查状态都存于共享内存中,该指令可以设置共享内存的大小。默认是1M,如果你有1千台以上的服务器并在配置的时候出现了错误,就可能需要扩大该内存的大小。



Syntax: check_status [html|csv|json]

Default: check_status html

Context: location

显示服务器的健康状态页面。该指令需要在http块中配置。

Tengine-1.4.0以后,你可以配置显示页面的格式。支持的格式有: htmlcsvjson。默认类型是html

你也可以通过请求的参数来指定格式,假设‘/status’是你状态页面的URLformat参数改变页面的格式,比如:

/status?format=html
/status?format=csv
/status?format=json

同时你也可以通过status参数来获取相同服务器状态的列表,比如:

/status?format=html&status=down
/status?format=csv&status=up

下面是一个HTML状态页面的例子(server number是后端服务器的数量,generationNginx reload的次数。Index是服务器的索引,Upstream是在配置中upstream的名称,Name是服务器IPStatus是服务器的状 态,Rise是服务器连续检查成功的次数,Fall是连续检查失败的次数,Check type是检查的方式,Check port是后端专门为健康检查设置的端口):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Nginx http upstream check status</title>
</head>
<body>
    <h1>Nginx http upstream check status</h1>
    <h2>Check upstream server number: 1, generation: 3</h2>
    <table style="background-color:white" cellspacing="0"        cellpadding="3" border="1">
        <tr bgcolor="#C0C0C0">
            <th>Index</th>
            <th>Upstream</th>
            <th>Name</th>
            <th>Status</th>
            <th>Rise counts</th>
            <th>Fall counts</th>
            <th>Check type</th>
            <th>Check port</th>
        </tr>
        <tr>
            <td>0</td>
            <td>backend</td>
            <td>106.187.48.116:80</td>
            <td>up</td>
            <td>39</td>
            <td>0</td>
            <td>http</td>
            <td>80</td>
        </tr>
    </table>
</body>
</html>

下面是csv格式页面的例子:

0,backend,106.187.48.116:80,up,46,0,http,80

下面是json格式页面的例子:

{"servers": {
  "total": 1,
  "generation": 3,
  "server": [
   {"index": 0, "upstream": "backend", "name": "106.187.48.116:80", "status": "up", "rise": 58, "fall": 0, "type": "http", "port": 80}
  ]
 }}



监控系统的负载和资源占用从而对系统进行保护


帮助更多ngx_http_sysguard_module



swap的剩余百分比,剩下的内存,load值到设定的值时,就会跳转到action所指定的url

    server {
        sysguard on;

        sysguard_load load=10.5 action=/loadlimit;
        sysguard_mem swapratio=20% action=/swaplimit;
        sysguard_mem free=100M action=/freelimit;
 

        location /loadlimit {
            return 503;
        }

        location /swaplimit {
            return 503;
        }

        location /freelimit {
            return 503;
        }
    }

注意,目前该模块仅对系统支持sysinfo函数时,才支持基于load与内存信息的保护,以及系统支持loadavg函数时支持基于load进行保护。模块需要从/proc文件系统中读取内存信息,模块默认没有编译,需要在编译时打开该模块: ./configure --with-http_sysguard_module

指令

Syntax: sysguard [on | off]
Default: sysguard off
Context: http, server, location

打开或者关闭这个模块

Syntax: sysguard_load load=number [action=/url]
Default: none
Context: http, server

该指令用于配置根据系统的load来限制用户的请求,以保护系统。当系统在一分钟内的load达到number时,将进来的请求转到action所指定的url。如果action没有配置,则直接返回503错误。

Syntax: sysguard_mem [swapratio=ratio%] [free=size] [action=/url]
Default: -
Context: http, server, location

该指定用于配置根据系统的内存使用状态来限制用户请求,以保护系统。swapratio用 于配置当当前交换空间的已使用ratio%时,或者剩下的内存少于size时,就将进来的请求跳转到指定的url。如果action没有配置,则直接返回 503错误。另外,如果用户自己禁用了交换区间,则配置该指定是不起作用的。free是根据/proc/meminfo的内容来计算的,计算公式 是"memfree= free + buffered + cached"

Syntax: sysguard_interval time
Default: sysguard_interval 1s
Context: http, server, location

该指定用于配置获取系统信息时的缓存时间。默认为1s,则表示在这1s内,只调用一次系统函数来获取系统的当前状况。

Syntax: sysguard_log_level [info | notice | warn | error]
Default: sysguard_log_level error
Context: http, server, location

该指令用于配置,当保护系统的操作执行时,记录日志时的日志级别。




显示对运维人员更友好的出错信息,便于定位出错机器

ngx_http_footer_filter_module

在请求的响应末尾输出一段内容。输出内容可配置,并支持内嵌变量。

    location / {
        root html;
        footer_types "text/plain" "text/css" "application/x-javascript";
        footer "$host_comment";
    }

指令

Syntax: footer format
Default: -
Context: http, server, location

在每个HTTP响应的正文结尾插入指定的format内容。如果format中含有变量,会被替换为变量当前的值。

举例:

    location / {
        footer "<!-- $hostname, $year/$month/$day $hour:$minute:$second, $request -->";
        index index.html;
    }

Syntax: footer_types type1 [type2] [type3]
Default: footer_types text/html
Context: http, server, location

定义需要插入footer的响应类型(Response Content-Type)。



更强大的防攻击(访问速度限制)模块

ngx_http_limit_req_module

指令

Syntax: limit_req_log_level info | notice | warn | error
Default: limit_req_log_level warn
Context: http

nginx相同。

Syntax: limit_req_zone $session_variable1 $session_variable2 ... zone=name_of_zone:size rate=rate
Default: -
Context: http

nginx类似,不过支持多个变量,并且支持多个limit_req_zone的设置。比如:

    limit_req_zone $binary_remote_addr zone=one:3m rate=1r/s;
    limit_req_zone $binary_remote_addr $uri zone=two:3m rate=1r/s;
    limit_req_zone $binary_remote_addr $request_uri zone=thre:3m rate=1r/s;

上面的第二个指令表示当相同的ip地址并且访问相同的uri,会导致进入limit req的限制(每秒1个请求)。

Syntax: limit_req [on | off] | zone=zone burst=burst [forbid_action=action] [nodelay]
Default: -
Context: http, server, location

zoneburst以及nodelay的使用与nginxlimit req模块中相同。

支持开关,默认是打开状态。并且一个location支持多个limit_req指令,当有多个limit_req指令的话,这些指令是或的关系,也就是当其中任意一个限制被触发,则执行对应的limit_req

forbid_action表示当条件被触发时,nginx所要执行的动作,支持name location和页面(/),默认是返回503。比如:

    limit_req_zone $binary_remote_addr zone=one:3m rate=1r/s;
    limit_req_zone $binary_remote_addr $uri zone=two:3m rate=1r/s;
    limit_req_zone $binary_remote_addr $request_uri zone=three:3m rate=1r/s;

    location / {
        limit_req zone=one burst=5;
        limit_req zone=two forbid_action=@test1;
        limit_req zone=three burst=3 forbid_action=@test2;
    }

    location /off {
        limit_req off;
    }

    location @test1 {
        rewrite ^ /test1.html;
    }

    location @test2 {
        rewrite ^  /test2.html;
    }

Syntax: limit_req_whitelist geo_var_name=var_name geo_var_value=var_value
Default: -
Context: http, server, location

表示白名单,要协同geo模块进行工作,其中geo_var_name表示geo模块设置的变量名,而geo_var_value表示geo模块设置的变量值。比如:

    geo $white_ip {
        ranges;
        default 0;
        127.0.0.1-127.0.0.255 1;
    }

    limit_req_whitelist geo_var_name=white_ip geo_var_value=1;

上面表示ip 127.0.0.1-127.0.0.255这个区间都会跳过limit_req的处理。



更方便的命令行参数,如列出编译的模块列表、支持的指令


命令行参数

        1. '-m' 选项

显示所有编译的模块,自1.4.0以来,Tengine支持动态模块,static表示静态编译,shared表示动态编译(后面接的是动态模块的版本)。下面是例子:

$ nginx -m
Tengine version: Tengine/1.4.1 (nginx/1.2.3)
loaded modules:
    ngx_core_module (static)
    ngx_errlog_module (static)
    ngx_conf_module (static)
    ngx_events_module (static)
    ngx_event_core_module (static)
    ngx_epoll_module (static)
    ngx_http_module (static)
    ngx_http_core_module (static)
    ngx_http_log_module (static)
    ngx_http_upstream_module (static)
    ngx_http_static_module (static)
    ngx_http_index_module (static)
    ngx_http_rewrite_module (static)
    ngx_http_proxy_module (static)
    ngx_http_memcached_module (shared, 1.1)
    ngx_http_write_filter_module (static)
    ngx_http_header_filter_module (static)
    ngx_http_chunked_filter_module (static)
    ngx_http_range_header_filter_module (static)
    ngx_http_gzip_filter_module (static)
    ngx_http_postpone_filter_module (static)
    ngx_http_headers_filter_module (static)
    ngx_http_copy_filter_module (static)
    ngx_http_range_body_filter_module (static)
    ngx_http_not_modified_filter_module (static)

        1. '-l' 选项

显示所有支持的指令:

$ nginx -l
Tengine version: Tengine/1.4.1 (nginx/1.2.3)
all available directives:
ngx_core_module:
    daemon
    master_process
    timer_resolution
    pid
    lock_file
    worker_processes
    debug_points
    user
    worker_priority
    worker_cpu_affinity
    worker_rlimit_nofile
    worker_rlimit_core
    worker_rlimit_sigpending
    working_directory
    env
ngx_dso_module:
    dso
ngx_http_memcached_module (shared):
    dso
    memcached_pass
    memcached_bind
    memcached_connect_timeout
    memcached_send_timeout
    memcached_buffer_size
    memcached_read_timeout
    memcached_next_upstream

[snip]

        1. '-d' 选项

输出配置文件的内容,包括'include'的内容:

$ nginx -d
# contents of file "/home/shudu/nginx/sandbox/conf/nginx.conf":

user shudu;
worker_processes 1;

worker_rlimit_core 1000M;
error_log logs/error.log debug;

#pid logs/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type application/octet-stream;

    access_log logs/access.log combined;

[snip]




更多变量


$conn_requests

当前请求在长连接上的序号

$dollar

表示美元符号本身

$request_time_msec

请求处理时间,单位是毫秒,用于log_format

$request_time_usec

请求处理时间,单位是微秒,用于log_format

$unix_time

当前时间戳,其值为197011日以来的秒数

$year

当前4位年(如2011

$year2

当前2位年(如11

$month

当前月份,有前导0(如12

$day

当前日,有前导0(如22

$hour

当前24小时制的小时,有前导0(如21

$hour12

当前12小时制的小时,有前导0(如09

$minute

当前分钟,有前导0(如55

$second

当前秒,有前导0(如12

$sent_cookie_XXX

响应Set-Cookie头中XXXcookie

$host_comment

主机名和时戳,内容类似于“<!-- localhost Thu, 29 Dec 2011 10:10:56 GMT -->”


ngx_http_headers_module

nginx本身原有的设置过期时间的基础上,增加了expires_by_types指令,用于根据Content-Type来设置过期时间。
原有的功能介绍看这里。

    expires_by_types       24h text/html;
    expires_by_types       modified +24h text/xml;
    expires_by_types       @15h30m text/xml;
    expires_by_types       0 text/xml;
    expires_by_types       -1 text/xml;
    expires_by_types       epoch text/xml;

指令

Syntax: expires_by_types [[modified] time | @time-of-day | epoch | max | off] content-type1
                  [content-type2] [content-type3] ...
Default: -
Context: http, server, location

该指令配置过期时间及其对应的content-type。过期时间的配置可参考expires的配置。在配置时间之后,可加上一到多个content-type

注意,在即有expires也有expires_by_types出现时,规则如下:

  • 在同一级别中,如果同时出现expiresexpires_by_type时,出现在expires_by_type中的content- type会优先选择expires_by_types中配置的,而没有出现在content-type中的,会选择expires中配置的;

  • 当本级别与上一级别都没有配置expires off时,expiresexpires_by_types当本级别没有配置时分配继承上一级别的配置信息,然后再按照规则一执行;

  • 当本级别配置有expires off时,此时模块会忽略expires_by_types的所有配置,并禁用掉expires

  • 当本级别没有配置expires,而上一级别有配置expires off时,本级别的expires_by_types将不受上一级别的expires的影响。

如:

    location /url {
        expires                10s;
        expires_by_types       24s text/html;
    }

此时,/url下面的文档,text/html类型的会返回24s的过期时间,而其它类型的会返回10s的过期时间。

    expires                    10s;
    expires_by_types           24s text/html;

    location /url {
        expires_by_types       20s text/rss;
    }

此时,/url下面的文档,text/rss类型的会返回20s的过期时间,而其它类型的会返回10s的过期时间。因为location里面的expires_by_types将上层的expires_by_types覆盖了。而expires 10s则被继承了下来。

    expires                    10s;
    expires_by_types           24s text/html;

    location /url {
        expires off;
        expires_by_types       20s text/rss;
    }

此时,/url下面的所有文档,都不会有过期时间。

    expires off;
    expires_by_types           24s text/html;

    location /url {
        expires_by_types       20s text/rss;
    }

此时,/url下面的文档,text/rss类型的会返回20s的过期时间,其它类型的没有过期时间。注意,expires off不会继承过来。




ngx_http_ssl_module


指令

Syntax: ssl_pass_phrase_dialog [builtin | exec:/path/to/exec]
Default: ssl_pass_phrase_dialog builtin
Context: http, server

设置tengine处理使用密钥加密的证书时,通过指定方式获取证书密钥。 类似于apache指令:SSLPassPhraseDialog 支持的参数:

  • builtin
    通过控制台交互方式获得密钥

  • exec:/path/to/exec
    执行/path/to/exec,将其输出结果作为密钥





ngx_http_stub_status_module



增加对每请求的响应时间的统计:在stub status模块中增加了自Tengine启动以来所有请求的总响应时间(request_time),单位为ms,可以用来统计一段时间的平均RT(response time)

    Active connections: 1
    server accepts handled requests request_time
     1140 1140 1140 75806
    Reading: 0 Writing: 1 Waiting: 0

tsar中监控Tengine/Nginx可以使用我们开发的tsar模块。





Tengine/Nginx module for tsar


这是一个tsar模块,它可以从Tengine/Nginx端采集数据.

源文件

下载源文件 (https://github.com/taobao/tsar-mod_nginx)

使用指南

1. 安装 tsar.
2.
使用tsar的模块开发工具tsardevel生成一个模块模板.(see tsar wiki)

tsardevel mod_ngx

3. 替换模板中的mod_ngx.c.

make
make install

4. 启动tsar.

tsar --nginx

配置

1. 默认采集地址和端口分别为127.0.0.1,80。可以通过环境变量来修改:
example:

export NGX_TSAR_HOST=192.168.0.1
export NGX_TSAR_PORT=8080

2. Tengine/Nginx必须编译了stub_status模块,而且必须在配置文件中增加类似如下配置:

location = /nginx_status {
    stub_status on;
}

3. 另外我们也可以使用unix域套接字,比如将NGX_TSAR_HOST指定为一个文件路径:

export NGX_TSAR_HOST=/tmp/nginx-tsar.sock

同时,Tengine/Nginx的配置文件中包含location /nginx_statusserver也必须是监听在该域套接口路径上

listen unix:/tmp/nginx-tsar.sock;

4. tsar模块发送给Tengine/Nginxuri和主机名也可以通过如下环境变量设置:
example:

export NGX_TSAR_SERVER_NAME=status.taobao.com
export NGX_TSAR_URI=/nginx_status

ngx_http_upstream_keepalive_module长连接超时设置



增加nginx后端长连接的超时支持:

    upstream backend {
        server 127.0.0.1:8080;
        keepalive;
        keepalive_timeout 30s; # 设置后端连接的最大idle时间为30s
    }

指令

Syntax: keepalive_timeout time
Default: -
Context: upstream

该指令设置后端长连接的最大空闲超时时间,参数的时间单位可以是s(秒),ms(毫秒),m(分钟)。默认时间单位是秒。





名称tfs



  • nginx-tfs

描述

  • 这个模块实现了TFS的客户端,为TFS提供了RESTful APITFS的全称是Taobao File System,是淘宝开源的一个分布式文件系统。

编译安装

  1. TFS模块使用了一个开源的JSON库来支持JSON,请先安装yajl-2.0.1

  2. 下载nginxtengine

  3. ./configure --add-module=/path/to/nginx-tfs

  4. make && make install

配置

http {
    tfs_upstream tfs_rc {
        server 127.0.0.1:6100;
        type rcs;
        rcs_zone name=tfs1 size=128M;
        rcs_interface eth0;
        rcs_heartbeat lock_file=/logs/lk.file interval=10s;
    }

    server {
          listen       7500;
          server_name  localhost;

          tfs_keepalive max_cached=100 bucket_count=10;
          tfs_log "pipe:/usr/sbin/cronolog -p 30min /path/to/nginx/logs/cronolog/%Y/%m/%Y-%m-%d-%H-%M-tfs_access.log";

          location / {
              tfs_pass tfs://tfs_rc;
          }
    }
}

指令

server

Syntaxserver address

Defaultnone

Contexttfs_upstream

指定后端TFS服务器的地址,当指令typercs时为RcServer的地址,如果为为ns时为NameServer的地址。此指令必须配置。例如:

server 10.0.0.1:8108;

type

Syntaxtype [ns | rcs]

Defaultns

Contexttfs_upstream

设置server类型,类型只能为ns或者rcs,如果为ns,则指令server指定的地址为NameServer的地址,如果为rcs,则为RcServer的地址。如需使用自定义文件名功能请设置类型为rcs,使用自定义文件名功能需额外配置MetaServerRootServer

rcs_zone

Syntaxrcs_zone name=n size=num

Defaultnone

Contexttfs_upstream

配置TFS应用在RcServer的配置信息。若开启RcServer(配置了type rcs),则必须配置此指令。配置此指令会在共享内存中缓存TFS应用在RcServer的配置信息,并可以通过指令rcs_heartbeat来和RcServer进行keepalive以保证应用的配置信息的及时更新。例如:

rcs_zone name=tfs1 size=128M;

rcs_heartbeat

Syntaxrcs_heartbeat lock_file=/path/to/file interval=time

Defaultnone

Contexttfs_upstream

配置TFS应用和RcServerkeepalive,应用可通过此功能来和RcServer定期交互,以及时更新其配置信息。若开启RcServer功能(配置了type rcs),则必须配置此指令。例如:

rcs_heartbeat lock_file=/path/to/nginx/logs/lk.file interval=10s;

rcs_interface

Syntaxrcs_interface interface

Defaultnone

Contexttfs_upstream

配置TFS模块使用的网卡。若开启RcServer功能(配置了type rcs),则必须配置此指令。例如:

rcs_interface eth0;

tfs_upstream

Syntaxtfs_upstream name {...}

Defaultnone

Contexthttp

配置TFS模块的server信息,这个块包括上面几个命令。例如:

tfs_upstream tfs_rc {
    server 127.0.0.1:6100;
    type rcs;
    rcs_zone name=tfs1 size=128M;
    rcs_interface eth0;
    rcs_heartbeat lock_file=/logs/lk.file interval=10s;
}

tfs_pass

Syntaxtfs_pass name

Defaultnone

Contextlocation

是否打开TFS模块功能,此指令为关键指令,决定请求是否由TFS模块处理,必须配置。需要注意,这里不支持直接写ip地址或者域名,这里只支持指令tfs_upstream name {...} 配置的upstream,并且必须以 tfs:// 开头。例如:

tfs_upstream tfs_rc {
};

location / {
    tfs_pass tfs://tfs_rc;
}

tfs_keepalive

Syntaxtfs_keepalive max_cached=num bucket_count=num

Defaultnone

Contexthttp, server

配置TFS模块使用的连接池的大小,TFS模块的连接池会缓存TFS模块和后端TFS服务器的连接。可以把这个连接池看作由多个hash桶构成的 hash表,其中bucket_count是桶的个数,max_cached是桶的容量。此指令必须配置。注意,应该根据机器的内存情况来合理配置连接池 的大小。例如:

tfs_keepalive max_cached=100 bucket_count=15;

tfs_block_cache_zone

Syntaxtfs_block_cache_zone size=num

Defaultnone

Contexthttp

配置TFS模块的本地BlockCache。配置此指令会在共享内存中缓存TFS中的BlockDataServer的映射关系。注意,应根据机器的内存情况来合理配置BlockCache大小。例如:

tfs_block_cache_zone size=256M;

tfs_log

Syntaxtfs_log path

Defaultnone

Contexthttp, server

是否进行TFS访问记录。配置此指令会以固定格式将访问TFS的请求记录到指定log中,以便进行分析。具体格式参见代码。例如:

tfs_log "pipe:/usr/sbin/cronolog -p 30min /path/to/nginx/logs/cronolog/%Y/%m/%Y-%m-%d-%H-%M-tfs_access.log";

注:cronolog支持依赖于tengine提供的扩展的日志模块。

tfs_body_buffer_size

Syntaxtfs_body_buffer_size size

Default8k|16k

Contexthttp, server, location

配置用于和后端TFS服务器交互时使用的的body_buffer的大小。默认为页大小的2倍。建议设为2m。例如:

tfs_body_buffer_size 2m;

tfs_connect_timeout

Syntaxtfs_connect_timeout time

Default3s

Contexthttp, server, location

配置连接后端TFS服务器的超时时间。

tfs_send_timeout

Syntaxtfs_send_timeout time

Default3s

Contexthttp, server, location

配置向后端TFS服务器发送数据的超时时间。

tfs_read_timeout

Syntaxtfs_read_timeout time

Default3s

Contexthttp, server, location

配置从后端TFS服务器接收数据的超时时间。

其他

能支持上传文件大小决定于client_max_body_size指令配置的大小。




  评论这张
 
阅读(1439)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017