面向 NGINX 和 NGINX Plus 的 OpenTracing
原文作者:Mohamed Gougam of F5
原文链接:面向 NGINX 和 NGINX Plus 的 OpenTracing
转载来源:NGINX 开源社区
NGINX 唯一中文官方社区 ,尽在 nginx.org.cn
尽管微服务架构有诸多优势,但它也带来了新的挑战。其中一个挑战是在处理请求时对其进行追踪,因为请求数据在组成应用的所有微服务之间流动。为此,一种被称为分布式(请求)追踪的新方法用来解决这一挑战, OpenTracing 供一组规范和标准的 API,旨在指导分布式追踪工具的设计和实施。
在 NGINX Plus Release 18 (R18) 中,NGINX 官方将 NGINX OpenTracing 模块添加到 NGINX Plus 动态模块库中(它已经作为第三方模块被使用了数年)。NGINX OpenTracing 模块的一大优势是,通过对 NGINX 和 NGINX Plus 进行分布式追踪,您可以获得每个代理应用的追踪数据,而无需单独对应用进行追踪。
在这篇博客中,我们将展示如何为 NGINX 或 NGINX Plus 启用分布式请求追踪(为简洁起见,我们从现在起只提及 NGINX Plus)。我们将讨论两个分布式追踪服务(在 OpenTracing 术语中为“追踪器 [tracer]”) — Jaeger 和 Zipkin。(关于其他追踪器的列表,请见 OpenTracing 文档)。为了说明追踪器提供的信息类型,我们比较了启用 NGINX Plus 缓存前后的请求处理。
追踪器有两个基本组件:
-
一个是代理,用于从运行应用的主机上收集跟踪数据。在我们的示例中,“应用”是 NGINX Plus,代理作为插件
-
一个是服务器(也称为“收集器”),它接受来自一个或多个代理的追踪数据,并在一个集中的用户界面上显示。您可以选择在 NGINX Plus 主机或其他主机上运行服务器。
安装追踪器服务器
第一步是根据您选择的追踪器在服务器上进行安装和配置服。我们现在为 Jaeger 和 Zipkin 提供说明;对其他追踪器则根据需要进行调整。
安装 Jaeger 服务器
1. 我们建议使用以下方法安装 Jaeger 服务器。您也可以在步骤 1 中指定的 URL 下载 Docker 镜像。
导航到 Jaeger 下载页面并下载 Linux 二进制文件(在编写本文时,jaeger-1.12.0-linux-amd64.tar)。
2. 解压二进制文件运行,或将二进制文件移到 /usr/bin 目录,然后运行。
$ mkdir /usr/bin/jaeger $ mv jaeger-1.12.0-linux-amd64.tar /usr/bin/jaeger $ cd /usr/bin/jaeger $ tar xvzf jaeger-1.12.0-linux-amd64.tar.gz $ sudo rm -rf jaeger-1.12.0-linux-amd64.tar.gz $ cd jaeger-1.12.0-linux-amd64 $ ./jaeger-all-in-one
3. 验证您能否在浏览器中访问 Jaeger UI,访问地址为 http://Jaeger-server-IP-address:16686/(16686 是 Jaeger 服务器的默认端口)。
安装和配置追踪器插件
在 NGINX Plus 主机上运行这些命令,为 Jaeger 或 Zipkin 安装插件。
安装 Jaeger 插件
1. 安装 Jaeger 插件。以下 wget 命令适用于 x86‑64 Linux 系统:
$ cd /usr/local/lib $ wget https://github.com/jaegertracing/jaeger-client-cpp/releases/download/v0.4.2/libjaegertracing_plugin.linux_amd64.so -O /usr/local/lib/libjaegertracing_plugin.so
GitHub 上提供了从源代码构建插件的说明。
2. 为插件创建一个 JSON 格式的配置文件,命名为 /etc/jaeger/jaeger-config.json,内容如下。我们使用 Jaeger 服务器的默认端口 6831:
{ "service_name": "nginx", "sampler": { "type": "const", "param": 1 }, "reporter": { "localAgentHostPort": "Jaeger-server-IP-address:6831" } }
有关采样器对象的详细信息,请参见 Jaeger 文档。
安装 Zipkin 插件
1. 安装 Zipkin 插件。以下 wget
命令适用于 x86‑64 Linux 系统:
$ cd /usr/local/lib $ wget -O - https://github.com/rnburn/zipkin-cpp-opentracing/releases/download/v0.5.2/linux-amd64-libzipkin_opentracing_plugin.so.gz | gunzip -c > /usr/local/lib/libzipkin_opentracing_plugin.so
2. 为插件创建一个 JSON 格式的配置文件,命名为 /etc/zipkin/zipkin-config.json,内容如下。我们使用 Zipkin 服务器的默认端口 9411:
{ "service_name": "nginx", "collector_host": "Zipkin-server-IP-address", "collector_port": 9411 }
有关配置对象的详细信息,请参阅 GitHub 上的 JSON 模式。
配置 NGINX Plus
在 NGINX Plus 主机上执行以下操作步骤。
1. 根据 NGINX Plus 管理指南中的说明安装 NGINX OpenTracing 模块。
2. 在主 NGINX Plus 配置文件 (/etc/nginx/nginx.conf) 的主(顶层)上下文中添加以下 load_module 指令:
load_module modules/ngx_http_opentracing_module.so;
3. 将以下指令添加到 NGINX Plus 配置中。
如果您使用传统的配置方案,请将指令放在一个名为 /etc/nginx/conf.d/opentracing.conf 的新文件中。同时验证以下 include 指令已经出现在 /etc/nginx/nginx.conf 的 http
上下文中:
http { include /etc/nginx/conf.d/*.conf; }
-
opentracing_load_tracer
指令启用追踪器插件。根据需要取消 Jaeger 或 Zipkin 的指令注释。 -
Opentracing_tag
指令将 NGINX Plus 变量作为 opentracing 标记显示在追踪器 UI 中。 -
要调试 OpenTracing 活动,请取消 log_format 和 access_log 指令的注释。如果要将默认的 NGINX 访问日志和日志格式替换为此格式,请取消注释这些指令,然后将 “
opentracing
” 的三个实例更改为 “main
” 。另一个选项是仅针对 9001 端口上的流量记录 OpenTracing 活动 — 取消log_format
和access_log
指令的注释,并将它们移动到服务器块中。
# Load a vendor tracer #opentracing_load_tracer /usr/local/libjaegertracing_plugin.so # /etc/jaeger/jaeger-config.json; #opentracing_load_tracer /usr/local/lib/libzipkin_opentracing_plugin.so # /etc/zipkin/zipkin-config.json; # Enable tracing for all requests opentracing on; # Set additional tags that capture the value of NGINX Plus variables opentracing_tag bytes_sent $bytes_sent; opentracing_tag http_user_agent $http_user_agent; opentracing_tag request_time $request_time; opentracing_tag upstream_addr $upstream_addr; opentracing_tag upstream_bytes_received $upstream_bytes_received; opentracing_tag upstream_cache_status $upstream_cache_status; opentracing_tag upstream_connect_time $upstream_connect_time; opentracing_tag upstream_header_time $upstream_header_time; opentracing_tag upstream_queue_time $upstream_queue_time; opentracing_tag upstream_response_time $upstream_response_time; #uncomment for debugging # log_format opentracing '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for" ' # '"$host" sn="$server_name" ' # 'rt=$request_time ' # 'ua="$upstream_addr" us="$upstream_status" ' # 'ut="$upstream_response_time" ul="$upstream_response_length" ' # 'cs=$upstream_cache_status'; #access_log /var/log/nginx/opentracing.log opentracing; server { listen 9001; location / { # The operation name used for OpenTracing Spans defaults to the name of the # 'location' block, but uncomment this directive to customize it. #opentracing_operation_name $uri; # Propagate the active Span context upstream, so that the trace can be # continued by the backend. opentracing_propagate_context; # Make sure that your Ruby app is listening on port 4567 proxy_pass http://127.0.0.1:4567; } }
4. 验证并重新加载 NGINX Plus 配置:
$ nginx -t $ nginx -s reload
设置 Ruby 示例应用
完成追踪器和 NGINX Plus 配置后,我们就创建了一个 Ruby 示例应用,可用来做 OpenTracing 数据展示。该应用可以让我们测量 NGINX Plus 缓存在多大程度上改善了响应时间。当应用收到请求时,比如下面对根路径/的 HTTP GET
请求,它会随机等待一段时间(2 到 5 秒之间),然后做出响应。
$ curl http://NGINX-Plus-IP-address:9001/
1. 安装和设置 Ruby 和 Sinatra(一种开源软件 web 应用框架和用 Ruby 编写的特定领域语言,可以替代其他 Ruby web 应用框架)。
2. 创建一个名为 app.rb 的文件,内容如下:
#!/usr/bin/ruby require 'sinatra' get '/*' do out = "<h1>Ruby simple app</h1>" + "\n" #Sleep a random time between 2s and 5s sleeping_time = rand(4)+2 sleep(sleeping_time) puts "slept for: #{sleeping_time}s." out += '<p>some output text</p>' + "\n" return out end
3. 对 app.rb 文件添加可执行权限并运行:
$ chmod +x app.rb $ ./app.rb
无缓存追踪响应时间
本部分使用 Jaeger 和 Zipkin 来显示未启用缓存时,NGINX Plus 响应请求所需的时间。对于每个追踪器,我们发送五个请求。
Jaeger 无缓存输出
以下是 Jaeger UI 中显示的五个请求(最近的排第一):
以下是 Ruby 应用控制台上的相同信息:
- -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:50:46 +0000] "GET / HTTP/1.1" 200 49 3.0028 127.0.0.1 - - [07/Jun/2019: 10:50:43 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 2s. 127.0.0.1 - - [07/Jun/2019: 10:50:56 +0000] "GET / HTTP/1.1" 200 49 2.0018 127.0.0.1 - - [07/Jun/2019: 10:50:54 UTC] "GET / HTTP/1.0"1 200 49 - -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:53:16 +0000] "GET / HTTP/1.1" 200 49 3.0029 127.0.0.1 - - [07/Jun/2019: 10:53:13 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 4s. 127.0.0.1 - - [07/Jun/2019: 10:54:03 +0000] "GET / HTTP/1.1" 200 49 4.0030 127.0.0.1 - - [07/Jun/2019: 10:53:59 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:54:11 +0000] "GET / HTTP/1.1" 200 49 3.0012 127.0.0.1 - - [07/Jun/2019: 10:54:08 UTC] "GET / HTTP/1.0" 200 49
在 Jaeger UI 中,我们点击第一个(最近的)请求来查看其详细信息,包括我们作为标签添加的 NGINX Plus 变量的值:
Zipkin 无缓存输出
以下是 Zipkin UI 中的五个请求:
Ruby 应用控制台中的相同信息:
- -> / slept for: 2s. 127.0.0.1 - - [07/Jun/2019: 10:31:18 +0000] "GET / HTTP/1.1" 200 49 2.0021 127.0.0.1 - - [07/Jun/2019: 10:31:16 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:31:50 +0000] "GET / HTTP/1.1" 200 49 3.0029 127.0.0.1 - - [07/Jun/2019: 10:31:47 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:32:08 +0000] "GET / HTTP/1.1" 200 49 3.0026 127.0.0.1 - - [07/Jun/2019: 10:32:05 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 3s. 127.0.0.1 - - [07/Jun/2019: 10:32:32 +0000] "GET / HTTP/1.1" 200 49 3.0015 127.0.0.1 - - [07/Jun/2019: 10:32:29 UTC] "GET / HTTP/1.0" 200 49 - -> / slept for: 5s. 127.0.0.1 - - [07/Jun/2019: 10:32:52 +0000] "GET / HTTP/1.1" 200 49 5.0030 127.0.0.1 - - [07/Jun/2019: 10:32:47 UTC] "GET / HTTP/1.0" 200 49
在 Zipkin UI 中,我们点击第一个请求来查看其详细信息,包括我们作为标签添加的 NGINX Plus 变量的值:
使用缓存追踪响应时间
配置 NGINX Plus 缓存
本部分通过在“配置 NGINX Plus” 部分创建的 opentracing.conf 文件中添加指令来启用缓存。
1. 在 http
上下文中,添加此 proxy_cache_path 指令:
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
2. 在服务器块中,添加以下 proxy_cache 和 proxy_cache_valid 指令:
proxy_cache one; proxy_cache_valid any 1m;
3. 验证并重新加载配置:
$ nginx -t $ nginx -s reload
带缓存的 Jaeger 输出
这是两个请求后的 Jaeger UI。
第一次响应(标记为 13f69db)耗时 4 秒。NGINX Plus 缓存了响应,当请求在大约 15 秒后重复时,响应花费了不到 2 毫秒 (ms) ,因为它来自 NGINX Plus 缓存。
详细查看这两个请求可以解释响应时间的差异。对于第一个请求,upstream_cache_status
是 MISS
,意味着请求的数据不在缓存中。Ruby 应用增加了 4 秒的延迟。
对于第二个请求,upstream_cache_status
是 HIT
。因为数据来自于缓存,Ruby 应用无法添加延迟,响应时间低于 2 毫秒。空的 upstream_*
值也表示上游服务器没有参与此响应。
带缓存的 Zipkin 输出
启用缓存的两个请求在 Zipkin UI 中呈现出类似的结果:
详细查看这两个请求可以解释响应时间的差异。第一个请求没有缓存响应(upstream_cache_status
为 MISS
),Ruby 应用(巧合)添加了与 Jaeger 示例相同的 4 秒延迟。
在我们发出第二个请求之前,响应已经被缓存,因此 upstream_cache_status
是 HIT
。
结语
NGINX OpenTracing 模块支持对 NGINX Plus 请求和响应的追踪,并使用 OpenTracing 标记提供对 NGINX Plus 变量的访问。此模块还可以使用不同的追踪器。
关于 NGINX OpenTracing 模块的更多详细信息,请访问 GitHub 上的 NGINX OpenTracing 模块存储库。
如欲试用 OpenTracing with NGINX Plus,请立即下载 30 天免费试用版,或与我们联系以讨论您的用例。
NGINX 唯一中文官方社区 ,尽在 nginx.org.cn
更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源: 开源社区官网 | 微信公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
GaussDB SQL调优:选择合适的分布列
一、背景 GaussDB是华为公司倾力打造的自研企业级分布式关系型数据库,该产品具备企业级复杂事务混合负载能力,同时支持优异的分布式事务,同城跨AZ部署,数据0丢失,支持1000+扩展能力,PB级海量存储等企业级数据库特性。 二、将会学到什么 在这个Codelabs中,您将体验GaussDB通过选择合适的分布列来达到性能调优的实际案例。 三、SQL调优指南 SQL调优的唯一目的是“资源利用最大化”,即CPU、内存、磁盘IO、网络IO四种资源利用最大化。所有调优手段都是围绕资源使用开展的。所谓资源利用最大化是指SQL语句尽量高效,节省资源开销,以最小的代价实现最大的效益。比如做典型点查询的时候,可以用seqscan+filter(即读取每一条元组和点查询条件进行匹配)实现,也可以通过indexscan实现,显然indexscan可以以更小的代价实现相同的效果。 1、选择合适的分布列 a.现象描述 表定义如下: CREATE TABLE t1 (a int, b int); CREATE TABLE t2 (a int, b int); 执行如下查询: SELECT * FROM t1,...
- 下一篇
从“执行SQL”到“返回结果”,数据库到底发生了什么?
SQL全称是 StructuredQueryLanguage结构化查询语言。由于其简单易学、完整安全、灵活且具备高可扩展性,SQL如今已经成为标准的关系型数据库管理语言。 当连接到数据库,写下一条 SQL 语句,点击“执行”, SELECTname,companyFROMproductWHEREid=12345; 就会获得结果: name |company ------------+--------- PieCloudDB|OpenPie (1row) 你是否好奇,从点击“执行”到看到结果的这段时间里,到底发生了哪些神奇的事情呢? 首先,用来连接数据库、编写 SQL 的工具是数据库的客户端软件(又称 Client),当我们编写完 SQL 并点击“执行”后,SQL 语句就从客户端传到了数据库服务器端(又称 Server)。数据库服务器收到 SQL 语句之后,就会开始它的表演。 SQL 语句的执行一般经过三个步骤:解析、优化、执行,而数据库里进行这三项操作的功能模块称为:解析器、优化器、执行器。分别负责对 SQL 语句进行词法和语法分析、进行查询优化和执行 SQL 语句。 ...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS7,CentOS8安装Elasticsearch6.8.6
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- CentOS8编译安装MySQL8.0.19
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker安装Oracle12C,快速搭建Oracle学习环境
- 设置Eclipse缩进为4个空格,增强代码规范