开源日志聚合系统盘点(2)——收集NGINX日志发送到ClickHouse

目标

收集、处理各服务器 NGINX 日志,发送到 ClickHouse,并在 Grafana 仪表盘的帮助下,将日志可视化,便于分析。

架构

ClickHouse 提供了 HTTP API 接口,这使得“保存到数据库”这一步相对简单。官方建议[1]每次写入不少于1000行的批量写入,或每秒不超过一个写入请求。

收集和处理可以使用老牌的 Logstash(或 gohangout)+ Filebeat(可选),Logstash 拥有 200 多个插件,有些输出插件可能并非原生实现的。Logstash 较为全面,还能覆盖到个别冷门的需求,比如输出到 IRC 等。Logstash 的劣势在于它的性能以及资源消耗较高。

这里有一个“all in one”的解决方案 —— Vector,它有 14 Sources、26 Transforms 和 32 Sinks,基本上能覆盖绝大多数场景和需求。与 Logstash 相比,Vector 具有高性能和低内存消耗的特点;更轻量的收集和处理方案可以采用 nginx-clickhouse 或 nginx-log-collector。如下图所示:

    .--------------------.     .--------------------.
    |  nginx-clickhouse  |     |                    |
    |   ||  vector  ||   |---->|     Clickhouse     |
    | nginx-log-collector|     |                    |
    '--------------------'     '--------------------'
                                         ^
                                         |
                                         v
                               .--------------------.
                               |                    |
                               |      Grafana       |
                               |                    |
                               '--------------------'

在采用 Vector 的方案中,可增加 Kafka 作为缓冲。

方案配置

1)nginx-clickhouse + ClickHouse + Grafana

2)Nginx-log-collector + ClickHouse + Grafana

3)Vector + ClickHouse + Grafana

  • Vector:Vector,用于收集、转换和发送日志数据、度量和事件。流程:sources → transforms → sinks。
    https://github.com/timberio/vector
  • ClickHouse:数据库。Schema:可参考方案 2)
  • Grafana:可视化仪表盘。dashboard:参考方案 2)

方案实施

在方案 1、2 中,日志数据的处理和转换在程序内已完成,按照操作指引实施就ok,方案较为完整。

方案3 采用的 Vector 覆盖面很广,但在具体的整合方案实施方面(比如某 source + 某 transform + 某 sink 如何配置?)不够深入,缺少清晰地指引。建议官方给出几个典型应用场景的完整配置示例,个人认为,这比增加 source、tansform 上的数字更为重要。

注解

[1]:https://clickhouse.tech/docs/zh/introduction/performance/

喜歡:
0
去到頂部