Nginx【有与无】【NP-AG6-1】监控方式--实时活动监控

最新推荐文章于 2024-04-30 08:47:48 发布
最新推荐文章于 2024-04-30 08:47:48 发布
阅读量812 收藏 1
点赞数
分类专栏： Nginx 文章标签： nginx
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u012549626/article/details/111741693
版权

说明

  • 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模块完全取代。

live activity monitoring

1.2.先决条件

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;
}

http {
    # ...
    proxy_cache_path /data/nginx/cache keys_zone=one:10m;
}
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;
            # ...
        }
    }
}
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：

live activity monitor

1.7.标签（tabs）概述

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

The row of tabs at the top of the window on the NGINX Plus dashboard make it easy to drill down to more detailed information about server zones, upstream groups, or the cache

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

The 'HTTP zones' tab in the NGINX Plus live activity monitoring dashboard displays information about NGINX Plus' interaction with clients

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

The 'TCP/UDP zones' tab in the NGINX Plus live activity monitoring dashboard

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

The 'Upstreams' tab on the NGINX Plus live activity monitoring dashboard provides information about the servers in each upstream group for HTTP/HTTPS traffic

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

The 'Caches' tab in the NGINX Plus live activity monitoring dashboard provides information about cache readiness, fullness, and hit ratio

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

The 'Shared Zones' tab in the NGINX Plus live activity monitoring dashboard provides information about memory usage across all shared memory zones

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

The 'Cluster' tab in the NGINX Plus live activity monitoring dashboard provides synchronization information of shared memory zones of NGINX cluster nodes

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

The 'Resolvers' tab in the NGINX Plus live activity monitoring dashboard provides information about cache readiness, fullness, and hit ratio

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

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

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

In editing mode on the 'Upstreams' tab in the NGINX Plus live activity monitoring dashboard, you can add, remove, or modify servers

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

The 'Add server' interface for adding servers to an upstream group in the NGINX Plus live activity monitoring dashboard

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

The 'Edit selected' interface for modifying or removing servers in an upstream group in the NGINX Plus live activity monitoring dashboard

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

1.9.配置仪表板选项

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

The 'Dashboard configuration' interface for modifying Dashboard settings

  • 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

  • 如果你已为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/

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和上游服务器之间的不同时间值，如果你的网站运行缓慢，这可能有助于诊断问题。 你可以使用以下变量来记录指示的时间值：

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

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 <other configure arguments>

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 <nginx PID obtained at the previous step>

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

set $log = ngx_cycle->log
while $log->writer != ngx_log_memory_writer
    set $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 <nginx_executable_path> <coredump_file_path>

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 <nginx PID obtained at the previous step>

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.获得的回溯。 请参阅启用核心转储，获取回溯

琴 韵
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Nginx监控
Bertram的博客
10-24 1690
nginx监控
nginx+ffmpeg+nginx-http-flv-module+html资源包
05-11
在本资源包中，提供的`nginx-1.20.2.tar.gz`是Nginx的源码包，版本为1.20.2。安装时，通常需要编译源码，执行`./configure`、`make`和`make install`等步骤。 2. **FFmpeg**: FFmpeg是一套强大的多媒体处理工具，...
Nginx服务状态的监控
weixin_33906657的博客
12-17 226
一、安装Nginx 使用源码编译安装，包括具体的编译参数信息。 正式开始前，编译环境gcc g++ 开发库之类的需要提前装好。 安装make： yum -y install gcc automake autoconf libtool make 安装g++: yum install gcc gcc-c++ 一般我们都需要先装pcre, zlib，前者为了重写rewrite，后者为了gz...
【prometheus】监控nginx并实现可视化
最新发布
康师傅没有眼泪
04-30 3269
prometheus 监控nginx有两种方式。 一种是通过nginx_exporter监控，需要开启nginx_stub_status，主要是nginx自身的status信息，metrics数据现对较少； 另外一种使用nginx-vts-exporter监控，但是需要在编译nginx的时候添加nginx-module-vts模块，监控数据较多，提供了包含server、upstream以及cache的相关监控指标，指标更丰富，所以如下采用nginx-vts-exporter实现对nginx的监控。
如何从命令行实时监控Nginx Web服务器
三口酥屋
04-25 1723
一旦Nginx Web服务器在生产环境下搭建并运行起来，你就希望能够实时监测其活动。实际上，普通的网络监控软件都可以提供支持实时监控Nginx的功能，比如Nagios、Zabbix和Munin。 不过，如果你不需要这类工具所提供的综合报告功能或长期统计数字，只想快速、简便地监控对Nginx Web服务器提出的请求，那么我会建议使用一款名为ngxtop的命令行工具。 你一眼就会发现，无论
linux的nginx命令行,Ngxtop：在命令行实时监控 Nginx 的神器
weixin_33521678的博客
04-29 173
Nginx网站服务器在生产环境中运行的时候需要进行实时监控。实际上，诸如Nagios, Zabbix, Munin 的网络监控软件是支持 Nginx 监控的。如果你不需要以上软件提供的综合性报告或者长期数据统计功能，只是需要一种快速简便的办法去监控 Nginx 服务器的请求的话，我建议你采用一个叫ngxtop的命令行工具。你马上就会发现 ngxtop 从界面和名称都借鉴了著名的top命令。ng...
linux监控nginx服务器,一个小工具帮你搞定实时监控Nginx服务器
weixin_39611070的博客
05-09 70
ngxtop是一个基于python的程序，可以在Python上安装。ngxtop通过实时解析nginx访问日志，并将结果(nginx服务器的有用指标)输出到终端。主要的功能当前有效请求总请求计数摘要按状态代码提供的总请求数(2xx，3xx，4xx，5xx)发送平均字节顶级远程地址不仅能实时监控Nginx日志的访问还可以对以前的日志进行排查整理。在Linux上安装ngxtop以下操作是在CentOS...
nginx + nginx-http-flv-module-1.2.9
07-06
6. **运行与监控** 在 `logs` 目录下，Nginx 的日志文件记录了服务器的运行状态和错误信息，这对于诊断问题和优化性能至关重要。`nginx` 和 `nginx.pid` 可能是用于启动和停止 Nginx 服务的脚本和进程 ID 文件。 7...
win环境使用nginx的nginx-http-flv-module.zip
08-24
在windows 7 64位 环境下使用nginx的nginx-http-flv-module搭建flv视频流播放所有的安装包，参考：https://blog.csdn.net/qq_33071429/article/details/102628008
nginx-1.21.1_nginx-http-flv-module
06-23
windows版，2021年6月23日编译，已编译nginx-http-flv-module直播推流模块
nginx/1.21.6 &nginx-http-flv-module-1.2.10
04-14
标题 "nginx/1.21.6 & nginx-http-flv-module-1.2.10" 暗示了我们正在讨论的是一个基于Nginx的Web服务器配置，特别是针对流媒体服务。Nginx是一个高性能、轻量级的HTTP和反向代理服务器，广泛应用于互联网上。这里...
简介使用Nginx Plus的在线活动监控功能的方法
09-30
主要介绍了简介使用Nginx Plus的在线活动监控功能的方法,注意其目前暂时为收费项目,需要的朋友可以参考下
nginx-plus-dashboard
05-15
NGINX Plus仪表板 NGINX Plus的实时活动监视工具。 构建过程： 确保已安装所有依赖项： yarn install 要构建仪表板运行，请执行以下操作： yarn build 结果将放置在dist/dashboard.html 。 测试： 为了不使测试与源混合在一起，所有测试文件都应放置在项目中相关的__test__文件夹中。 yarn test 运行以上命令将启动业力服务器并构建覆盖率报告。 测试报告： http://0.0.0.0:9876/ –将运行测试的业力服务器的起始页 http://0.0.0.0:9876/debug.html –所有测试及其状态 覆盖率报告： 在项目文件夹中，检查coverage目录– index.html包含您需要的所有内容。 有用的链接： 第三方模块： – 7.2.6 – 6.26.3 – 7.1.5 –
Linux中使用ngxtop实现Nginx的实时网站监控
zhaghailiangji的博客
02-27 427
场景Linux的优化不是盲目的，而要对症下药，经常看到站长群里有人在问，为什么和你们用的是一样的oneinstack一键包，我的速度还这么慢呢？用的可是阿里云！我都会这样回答，优化分析不够彻底！盲目优化！今天小残说下对Nginx的实时监控！如哪些请求最频繁、哪些IP访问次数多.例如服务器出现带宽持续很高，就需要看下现在哪些请求的流量大。ngxtopngxtop就是用来满足这些实时监控需求的，是个非...
实时监控Nginx日志文件：ngxtop详解
网络技术联盟站
01-15 1409
ngxtop允许用户根据需求定制输出格式，以便更好地满足特定的分析需求。通过使用选项，您可以选择在ngxtop的输出中包含哪些字段。# 例：只显示IP地址和响应时间 ngxtop --output-fields = "IP,Response time"这种定制功能使得ngxtop适用于各种不同的分析场景，确保您只看到关注的信息。# 自定义输出格式，只显示IP地址、状态码和请求路径 ngxtop --output-fields = "IP,status,request_path"
nginx状态页面监控
tian的博客
10-13 771
nginx状态页面监控
nginx配置和监控nginx状态页面
m0_65079526的博客
10-22 1637
nginx的安装配置，功能的详细介绍、监控nginx状态页面
Nginx 命令
LP的博客
08-14 753
nginx -s reopen #重启Nginx nginx -s reload #重新加载Nginx配置文件，然后以优雅的方式重启Nginx nginx -s stop #强制停止Nginx服务 nginx -s quit #优雅地停止Nginx服务（即处理完所有请求后再停止服务） nginx -t #检测配置文件是否有语法错误，然后退出 nginx -?,-h #打开帮助信息 nginx -v #显示版本信息并退出 nginx -V #显示版本和配置选项信息，然后退出 nginx...
nginx-1.7.11.3-gryphon 与nginx有什么区别
12-02
nginx-1.7.11.3-gryphon 与nginx其实是同一个软件的不同版本。nginx是一个开源的高性能的web服务器和反向代理服务器，常用于构建高性能的网站。而nginx-1.7.11.3-gryphon是nginx的一个特定版本号，通常这些版本号中...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

琴 韵

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值