说明

• NP: NGINX Plus
• AG: Admin Guide
• 会话: session
• 上游:  upstream
• 流量：traffic
• 后端：backend
• 区域：zone
• 切片：slices
• 位置：location
• 根：root
• 终端：termination
• 端点：endpoint

目录

1.实时活动监控

1.1.关于实时活动监控

1.2.先决条件

1.3.收集数据以显示在统计信息中

1.4.配置API

1.5.使用仪表板

1.6.访问仪表板

1.7.标签（tabs）概述

1.8.从仪表板管理上游服务器

1.9.配置仪表板选项

1.10.使用REST API

1.11.使用API获取统计信息

1.12.重置统计信息

1.13.使用API管理上游服务器

1.14.Swagger UI

1.15.使用Swagger UI

1.16.API Live示例

2.配置日志

2.1.设置错误日志

2.2.设置访问日志

2.3.启用条件日志

2.4.用例：采样TLS参数

2.5.记录到系统日志

2.6.实时活动监控

3.调试NGINX

3.1.介绍

3.2.配置NGINX二进制文件进行调试

3.3.配置NGINX Plus二进制

3.4.编译NGINX开源二进制文件

3.5.NGINX和调试符号

3.6.在NGINX配置中启用调试日志记录

3.6.1.将调试日志写入文件

3.6.2.将调试日志写入内存

3.6.3.从内存中提取调试日志

3.6.4.选定IP的调试日志

3.6.5.每个虚拟主机的调试日志

3.6.6.启用核心转储（Dumps）

3.6.7.在操作系统中启用核心转储（Dumps）

3.6.8.在NGINX配置中启用核心转储

3.6.9.从核心转储文件获取回溯（Backtrace）

3.6.10.从正在运行的进程中转储NGINX配置

3.7.寻求帮助

---

1.实时活动监控

介绍了如何在NGINX Plus中配置和使用运行时监视服务：交互式仪表板和NGINX Plus REST API。

1.1.关于实时活动监控

NGINX Plus为你的服务器基础架构提供了各种监视工具：

• 自NGINX Plus Release 9起提供的交互式仪表板页面-实时实时活动监视界面，显示服务器基础结构的关键负载和性能指标。
• NGINX Plus Release 14以后提供了NGINX REST API-一种可以获取扩展状态信息，重置统计信息，即时管理上游服务器以及管理键值存储的接口。 使用API，你可以将NGINX Plus状态信息与支持JSON接口的第三方工具（例如NewRelic或你自己的仪表板）连接。

注意：在NGINX Plus R14之前，仪表板中的上游服务器的统计信息和管理是使用status和upstream_conf模块执行的。 现在，扩展状态和上游模块模块已被api模块取代。 从R16开始，status和upstream_conf模块将被删除，并被api模块完全取代。

1.2.先决条件

• NGINX Plus R13及更高版本，用于NGINX Plus REST API和仪表板
• 统计数据（请参阅收集数据以显示在统计信息中）

1.3.收集数据以显示在统计信息中

为了从虚拟服务器，上游服务器组或缓存区域收集数据，你将需要为要为其收集数据的对象启用共享内存区域。 共享内存区域存储NGINX工作进程引用的配置和运行时状态信息。

• 要使HTTP和TCP服务器出现在统计信息中，请指定status_zone指令。 对于多个server块，可以多次指定相同的区域名称。 从R19开始，还可以为位置块指定status_zone指令-在这种情况下，将分别为仪表板中的服务器和位置汇总统计信息：

server {# ...status_zone status_page;location / {proxy_pass http://backend;status_zone location_zone;}
}

• 要使上游服务器组出现在统计信息中，请为每个upstream块指定zone指令：

upstream backend {zone   backend 64k;server backend1.example.com;server backend2.example.com;
}

• 要使缓存出现在统计信息中，请确保在配置中启用了缓存。 在keys_zone参数中的proxy_cache_path, fastcgi_cache_path, scgi_cache_path, uwsgi_cache_path指令中指定了用于缓存的共享内存区域。 有关更多信息，请参见NGINX Content Caching。

http {# ...proxy_cache_path /data/nginx/cache keys_zone=one:10m;
}

• 要使运行状况检查出现在统计信息中，请确保使用health_check 指令启用了运行状况检查，并且服务器组位于共享内存中。 有关更多信息，请参见HTTP运行状况检查和TCP运行状况检查：

server {# ...status_zone status_page;location / {proxy_pass http://backend;health_check;}
}

• 为了使集群信息出现在仪表板上，请确保在集群中组织了NGINX Plus实例，并且在每个实例上启用了区域同步。 有关详细信息，请参见群集中的运行时状态共享。
• 要使解析器统计信息出现在仪表板中，请指定resolver指令的status_zone 参数：

resolver 192.168.33.70 status_zone=resolver-zone1;server {# ...}

• 完成后，保存并退出配置文件。
• 测试配置并重新加载NGINX Plus：

sudo nginx -t && sudo nginx -s reload

1.4.配置API

启用API：

• 在http上下文中，指定将负责API的server块：

http {server {# your api configuration will be here}
}

• 为API请求创建一个location，并在此location指定api指令：

http {# ...server {listen 192.168.1.23;# ...location /api {api;# ...}}
}

• 为了通过API进行更改，例如重置统计信息计数器，实时管理上游服务器或键值存储，从仪表板管理上游服务器，请通过指定write=on参数来启用API的读写模式api指令：

http {# ...server {listen 192.168.1.23;# ...location /api {api write=on;# ...}}
}

• 建议限制访问此位置，例如，使用allow和deny指令仅允许从本地网络访问：

http {# ...server {listen 192.168.1.23;# ...location /api {api write=on;allow 192.168.1.0/24;deny  all;}}
}

• 在写入模式下启用API时，建议限制特定用户对PATCH, POST, DELETE方法的访问。 这可以通过实现HTTP basic authentication来完成：

http {...server {listen 192.168.1.23;# ...location /api {limit_except GET {auth_basic "NGINX Plus API";auth_basic_user_file /path/to/passwd/file;}api   write=on;allow 192.168.1.0/24;deny  all;}}
}

• 通过指定/dashboard.html位置来启用仪表板。 缺省情况下，仪表板位于由root指令指定的根目录（例如/usr/share/nginx/html）中：

http {...server {listen 192.168.1.23;# ...location /api {limit_except GET {auth_basic "NGINX Plus API";auth_basic_user_file /path/to/passwd/file;}api   write=on;allow 192.168.1.0/24;deny  all;}location = /dashboard.html {root   /usr/share/nginx/html;}}
}

• 通过为其创建位置来启用Swagger UI，例如，/swagger-ui。 默认情况下，Swagger UI位于root指令指定的根目录中，例如/usr/share/nginx/html：

http {# ...server {listen 192.168.1.23;# ...location /api {limit_except GET {auth_basic "NGINX Plus API";auth_basic_user_file /path/to/passwd/file;}api   write=on;allow 192.168.1.0/24;deny  all;}location = /dashboard.html {root   /usr/share/nginx/html;}location /swagger-ui {root   /usr/share/nginx/html;}}
}

1.5.使用仪表板

NGINX Plus仪表板提供了实时实时活动监视界面，该界面显示了服务器基础架构的关键负载和性能指标。

1.6.访问仪表板

在浏览器的地址栏中，输入与仪表板页面相对应的地址（在我们的示例中为http://192.168.1.23/dashboard.html）。 这将显示root指令中指定的位于/usr/share/nginx/html的“仪表板（Dashboard ）”页面。

NGINX还提供了一个实时演示页面，可访问demo.nginx.com/dashboard.html：

1.7.标签（tabs）概述

选项卡中显示了NGINX Plus仪表板中的所有信息。

HTTP Zones 选项卡提供了有关前端性能的详细统计信息。 在http上下文中按每个服务器，位置和limit_req区域显示统计信息。 为了使NGINX Plus能够收集每个服务器的信息，必须在每个服务器或位置块中包括status_zone指令。 要包括limit_req限制的图表，必须配置limit_req_zone 指令。

“TCP/UDP Zones”选项卡上显示带有连接限制图表（limit_conn）的TCP和UDP状态区域。

“HTTP Upstreams”选项卡提供有关HTTP和HTTPS流量的每个上游组的信息。 TCP和UDP上游组出现在“TCP/UDP Upstreams”选项卡上。 为了使NGINX Plus收集上游组的信息，必须在upstream配置块中包括zone指令。

Caches选项卡提供有关NGINX Plus中配置的缓存的统计信息。 为了使NGINX Plus能够收集上游组的信息，必须配置缓存。

“Shared Zones”选项卡显示每个共享内存区域使用了多少内存，包括高速缓存区域，SSL会话高速缓存，上游区域，键值区域，会话日志，粘性会话，limit_conn和limit_req区域。

“Cluster”选项卡提供了所有NGINX群集节点之间共享内存区域的同步状态。 有关如何组织集群中的NGINX实例以及配置所有集群节点之间的同步的详细信息，请参见集群中的运行时状态共享。

“Resolvers”选项卡提供每个DNS状态区域的请求和响应的DNS服务器统计信息。 为了使NGINX Plus收集有关你的DNS服务器的信息，请在resolver指令中包含status_zone参数。

1.8.从仪表板管理上游服务器

你可以直接从仪表板界面添加新的或修改和删除上游服务器。 请注意，你必须事先在写入模式下启用api 。

在“Upstreams”或“TCP/UDP Upstreams”选项卡中，单击服务器名称旁边的铅笔图标，然后在“Edit selected”和“Add server按钮之间进行选择：

要添加上游服务器，请单击添加服务器：

要删除或修改上游服务器，请单击每个服务器名称左侧的框，然后单击“Edit selected”：

完成后，单击“Save”按钮以保存更改。

1.9.配置仪表板选项

你可以通过单击“Gear”菜单中的“Tabs”按钮来配置仪表板警告和警报的阈值：

• Update every N sec-在指定的秒数后更新仪表板数据，默认值为1秒。
• 4xx warnings threshold - 表示HTTP Upstreams和 HTTP Zones的请求总数与4xx错误之间的比率。 默认值为30%。
• Calculate hit ratio for the past N sec - 表示指定的秒数内所有Caches命中次数。 默认值为300秒。
• Not synced data threshold - 表示集群（Clusters）的待处理（Pending）记录与总记录之间的比率。 默认值为70%。
• Resolver errors threshold - 表示在“Update every N sec”中为解析程序（Resolvers）指定的时间范围内，请求（Requests）与解析程序（resolver）错误之间的比率。 默认值为3%。

1.10.使用REST API

使用NGINX Plus，可以使用REST API接口管理服务器基础结构的统计信息。 该API基于标准的HTTP请求：可以使用GET请求获得统计信息，并使用DELETE请求进行重置。 上游服务器可以添加POST请求，也可以使用PATCH请求进行修改。 有关更多信息，请参阅使用API管理上游服务器。

请求以JSON格式发送，允许你将统计信息连接到支持JSON的监视工具或仪表板。

1.11.使用API获取统计信息

可以使用斜杠分隔的URL访问任何元素的状态信息。该URL可能如下所示：

http://demo.nginx.com/api/6/http/caches/http_cache?fields=expired,bypass

• /api 是你在NGINX配置文件中为API配置的位置
• /6 是API版本，当前的API版本是6
• /http/caches/http_cache是资源的路径
• ?fields=expired,bypass 是一个可选参数，用于指定将输出所请求对象的哪些字段

所请求的信息以JSON数据格式返回。

要获取所有可用根点的列表，请在终端中使用“curl”命令发送GET 请求（在示例中，使用JSON漂亮的打印扩展名“ json_pp”）：

curl -s 'https://demo.nginx.com/api/6/' | json_pp

JSON数据返回：

["nginx","processes","connections","slabs","http","stream","resolvers","ssl"
]

要获取特定端点的统计信息，例如，获取有关NGINX的常规信息，请发送以下GET请求：

curl -s 'https://demo.nginx.com/api/6/nginx' | json_pp

JSON数据返回：

{"generation" : 14,"timestamp" : "2020-06-10T14:04:51.515Z","pid" : 2201,"address" : "206.251.255.64","build" : "nginx-plus-r22","version" : "1.19.0","load_timestamp" : "2020-06-10T10:00:00.114Z","ppid" : 92033
}

你可以在请求行中使用可选的fields 参数指定将输出所请求对象的哪些字段。 例如，要仅显示NGINX Plus版本和构建，请指定命令：

curl -s'https://demo.nginx.com/api/6/nginx?fields=version,build'| json_pp

JSON数据返回：

{"version" : "1.19.0","build" : "nginx-plus-r22"
}

有关可用端点和支持的方法的完整列表，请参见参考文档。

1.12.重置统计信息

通过将具有DELETE方法的API命令发送到目标端点来执行重置统计信息。 确保你的API已配置为读写模式。

你可以重置以下类型的统计信息：

• 异常终端并重新生成的子进程
• 接受和删除客户端连接
• SSL握手和会话（session）重用
• 每个内存插槽的reqs和fails指标
• 客户端HTTP请求总数
• 在特定的HTTP服务器区域中接受和丢弃的请求，响应，接收和发送的字节
• 特定缓存区域中的缓存命中（hits）和缓存未命中（misses ）
• 上游服务器组中特定http或流上游服务器的统计信息

例如，要重置异常终止和重生的子进程的数量，你可以在终端中通过curl执行以下命令：

curl -X DELETE -s 'http://192.168.1.23/api/6/processes'

要重置接受和删除的客户端连接，请执行以下命令：

curl -X DELETE  -s 'http://192.168.1.23/api/6/connections'

1.13.使用API管理上游服务器

NGINX Plus REST API支持POST和PATCH HTTP方法，以将服务器动态添加到上游组或修改服务器参数。

要动态更改上游组的配置，请使用适当的API方法发送HTTP请求。 以下示例使用curl命令，但是支持任何发出HTTP请求的机制。 所有请求主体和响应均为JSON格式。

URI按此顺序指定以下信息：

• 处理请求的节点的主机名或IP地址（在以下示例中为192.168.1.23）
• api指令出现的位置（api）
• API版本（6）
• 上游组的名称，在NGINX Plus配置层次结构中的位置完整，以斜杠分隔的路径表示（http/upstreams/appservers）

例如，要将新服务器添加到appservers上游组，请发送以下curl命令：

curl -X POST -d '{ \"server": "10.0.0.1:8089", \"weight": 4, \"max_conns": 0, \"max_fails": 0, \"fail_timeout": "10s", \"slow_start": "10s", \"backup": true, \"down": true \}' -s 'http://192.168.1.23/api/6/http/upstreams/appservers/servers'

要从上游组中删除服务器：

curl -X DELETE -s 'http://192.168.1.23/api/6/http/upstreams/appservers/servers/0'

要为组中第一台服务器（ID为0）设置down参数：

curl -X PATCH -d '{ "down": true }' -s 'http://192.168.1.23/api/6/http/upstreams/appservers/servers/0'

1.14.Swagger UI

NGINX Plus包含一个集成的Swagger UI页面，使你可以浏览REST API文档并使用图形用户界面发送API命令。

1.15.使用Swagger UI

要访问Swagger UI页面：

• 在浏览器的地址栏中，输入Swagger UI的地址，在我们的示例中，该地址为 http://192.168.1.23/swagger-ui/：

• 如果你已为Swagger UI页面配置了HTTPS协议，则需要在“Schemes”菜单中选择“HTTPS”方案。
• 单击要执行的操作。
• 点击Try it out。
• 如果需要，请填写必填字段。 通常，必填字段是共享内存区域的名称。
• 作为一种选择，你只能显示特定的字段。 在“Fields”行中，指定要显示的字段，以逗号分隔。 如果未指定任何字段，则显示所有字段。
• 单击Execute。 结果和相应的HTTP错误代码将显示在Execute命令下方。

1.16.API Live示例

NGINX在演示网站上提供了JSON数据和Swagger UI的实时示例。

有关JSON数据的实时示例，请访问：https://demo.nginx.com/api/6/

你可以通过curl或浏览器发送API命令：

curl -s 'http://demo.nginx.com/api/6/'
curl -s 'http://demo.nginx.com/api/6/nginx?fields=version,build'
curl -s 'http://demo.nginx.com/api/6/http/caches/http_cache'
curl -s 'http://demo.nginx.com/api/6/http/upstreams/'
curl -s 'http://demo.nginx.com/api/6/http/upstreams/demo-backend'
curl -s 'http://demo.nginx.com/api/6/http/upstreams/demo-backend/servers/0'

Swagger UI演示页面位于：http://demo.nginx.com/swagger-ui/

实时示例以只读模式运行，无法通过DELETE方法重置统计信息，并且无法使用POST/PATCH方法创建/修改上游服务器。 还要注意，由于演示API是通过HTTP协议提供的，因此需要在Swagger UI演示页面的“Schemes”菜单中选择“HTTP”方案。

2.配置日志

介绍如何在NGINX Open Source和NGINX Plus中配置错误和已处理请求的日志记录。

2.1.设置错误日志

NGINX将有关严重性级别不同的问题的信息写入错误日志。 error_log指令将日志记录设置到特定文件，stderr或syslog ，并指定要记录的消息的最低严重性级别。 默认情况下，错误日志位于logs/error.log（绝对路径取决于操作系统和安装），并且记录来自指定级别以上的所有严重性级别的消息。

下面的配置将错误消息的最低严重性级别更改为从错误记录到警告：

error_log logs/error.log warn;

在这种情况下，将记录warn, error crit, alert, emerg级别的消息。

错误日志的默认设置在全局范围内起作用。 要覆盖它，请将error_log 指令放置在main（顶层）配置上下文中。 main上下文中的设置始终由其他配置级别（http, server, location）继承。 还可以在http，（http, stream, server, location）级别指定error_log 指令，并覆盖从更高级别继承的设置。 如果发生错误，则仅将消息写入一个错误日志，该日志最接近发生错误的级别。 但是，如果在同一级别上指定了多个error_log 指令，则将消息写入所有指定的日志中。

注意：NGINX开源版本1.5.2中增加了在同一配置级别上指定多个error_log指令的功能。

2.2.设置访问日志

NGINX处理完请求后，立即在访问日志中写入有关客户端请求的信息。 默认情况下，访问日志位于logs/access.log，并且信息以预定义的组合格式写入日志。 要覆盖默认设置，请使用log_format指令更改日志消息的格式，并使用access_log指令指定日志的位置及其格式。 日志格式是使用变量定义的。

以下示例定义了日志格式，该日志格式使用表示响应的gzip压缩率的值扩展了预定义的组合格式。 然后将该格式应用于启用压缩的虚拟服务器。

http {log_format compression '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''"$http_referer" "$http_user_agent" "$gzip_ratio"';server {gzip on;access_log /spool/logs/nginx-access.log compression;...}
}

日志格式的另一个示例使你可以跟踪NGINX和上游服务器之间的不同时间值，如果你的网站运行缓慢，这可能有助于诊断问题。 你可以使用以下变量来记录指示的时间值：

• $upstream_connect_time – 与上游服务器建立连接所花费的时间
• $upstream_header_time – 从建立连接到从上游服务器接收响应头的第一个字节之间的时间
• $upstream_response_time – 从建立连接到从上游服务器接收响应主体的最后一个字节之间的时间
• $request_time – 处理请求所花费的总时间

所有时间值均以毫秒为单位，以毫秒为单位进行测量。

http {log_format upstream_time '$remote_addr - $remote_user [$time_local] ''"$request" $status $body_bytes_sent ''"$http_referer" "$http_user_agent"''rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';server {access_log /spool/logs/nginx-access.log upstream_time;...}
}

以下是一些规则，如何读取结果时间值：

• 通过多个服务器处理请求时，该变量包含多个值，以逗号分隔
• 当存在从一个上游组到另一个上游组的内部重定向时，这些值用分号分隔
• 当请求无法到达上游服务器或无法接收到完整的标头时，变量将包含“0”（零）
• 如果在连接上游时发生内部错误或从缓存中获取回复，则变量包含“-”（连字符）

通过启用日志消息缓冲区和名称包含变量的常用日志文件描述符的缓存，可以优化日志记录。 要启用缓冲，请使用access_log指令的buffer参数指定缓冲区的大小。 然后，在下一条日志消息不适合缓冲区时以及在某些其他情况下，将缓冲的消息写入日志文件。

要启用日志文件描述符的缓存，请使用open_log_file_cache指令。

与error_log指令类似，在特定配置级别上定义的access_log指令将覆盖先前级别的设置。 请求处理完成后，消息将被写入当前级别配置的日志，或者从先前级别继承。 如果一个级别定义了多个访问日志，则将消息写入所有日志。

2.3.启用条件日志

条件日志记录允许从访问日志中排除琐碎或不重要的日志条目。 在NGINX中，通过access_log指令的 if 参数启用条件日志记录。

本示例不包括HTTP状态码为2xx（成功）和3xx（重定向）的请求：

map $status $loggable {~^[23]  0;default 1;
}access_log /path/to/access.log combined if=$loggable;

2.4.用例：采样TLS参数

许多客户端使用的TLS版本早于TLS 1.3。 尽管许多密码（ciphers）被宣布为不安全的，但是较旧的实现仍使用它们。 ECC证书比RSA提供更高的性能，但并非所有客户端都可以接受ECC。 许多TLS攻击都依靠“中间人”来拦截密码（ciphers）协商握手，并迫使客户端和服务器选择不太安全的密码（ciphers）。 因此，将NGINX Plus配置为不支持弱密码或旧密码很重要，但是这样做可能会排除旧客户端。

你可以评估从客户端获取的SSL数据，并确定如果删除了对较旧的SSL协议和密码（ciphers）的支持，则排除了多少比例的客户端。

以下配置示例记录了所有连接的TLS客户端的SSL协议，密码（cipher）和User-Agent标头，假设每个客户端选择了它支持的最新协议和最安全的密码。

在此示例中，每个客户端都通过其IP地址和用户代理（User-Agent）的唯一组合来标识。

1.定义自定义日志格式sslparams，其中包括SSL协议的版本（$ssl_protocol），连接中使用的密码（$ssl_cipher），客户端IP地址（$remote_addr）和标准用户代理HTTP请求字段的值（$http_user_agent）：

log_format sslparams '$ssl_protocol $ssl_cipher ''$remote_addr "$http_user_agent"';

2.定义键值存储，该键值存储将保留客户端及其用户代理（例如，clients）的IP地址：

keyval_zone zone=clients:80m timeout=3600s;

3.为$remote_addr和User-Agent标头的每个唯一组合创建一个变量，例如$seen：

keyval $remote_addr:$http_user_agent $seen zone=clients;server {listen 443 ssl;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_ciphers   HIGH:!aNULL:!MD5;if ($seen = "") {set $seen  1;set $logme 1;}access_log  /tmp/sslparams.log sslparams if=$logme;# ...
}

4.查看使用此配置生成的日志文件：

TLSv1.2 AES128-SHA 1.1.1.1 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 2.2.2.2 "Mozilla/5.0 (iPhone; CPU iPhone OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1"
TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 3.3.3.3 "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0"
TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 4.4.4.4 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
TLSv1 AES128-SHA 5.5.5.5 "Mozilla/5.0 (Android 4.4.2; Tablet; rv:65.0) Gecko/65.0 Firefox/65.0"
TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305 6.6.6.6 "Mozilla/5.0 (Linux; U; Android 5.0.2; en-US; XT1068 Build/LXB22.46-28) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.10.2.1164 Mobile Safari/537.36"

5.处理日志文件以确定数据的传播：

cat /tmp/sslparams.log | cut -d ' ' -f 2,2 | sort | uniq -c | sort -rn | perl -ane 'printf "%30s %s\n", $F[1], "="x$F[0];'

6.在此输出中，确定了低容量，不太安全的密码：

ECDHE-RSA-AES128-GCM-SHA256 =========================
ECDHE-RSA-AES256-GCM-SHA384 ========AES128-SHA ====
ECDHE-RSA-CHACHA20-POLY1305 ==ECDHE-RSA-AES256-SHA384 ==

然后，你可以检查日志以确定哪些客户端正在使用这些密码，然后决定从NGINX Plus配置中删除这些密码。

有关使用NGINX条件日志记录采样请求的更多信息，请参阅博客文章。

2.5.记录到系统日志

syslog实用程序是计算机消息日志记录的标准，并允许从单个syslog服务器上的不同设备收集日志消息。 在NGINX中，使用error_log 和access_log 指令中的syslog:前缀来配置登录到syslog。

可以将Syslog消息发送到server=，该server=可以是域名，IP地址或UNIX域套接字路径。 可以使用端口指定域名或IP地址，以覆盖默认端口514。可以在unix:前缀后指定UNIX域（UNIX-domain）套接字路径：

error_log  syslog:server=unix:/var/log/nginx.sock debug;
access_log syslog:server=[2001:db8::1]:1234,facility=local7,tag=nginx,severity=info;

在示例中，NGINX错误日志消息在debug日志记录级别被写入UNIX域套接字，而访问日志被写入具有IPv6地址和端口1234的syslog服务器。

facility= 参数指定记录消息的程序的类型。 默认值为local7。 其他可能的值包括：auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0 ... local7。

 tag= 参数将自定义标签应用于系统日志消息（在我们的示例中为nginx）。

 severity= 参数设置访问日志的系统日志消息的严重性级别。 严重性从高到低的可能值包括：debug, info, notice, warn, error（默认）, crit, alert, and emerg。 消息以指定级别和所有更严重级别记录。 在我们的示例中，严重性级别错误还使crit, alert, emerg级别得以记录。

2.6.实时活动监控

NGINX Plus提供了一个实时实时活动监视界面，该界面显示了HTTP和TCP上游服务器的关键负载和性能指标。 有关更多信息，请参见实时活动监视文章。

要了解有关NGINX Plus的更多信息，请访问产品页面。

3.调试NGINX

3.1.介绍

如果出现问题，调试有助于识别程序代码中的错误。 它通常用于开发或测试第三方或实验模块。

NGINX的调试功能包括调试日志以及带有进一步回溯的核心转储文件的创建。

3.2.配置NGINX二进制文件进行调试

首先，你需要在NGINX二进制文件中启用调试。 NGINX Plus已经为你提供了nginx-debug二进制文件，而NGINX Open Source需要重新编译。

3.3.配置NGINX Plus二进制

从Release 8开始，NGINX Plus附带了nginx-debug二进制文件和标准二进制文件。 要在NGINX Plus中启用调试，你需要从nginx切换到nginx-debug二进制文件。 打开终端并运行命令：

$ service nginx stop && service nginx-debug start

完成后，在配置文件中启用调试日志。

3.4.编译NGINX开源二进制文件

要在NGINX开源中启用调试，你将需要使用configure脚本中指定的--with-debug标志重新编译它。

要使用调试支持编译NGINX开源代码：

1.下载并解压缩NGINX源文件，并转到包含源文件的目录。 请参阅下载源码。

2.获取NGINX配置参数列表。 运行命令：

$ nginx -V 2>&1 | grep arguments

3.将--with-debug选项添加到配置命令列表中，然后运行配置脚本：

$ ./configure --with-debug 

4.编译并安装NGINX：

$ sudo make
$ sudo make install

5.重新启动NGINX

3.5.NGINX和调试符号

调试符号有助于获取其他调试信息，例如函数，变量，数据结构，源文件和行号信息。

默认情况下，NGINX使用包含调试符号的“-g”标志进行编译。

但是，如果在运行回溯时收到“No symbol table info available”错误，则调试符号丢失，你将需要在支持调试符号的情况下重新编译NGINX。

编译器标志的确切集合取决于编译器。 例如，对于GCC编译器系统：

• 包含带有“-g”标志的调试符号
• 通过使用“-O0”标志禁用编译器优化，使调试器的输出更易于理解：

$ ./configure --with-debug --with-cc-opt='-O0 -g' ...

3.6.在NGINX配置中启用调试日志记录

调试日志记录错误和任何与调试有关的信息，并且默认情况下处于禁用状态。 要启用它，请确保已编译NGINX以支持调试（请参阅配置NGINX二进制文件进行调试），然后使用error_log指令的debug参数在NGINX配置文件中启用它。 调试日志可以写入文件，内存中分配的缓冲区，stderr输出或syslog。

建议在NGINX配置的“main”级别上启用调试日志，以全面了解正在发生的事情。

3.6.1.将调试日志写入文件

将调试日志写入文件可能会降低高负载下的性能。 另请注意，文件可能会变得很大，并很快耗尽磁盘空间。 为了减少负面影响，你可以配置调试日志以将其写入内存缓冲区，或为特定IP地址设置调试日志。 有关详细信息，请参见将调试日志写入内存和选定IP的调试日志。

要将调试日志写入文件：

1.确保使用--with-debug配置选项配置了NGINX。 运行命令并检查输出是否包含--with-debug行：

$ nginx -V 2>&1 | grep -- '--with-debug'

2.打开NGINX配置文件：

$ sudo vi /etc/nginx/nginx.conf

3.查找默认情况下位于main上下文中的error_log指令，并将日志记录级别更改为debug。 如有必要，请更改日志文件的路径：

error_log  /var/log/nginx/error.log debug;

4.保存配置并退出配置文件。

3.6.2.将调试日志写入内存

可以使用循环缓冲区将调试日志写入内存。 优点是在调试级别登录将不会对高负载下的性能产生重大影响。

要将调试日志写入内存：

1.确保使用--with-debug配置选项配置了NGINX。 运行命令并检查输出是否包含--with-debug行：

$ nginx -V 2>&1 | grep -- '--with-debug'

2.在NGINX配置文件中，使用在main上下文中指定的error_log指令启用用于调试日志记录的内存缓冲区：

error_log memory:32m debug;
...
http {...
}

3.6.3.从内存中提取调试日志

可以使用GDB调试器中执行的脚本从内存缓冲区中提取日志。

要从内存中提取调试日志：

1.获取NGINX工作进程的PID：

$ ps axu |grep nginx

2.启动GDB调试器：

$ sudo gdb -p 

3.复制脚本，将其粘贴到GDB，然后按“Enter”。 该脚本会将日志保存在当前目录中的debug_log.txt 文件中：

set $log = ngx_cycle->log
while $log->writer != ngx_log_memory_writerset $log = $log->next
end
set $buf = (ngx_log_memory_buf_t *) $log->wdata
dump binary memory debug_log.txt $buf->start $buf->end

4.通过选定IP的调试日志按CTRL + D退出GDB。

5.打开位于当前目录中的文件“debug_log.txt”：

$ sudo less debug_log.txt

3.6.4.选定IP的调试日志

可以为特定IP地址或IP地址范围启用调试日志。 记录特定IP在生产环境中可能有用，因为它不会对性能产生负面影响。 IP地址在events块中的debug_connection指令中指定； 该指令可以多次定义：

error_log /path/to/log;
...
events {debug_connection 192.168.1.1;debug_connection 192.168.10.0/24;
}

3.6.5.每个虚拟主机的调试日志

通常，error_log指令在main上下文中指定，因此可应用于所有其他上下文，包括server和location。 但是，如果在特定server或location块中指定了另一个error_log指令，则全局设置将被覆盖，并且此类error_log指令将设置其自己的日志文件路径和日志记录级别。

要为特定虚拟主机设置调试日志，请在特定服务器块内添加error_log指令，在其中设置日志文件的新路径和debug日志记录级别：

error_log /path1/to/log debug;
...
http {...server {error_log /path2/to/log debug;...}
}

要针对每个特定的虚拟主机禁用调试日志，请在特定的server块内指定error_log指令，并仅指定日志文件的路径：

error_log /path/to/log debug;
...
http {...server {error_log /path/to/log;...}
}

3.6.6.启用核心转储（Dumps）

请注意，核心转储文件可能包含敏感信息，例如密码和私钥，因此请确保以安全的方式进行处理。

可以通过两种不同的方式启用核心转储：

• 在操作系统中
• 在NGINX配置文件中

3.6.7.在操作系统中启用核心转储（Dumps）

在操作系统中执行以下步骤：

1.指定将在其中保存核心转储（dump）文件的工作目录，例如“/tmp/cores”：

$ mkdir /tmp/cores

2.确保该目录可由NGINX工作进程可写：

$ sudo chown root:root /tmp/cores
$ sudo chmod 1777 /tmp/cores

3.禁用核心转储文件的最大大小限制：

$ ulimit -c unlimited

如果操作以“Cannot modify limit: operation not permitted”结束，请运行以下命令：

$ sudo sh -c "ulimit -c unlimited && exec su $LOGNAME"

4.为setuid和setgid进程启用核心转储。

对于CentOS 7.0，Debian 8.2，Ubuntu 14.04，运行以下命令：

$ echo "/tmp/cores/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern
$ sudo sysctl -w fs.suid_dumpable=2
$ sysctl -p

对于FreeBSD，请运行以下命令：

$ sudo sysctl kern.sugid_coredump=1
$ sudo sysctl kern.corefile=/tmp/cores/%N.core.%P

3.6.8.在NGINX配置中启用核心转储

如果你已经在操作系统中配置了核心转储文件的创建，请跳过这些步骤。

要在NGINX配置文件中启用核心转储：

1.打开NGINX配置文件：

$ sudo vi  /usr/local/etc/nginx/nginx.conf

2.使用working_directory指令定义一个目录，该目录将保留核心转储文件。 该指令在main配置级别上指定：

working_directory /tmp/cores/;

3.确保该目录存在并且可由NGINX worker进程写入。 打开终端并运行命令：

$ sudo chown root:root /tmp/cores
$ sudo chmod 1777 /tmp/cores

4.使用worker_rlimit_core指令指定核心转储文件的最大可能大小。 该指令也在main配置级别上指定。 如果核心转储文件大小超过该值，将不会创建核心转储文件。

worker_rlimit_core 500M;

例子：

worker_processes   auto;
error_log          /var/log/nginx/error.log debug;
working_directory  /tmp/cores/;
worker_rlimit_core 500M;events {...
}http {...
}

使用这些设置，将在“/tmp/cores/”目录中创建一个核心转储文件，并且仅在其大小不超过500兆字节时创建。

3.6.9.从核心转储文件获取回溯（Backtrace）

回溯提供核心转储文件中有关程序崩溃时出了什么问题的信息。

要从核心转储文件获取回溯，请执行以下操作：

1.使用以下模式，使用GDB调试器打开核心转储文件：

$ sudo gdb  

2.键入“backtrace命令”以获取崩溃时的堆栈跟踪：

(gdb) backtrace

如果“backtrace”命令产生“No symbol table info available”消息，则你将需要重新编译NGINX二进制文件以包含调试符号。 请参阅NGINX和调试符号。

3.6.10.从正在运行的进程中转储NGINX配置

你可以从内存中的主进程中提取当前的NGINX配置。 当你需要：

• 验证已加载的配置
• 如果磁盘上的版本被意外删除或覆盖，请还原以前的配置

如果你的NGINX具有调试支持，则可以使用GDB脚本获得配置转储。

1.确保你的NGINX内置了调试支持（configure参数列表中的--with-debug configure选项）。 运行命令并检查输出是否包含--with-debug行：

$  nginx -V 2>&1 | grep -- '--with-debug'

2.获取NGINX工作进程的PID：

$ ps axu | grep nginx

3.启动GDB调试器：

$ sudo gdb -p 

4.复制脚本并将其粘贴到GDB，然后按“Enter”。 该脚本会将配置保存在当前目录的nginx_conf.txt文件中：

set $cd = ngx_cycle->config_dump
set $nelts = $cd.nelts
set $elts = (ngx_conf_dump_t*)($cd.elts)
while ($nelts-- > 0) 
set $name = $elts[$nelts]->name.data
printf "Dumping %s to nginx_conf.txt\n", $name
append memory nginx_conf.txt \$elts[$nelts]->buffer.start $elts[$nelts]->buffer.end
end

5.通过按CTRL + D退出GDB。

6.打开位于当前目录中的文件nginx_conf.txt：

$ sudo vi nginx.conf.txt

3.7.寻求帮助

在寻求调试帮助时，请提供以下信息：

1.NGINX版本，编译器版本和配置参数。 运行命令：

$ nginx -V

2.当前完整的NGINX配置。 请参阅从正在运行的进程中转储NGINX配置

3.调试日志。 请参阅在NGINX配置中启用调试日志记录

4.获得的回溯。 请参阅启用核心转储，获取回溯

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！