实现clickhouse-logger自定义请求头存储

本文介绍了如何在apisix中使用clickhouse-logger插件,通过注册自定义变量存储请求的x_customer_type头和路由的customerType标签,同时配置log_format以匹配数据库表结构。

实现clickhouse-logger自定义请求头存储

需求描述

公司需要实现全链路日志采集功能,调研发现apisix的clickhouse-logger插件,但是我们的请求会有一些自定义的请求头以及对应路由的区分。因此考虑到基于clickhouse-logger结合apisix的注册自定义变量功能来实现。

因此我们调研下来通过注册一个叫做 route_label_customer_type 的变量来获取路由中 customerType 标签的值来做clickhouse中的记录区分。也可以将请求中自定义的header值存储到clickhouse中。

实现

首先在apisix的clickhouse-logger.lua中追加如下代码:

-- 获取request中的自定义header
core.ctx.register_var("x_customer_type", function(ctx)
	local type = core.request.header(ctx, "x_customer_type")
    if type then
        return type
    end
    return nil
end)

-- 注册一个叫做 route_label_customer_type 的变量来获取路由中 customerType 标签的值。
core.ctx.register_var("route_label_customer_type", function(ctx)
    local route = ctx.matched_route and ctx.matched_route.value
    if route and route.labels then
        return route.labels.customerType
    end
    return nil
end)

设置路由标签

  "labels": {
    "customerType": "测试接口"
  }

通过proxy-rewrite插件追加自定义请求header

    "proxy-rewrite": {
      "headers": {
        "x_customer_type": "开启计费模式"
      }
    }​

然后配置 log_format 元数据参数。log_format 的格式必须与数据库表的结构保持一致,否则会导致写入失败。

 curl http://127.0.0.1:9080/apisix/admin/plugin_metadata/clickhouse-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "upstream_header_time": "$upstream_header_time",
        "upstream_connect_time": "$upstream_connect_time",
        "status": "$status",
        "host": "$host",
        "body_bytes_sent": "$body_bytes_sent",
        "request": "$request",
        "remote_user": "$remote_user",
        "client_ip": "$remote_addr",
        "content_length": "$content_length",
        "local_time": "$fmt_ms_time_local",
        "http_referer": "$http_referer",
        "http_x_amz_target": "$http_x_amz_target",
        "http_x_request_id": "$http_x_request_id",
        "upstream_response_time": "$upstream_response_time",
        "upstream_status": "$upstream_status",
        "http_user_agent": "$http_user_agent",
        "request_time": "$request_time",
        "upstream_addr": "$upstream_addr",
        "http_host": "$http_host",
        "content_type": "$content_type",
        "route_id": "$route_id",
        "route_name": "$route_name",
        "consumer_name": "$consumer_name",
        "arg": "$args",
        "request_body": "$request_body",
        "req_timestamp": "$time_iso8601",
        "request_uri": "$request_uri",
        "x_customer_type": "$x_customer_type",
        "route_label_customer_type": "$route_label_customer_type"
    }
}'

创建 ClickHouse 写入的表格

CREATE TABLE default.record (
  `upstream_header_time` Float64,
  `upstream_connect_time` Float64,
  `status` Int16,
  `host` String,
  `body_bytes_sent` String,
  `request` String,
  `remote_user` String,
  `client_ip` String,
  `content_length` Int32,
  `local_time` String,
  `http_referer` String,
  `http_x_amz_target` String,
  `http_x_request_id` String,
  `upstream_response_time` Float64,
  `upstream_status` String,
  `http_user_agent` String,
  `request_time` Float64,
  `upstream_addr` String,
  `http_host` String,
  `content_type` String,
  `route_id` String,
  `route_name` String,
  `consumer_name` String,
  `req_timestamp` String,
  `arg` String,
  `request_body` String,
  `request_uri` String,
  `x_customer_type` String,
  `route_label_customer_type` String,
  PRIMARY KEY(`http_x_request_id`)
) ENGINE = MergeTree()

在 ClickHouse 上执行 select * from default.record;,将得到类似下面的数据。

┌─host──────┬─client_ip─┬─route_id─┬─route_label_customer_type───┐─x_customer_type────┐
│ 127.0.0.1 │ 127.0.0.1 │    1     │ 测试接口                     │开启计费模式         │
└───────────┴───────────┴──────────┴─────────────────────────────┘────────────────────┘
<think>好的,我现在需要解决ClickHouse启动时无论成功还是失败都重复打印配置文件处理日志的问题。首先,我需要了解ClickHouse的日志机制。ClickHouse使用内置的日志系统,通常配置在config.xml或者users.xml中。用户提到的重复打印配置文件处理日志,可能和日志级别设置有关,或者是某些组件在启动时多次尝试加载配置文件导致的。 接下来,我需要查阅相关资料。根据引用[1]中的内容,ForceExecutionResult属性用于测试任务或容器的执行结果,可能影响执行流程。但这里的问题是关于日志重复打印,可能与执行流程无关,但可能需要检查是否有任务被重复执行导致日志多次输出。例如,某个配置加载任务被多次触发,导致日志重复记录。 另外,引用[2]提到不要修改内容更新构建的设置,否则内容状态文件的数据会失效。虽然这可能与日志问题无直接关联,但需要确保在调整配置时不会影响其他功能,比如避免修改与日志无关的重要设置。 接下来,可能的解决步骤包括: 1. **检查日志级别**:查看config.xml中的日志级别设置,如<level>trace</level>是否被设置得过低,导致输出过多信息。调整为更高的级别如information或warning可能减少冗余日志。 2. **审查配置文件加载流程**:ClickHouse在启动时会处理多个配置文件,包括主配置和附加配置文件。检查是否有重复的配置项或多余的配置文件被加载,导致日志重复记录。 3. **查找已知问题或补丁**:查看ClickHouse的GitHub仓库或社区讨论,确认是否有类似问题已被报告并修复。可能需要升级到特定版本。 4. **自定义日志配置**:在config.xml中调整日志输出,通过修改或添加logger配置,限制特定模块的日志输出,比如与配置文件处理相关的模块。 例如,检查config.xml中的以下部分: ```xml <logger> <level>information</level> <log>/var/log/clickhouse-server/clickhouse-server.log</log> <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog> </logger> ``` 如果日志级别是trace,改为information可能会减少日志量。 此外,某些配置可能需要通过命令行参数覆盖,比如使用--log-level参数启动服务,但需确认ClickHouse是否支持此参数。 可能的错误点:误调整与日志无关的配置,导致服务无法启动,需谨慎修改并备份原文件。 最后,测试修改后的配置,重启ClickHouse服务,观察日志输出是否改善。如果问题依旧,可能需要深入分析日志内容,查看是否有异常错误导致配置文件被重复处理。</think>针对ClickHouse启动时重复打印配置文件处理日志的问题,可按照以下步骤排查和解决: --- ### **步骤1:检查日志级别配置** 1. 打开ClickHouse的主配置文件`config.xml`,路径通常为`/etc/clickhouse-server/config.xml`。 2. 定位到`<logger>`标签,检查日志级别是否设置为`trace`: ```xml <logger> <level>trace</level> <!-- 若为trace,改为information或warning --> <log>/var/log/clickhouse-server/clickhouse-server.log</log> </logger> ``` 3. 修改后重启服务: ```bash systemctl restart clickhouse-server ``` --- ### **步骤2:检查配置文件加载逻辑** 1. ClickHouse会加载`/etc/clickhouse-server/config.d/`和`/etc/clickhouse-server/conf.d/`目录下的附加配置。确认这些目录中是否存在重复或冲突的配置文件。 2. 检查主配置文件是否包含重复的`<include>`指令: ```xml <include_from>/etc/clickhouse-server/config.d/</include_from> <include_from>/etc/clickhouse-server/conf.d/</include_from> ``` 若有重复包含,需删除冗余条目。 --- ### **步骤3:检查版本已知问题** 1. 访问[ClickHouse GitHub Issues](https://github.com/ClickHouse/ClickHouse/issues),搜索关键词如`duplicate config logs`,确认是否存在版本相关Bug。 2. 若问题由版本缺陷导致,升级到最新稳定版: ```bash apt-get update && apt-get install clickhouse-server ``` --- ### **步骤4:自定义日志过滤器(可选)** 在`config.xml`中为特定模块(如配置文件加载模块)设置更严格的日志级别: ```xml <logger> <level>information</level> <filters> <filter> <name>ConfigProcessor</name> <!-- 假设模块名称为ConfigProcessor --> <level>warning</level> </filter> </filters> </logger> ``` --- ### **验证结果** 重启服务后检查日志: ```bash tail -f /var/log/clickhouse-server/clickhouse-server.log ``` 若仍有重复日志,需结合日志时间戳和上下文分析具体原因[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值