kong 插件应用(一)
插件优先顺序
插件将始终运行一次,并且每个请求只能运行一次。但是它将运行的配置取决于为其配置的实体。
可以为各种实体,实体组合甚至全局配置插件。这很有用,例如,当您希望以某种方式为大多数请求配置插件,但使经过身份验证的请求的行为略有不同时。
因此,将插件应用于具有不同配置的不同实体时,存在运行该插件的优先顺序。其规则是:插件关于配置了多少个实体越具体,其优先级越高。
多次配置插件后,完整的优先级顺序为: (1优先级最高,8优先级最低)
- 在以下各项的组合上配置的插件:
Route
,Service
和Consumer
。(Consumer
意味着必须对请求进行身份验证)。 - 在
Route
和Consumer
的组合上配置的插件。(Consumer
意味着必须对请求进行身份验证)。 - 在
Service
和Consumer
的组合上配置的插件。(Consumer
意味着必须对请求进行身份验证)。 - 在
Route
和Service
的组合上配置的插件。 - 在
Consumer
配置的插件。(Consumer
意味着必须对请求进行身份验证)。 - 在
Route
上配置的插件。 - 在
Service
上配置的插件。 - 配置为全局运行的插件。
file-log
兼容的协议
该插件兼容以下协议:
http
https
grpc
grpcs
在Services
上启用
1 |
|
其中
{service}
是service
的id
或者name
在Routes
上启用
1 |
|
其中
{route}
是route
的id
或者name
在Consumers
上启用
1 |
|
其中
{consumer}
是consumer
的id
或者username
全局启用
1 |
|
参数
参数 | 解释 |
---|---|
name |
要使用的插件名称,本处为file-log |
service.id |
service 的id |
route.id |
route 的id |
consumer.id |
consumer 的id |
enabled 默认为true |
这个插件是否被应用 |
config.path |
日志存放的文件,该文件必须可以为kong 可写 |
config.reopen 默认false |
在Kong 0.10.2中引入。 确定是否在每次请求时关闭并重新打开日志文件。 如果文件没有重新打开,并且已被删除/旋转,则插件将继续写入陈旧的文件描述符,从而丢失信息。 (该处我没明白) |
日志格式
1 |
|
部分字段解释:
request
包含有关客户端发送的请求的属性response
包含有关发送给客户端的响应的属性tries
包含负载均衡器对此请求进行的(重试)(成功和失败)列表route
包含有关请求的特定路线的Kong属性service
包含与所请求路线相关的服务的Kong属性authenticated_entity
包含有关已认证凭据的Kong属性(如果已启用身份验证插件)workspaces
包含与所请求路线关联的工作区的Kong
属性。仅在Kong Enterprise版本> = 0.34中。consumer
包含经过身份验证的使用者(如果已启用身份验证插件)latencies
包含有关延迟的一些数据:proxy
是最终服务处理请求所花费的时间kong
是运行所有插件所需的内部Kong
延迟request
是从客户端读取第一个字节到将最后一个字节发送到客户端之间经过的时间。对于检测慢速客户端非常有用。
client_ip
包含原始客户端IP地址started_at
包含开始处理请求的时间的UTC时间戳。
注意事项
此日志记录插件将仅记录HTTP请求和响应数据。
zipkin
兼容的协议
该插件兼容以下协议:
http
https
grpc
grpcs
tcp
tls
在Service
上启用
1 |
|
其中
{service}
可以是service
的id
或者name
在Route
上启用
1 |
|
其中
{route}
可以是route
的id
或者name
在Consumer
上启用
1 |
|
其中
{consumer}
可以是consumer
的id
或者name
全局启用
1 |
|
参数详解
参数 | 解释 |
---|---|
name |
该处只为zipkin |
service.id |
Service 的id |
route.id |
Route 的id |
consumer.id |
Consumer 的id |
enabled 默认为true |
是否启用 |
config.http_endpoint |
kong 上报到zipkin 的完整http (https )地址 |
config.sample_ratio 默认为0.001 |
是否进行采样,0是不采样,1是完整采样 |
config.default_service_name |
zipkin 的服务名称设置。 |
config.include_credential 默认为true |
当前经过身份验证的消费者的凭据是否应该包含在发送到Zipkin服务器的元数据中 |
工作原理
当启用时,此插件以与zipkin兼容的方式跟踪请求。
代码是围绕opentrace核心构建的,使用opentrace -lua库来收集Kong每个阶段请求的定时数据。插件使用兼容opentrace -lua的提取器、注入器和报告器来实现Zipkin的协议。
提取器和注入器
一个开放式的“提取器”从传入的请求中收集信息。 如果传入请求中不存在任何跟踪ID,则根据sample_ratio配置值可能会生成一个跟踪ID。
开放式跟踪“注入器”将跟踪信息添加到外发请求中。 目前,仅由kong
代理请求注入者; 它尚未用于数据库请求或其他插件(例如http-log
插件)的请求。
此插件遵循Zipkin
的B3
规范,说明要使用的HTTP
标头。 此外,它还支持Jaegar
风格的uberctx-
标头,用于传播包。
上报
开放式跟踪“报告器”是将跟踪数据报告给另一个系统的方式。 该插件记录给定请求的跟踪数据,并使用Zipkin v2 API将其批量发送到Zipkin服务器。 请注意,需要zipkin 1.31或更高版本。
http_endpoint
配置变量必须包含完整的uri
,包括协议,主机,端口和路径部分(即uri
可能以/api/v2/spans
结尾)。
response-transformer
兼容协议
http
https
在 Service
上启用
1 |
|
{service}
可以是Service
的id
或者name
在 Route
上启用
1 |
|
{routes}
可以是Routes
的id
或者name
在 Consumers
上启用
1 |
|
{consumers}
可以是Consumers
的id
或者name
全局启用
1 |
|
参数详解
参数 | 解释 |
---|---|
name |
插件名称,此处为response-transformer |
service.id |
service 的id |
route.id |
route 的id |
consumer.id |
consumer 的id |
enabled 默认为true |
是否启用该插件 |
config.remove.headers |
需要取消的header 的名字列表 |
config.remove.json |
需要移除的json 的名字列表 |
config.rename.headers |
需要重命名header 的列表, 格式为:original_header_name: new_header_name ,如果original_header 存在,则重命名,否则忽略。这个是重命名header 的name |
config.replace.headers |
需要替换header 的列表,格式为header_name: header_value ,如果header_name 存在,则替换,不存在忽略。这个替换的是header 的value |
config.replace.json |
需要替换的json 列表,格式为:josn_key: josn_value , 如果json_key 存在,则将该josn_key 的value 替换成json_value ,不存在,忽略。 |
config.add.headers |
需要新增的header 的列表,格式为:header_name: header_value , 如果header_name 存在,忽略,不存在则新增。 |
config.add.json |
需要新增的json 的列表,格式为:json_name: json_value , 如果json_name 存在,则忽略,不存在则新增。 |
config.append.headers |
需要新增的header 的列表,格式为:header_name: header_value , 如果header_name 存在,替换,不存在则新增。 |
config.append.json |
需要新增的json 的列表,格式为:json_name: json_value , 如果json_name 存在,则替换,不存在则新增。 |
注意:如果
value
中包含,
,不能使用分割符,必须使用数组
执行顺序
插件按照以下顺序执行响应转换:
remove
–> rename
–> replace
–> add
–> append
示例
新增响应头
分别键值对方式
1 |
|
header
返回对比
upstream response headers | proxied response headers |
---|---|
h1: v1 | h1: v1 h2: v1 |
逗号分隔符方式
1 |
|
header
返回对比
upstream response headers | proxied response headers |
---|---|
h1: v1 | h1: v1 h2: v1 |
json
方式
1 |
|
header
返回对比
upstream response headers | proxied response headers |
---|---|
h1: v1 | h1: v1 h2: v1 |
添加body
属性和header
1 |
|
header
返回对比
upstream response headers | proxied response headers |
---|---|
h1: v2 | h1: v2 h2: v1 |
h3: v1 | h1: v1 h2: v1 h3: v1 |
body
返回对比
upstream response JSON body | proxied response body |
---|---|
{} | {“p1” : “v1”, “p2”: “v2”} |
{“p1” : “v2”} | {“p1” : “v2”, “p2”: “v2”} |
添加多个header
并删除body
1 |
|
header
返回对比
upstream response headers | proxied response headers |
---|---|
h1: v1 | h1: v1 h1: v2 h2: v1 |
body
返回对比
upstream response JSON body | proxied response body |
---|---|
{“p2”: “v2”} | {“p2”: “v2”} |
{“p1” : “v1”, “p2” : “v1”} | {“p2”: “v2”} |
Rate Limiting
支持协议
http
https
在Services
上启用
1 |
|
{service}
可以代表service
的id
或者name
在Route
上启用
1 |
|
{route}
可以代表route
的id
或者name
在Consumer
上启用
1 |
|
{consumers}
可以代表consumers
的id
或者name
全局启用
1 |
|