首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >使用 ClickHouse 处理离线半结构化日志

使用 ClickHouse 处理离线半结构化日志

作者头像
soulteary
发布于 2021-11-25 02:17:46
发布于 2021-11-25 02:17:46
91700
代码可运行
举报
运行总次数:0
代码可运行

在《快速上手 ClickHouse》一文中,我们介绍了 ClickHouse 的基础使用。本篇文章里,将介绍如何使用 Clickhouse 快速处理诸如 Nginx 运行日志等半结构化的离线数据,让这些静态数据能够被快速的查询分析。

写在前面

诸如 Nginx 等 Web 服务器、MySQL 等数据库,这类软件在日常运行过程中,都会生产非常多的运行数据,在不进行特别设置的情况下,我们将得到一些有一定格式的纯文本内容,我们一般称之为半结构化内容,比如这样:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
xxx.xxx.xxx.xxx - - [01/Jan/2021:00:02:03 +0000] "GET /feed HTTP/1.1" 301 169 "-" "Winds: Open Source RSS & Podcast app: https://getstream.io/winds/"
xxx.xxx.xxx.xxx - - [01/Jan/2021:00:02:34 +0000] "GET /feed/ HTTP/1.1" 304 0 "-" "Tiny Tiny RSS/20.08-5497a13 (http://tt-rss.org/)"
xxx.xxx.xxx.xxx - - [01/Jan/2021:00:02:54 +0000] "GET /feed/ HTTP/1.1" 304 0 "-" "Tiny Tiny RSS/20.11-242aa6e41 (http://tt-rss.org/)"

这些非完全结构化的数据,是不能够被 ClickHouse 解析和使用的,想要做快速的数据分析自然也就无从谈起。

开源社区现有方案

为了解决上面的问题,开源社区出现了一些方案。我们大概有以下几种选择:

  • 方案一 Clicktail:能够将 MySQL、Nginx等半结构化日志结构化,然后在流式处理的过程中,直接发送至 ClickHouse Client,然后进行结构化导入的开源工具。
  • 方案二 nginx-clickhouse:能够将 Nginx 运行日志结构化并发送至 ClickHouse 进行处理,并提供了 Prometheus 监控抓取使用的性能指标接口。
  • 方案三 seslog:兼容 Nginx 日志协议的服务器,能够将数据转换并写入 Clickhouse 。
  • 方案四 nginx2clickhouse:由C编写的,基于字符串匹配替换的小工具,能够将 Nginx 日志进行转换处理,方便我们手动导入 ClickHouse。
  • 方案五 rsyslog-nginx-clickhouse:严格意义来说,这不是工具,而是一个文档。介绍了如何配置 Nginx ,并使用 Rsyslog 进行转换,然后存储至 ClickHouse。

将这些方案进行分类的话,大概可以分为下面三种类型:

  • 我有存量的现成数据,需要先使用结构化数据转换,然后手动导入 ClickHouse:方案四
  • 我需要处理实时生产的 Nginx 数据:方案一,方案二,方案三,方案五
  • 如果我想处理非 Nginx 生产的半结构化数据,比如 MySQL:只有方案一

现有方案存在的问题及亮点

不过,这些方案的诞生都基于非常固定的场景和受众,所以在我们文中提到的场景下(通用的,适用于批量离线数据处理),会存在一些问题:

  • 看似万能的方案一,开发者已经弃坑。代码比较陈旧,有一些依赖已经找不到了,如果想进行定制和开发,有一定的重构成本。
  • 方案二、方案三、方案五,如果想使用,需要使用“日志重放”的方式,效率低、流程复杂。而且这些方案均不能处理 Nginx 日志之外的数据,通用性比较差。
  • 方案四,因为程序逻辑固定,所以要求 Nginx 的字段需要重新配置,也就是说,如果不按照这个约定规则进行,则无法进行数据转换、分析。并且这个程序只能处理 Nginx 日志,缺少通用性。

虽然上面的方案各自存在一些场景不适配的问题,但是这些方案之间有都有一些可取之处:

  • 方案一至方案四,使用性能下限高的语言(Golang、C)进行工具编写,工具执行效率相比脚本语言高。
  • 方案四,无状态的工具使用场景最符合我们的需求,适合离线批处理,解决大尺寸日志的分析导入。
  • 方案五,能够灵活配置来源日志,场景适配性强。其中Rsyslog 组件 liblognorm 非常适合作为方案中的 “transporter” 使用。

它山之石,可以攻玉

在清楚了解上述方案的问题和优点之后,我们就可以简单的实现我们的工具方案啦,初步思路:

  1. 使用 Linux catgrepawkuniq 以及其他命令快速进行数据预处理
  2. 使用 liblognorm 组件中的 lognormalizer 进行日志格式解析和转换,将日志转换为 JSON 格式。
  3. 编写一个小脚本针对上一步的数据进行进一步加工处理,修正诸如时间等不符合预期的数据。
  4. 使用 ClickHouse Client 直接进行数据导入,以及数据字段调整,然后进行分析。

第一步:数据预处理

使用 Linux 命令进行日志的基础处理,在《日志分析处理:GoAccess 篇》一文中有提到,这里就不进一步展开了。感兴趣的同学可以翻阅之前的文章。

第二步:使用 lognormalizer 进行日志结构化

这部分的相关代码,我已经上传至 GitHub,有需要可以自取。

lognormalizer 被包含在Rsyslog 的组件 liblognorm 中。它能够根据配置的方式,快速的将各种具有一定结构的半结构化的内容序列为我们想要的结构化格式。

相比较这几年的后起之秀,官方并未积极维护它的发行版,从 https://repology.org/project/liblognorm/versions 可以看到,我们只能在 Fedora 、OpenBSD、Alpine 的发行版上以开箱即用的方式使用到它的最新版本。

**所以,如果追求绝对的高性能,我们需要自行编译。**不过因为它发布了 Alpine 版本的二进制文件,或许使用容器也不失为一个简单愉快的选择。(编译的过程能够单独写一篇文章啦,本文先聊聊容器场景)在介绍容器方案前,额外聊一下编译过程中的小细节。

官方文档中对于安装部分的介绍存在一些陈旧的内容,需要进行一些升级替换,诸如使用 libfastjson 替换 json-c 链接库,使用 Rsyslog 的安装依赖完成基础编译环境的部署等,或许后续有时间的时候,我会将它移至到 MacOS,方便平时的使用。

为了愉快使用最新版本的 lognormalizer ,我们需要准备一个容器镜像

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
FROM alpine:3.14

ENV LANG en_US.UTF-8
ENV LANGUAGE en_US.UTF-8
ENV LC_ALL=en_US.UTF-8

RUN apk --no-cache --no-progress update && \
    apk --no-cache --no-progress upgrade

RUN apk add liblognorm

为了方便后续使用,我将这个镜像推送到了 DockerHub,你可以通过下面的命令直接下载和使用它:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker pull soulteary/lognormalizer:2.0.6

为了验证 lognormalizer 是否能够正常使用,我们可以准备一小部分日志数据,以及编写简单的解析配置,并创建一个应用容器,试着使用它进行一下数据转换。

我们将下面的内容保存为 parser.rule (配置来自 rsyslog-nginx-clickhouse 方案):

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
version=2

rule=:%clientip:word% %ident:word% %auth:word% [%day:char-to:/%/%month:char-to:/%/%year:number%:%rtime:word% %tz:char-to:]%] "%verb:word% %request:word% HTTP/%httpversion:float%" %response:number% %bytes:number% "%referrer:char-to:"%" "%agent:char-to:"%"%blob:rest%

然后顺手抽取日志文件的前三行,作为测试数据:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
head -n 3 logs/2021.log > sample.txt

接着,启动一个测试容器,把上面提到的配置和测试日志数据都挂载进容器中:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker run --rm -it -v `pwd`/sample.txt:/sample.txt -v `pwd`/parser.rule:/parser.rule soulteary/lognormalizer:2.0.6 sh

手动加载数据,使用管道传递给 lognormalizer 进行结构化输出,设置输出格式为 JSON

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
cat sample.txt | lognormalizer -r parser.rule -e json

不出意外,我们将得到类似下面的输出:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{ "blob": "", "agent": "Tiny Tiny RSS\/20.08-5497a13 (http:\/\/tt-rss.org\/)", "referrer": "-", "bytes": "0", "response": "304", "httpversion": "1.1", "request": "\/feed\/", "verb": "GET", "tz": "+0000", "rtime": "00:02:34", "year": "2021", "month": "Jan", "day": "01", "auth": "-", "ident": "-", "clientip": "xxx.xxx.xxx.xxx" }
...

上面的内容,是不是看起来已经搞的差不多了?但是仔细观察,这里的时间有一些问题:“"month": "Jan"”,Nginx 日志中默认的时间记录方式,并不适合我们后续在 ClickHouse 中进行结构化查询,所以我们要考虑对它进行进一步的处理,将它处理为“数值”。

第三步:编写基础的转换数据

为了兼顾执行效率和简单,我们可以使用 Golang 编写一个小工具,来帮助我们进行第二步中数据的收尾工作。考虑到执行效率,我们同样可以让中间过程的数据直接借助 Linux Pipeline 进行传递,而无需落盘。

想要实现一个简单的,能够通过“管道”读取数据,然后将十二个月的月份字符串名称替换为“数字”的程序,可以考虑下面的方式:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
package main

import (
 "bufio"
 "fmt"
 "os"
 "strings"
)

func main() {
 monthLabels := []string{"\"Jan\"", "\"Feb\"", "\"Mar\"", "\"Apr\"", "\"May\"", "\"Jun\"", "\"Jul\"", "\"Aug\"", "\"Sep\"", "\"Oct\"", "\"Nov\"", "\"Dec\""}
 monthValues := []string{"\"01\"", "\"02\"", "\"03\"", "\"04\"", "\"05\"", "\"06\"", "\"07\"", "\"08\"", "\"09\"", "\"10\"", "\"11\"", "\"12\""}

 src, _ := bufio.NewReader(os.Stdin).ReadString('\n')
 for i, monthLabel := range monthLabels {
  if strings.Contains(src, monthLabel) {
   dest := strings.Replace(src, monthLabel, monthValues[i], -1)
   fmt.Println(dest)
   return
  }
 }
 fmt.Println("")
}

我们将代码保存为 test.go ,然后使用第二步中的数据和简单的命令对其进行测试:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
echo '{ "blob": "", "agent": "Tiny Tiny RSS\/20.08-5497a13 (http:\/\/tt-rss.org\/)", "referrer": "-", "bytes": "0", "response": "304", "httpversion": "1.1", "request": "\/feed\/", "verb": "GET", "tz": "+0000", "rtime": "00:02:34", "year": "2021", "month": "Jan", "day": "01", "auth": "-", "ident": "-", "clientip": "xxx.xxx.xxx.xxx" }' | go run test.go 

命令执行完毕,会看到数据已经变成了我们预期的样子,月份被正确的转换为了数字:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
{ "blob": "", "agent": "Tiny Tiny RSS\/20.08-5497a13 (http:\/\/tt-rss.org\/)", "referrer": "-", "bytes": "0", "response": "304", "httpversion": "1.1", "request": "\/feed\/", "verb": "GET", "tz": "+0000", "rtime": "00:02:34", "year": "2021", "month": "01", "day": "01", "auth": "-", "ident": "-", "clientip": "xxx.xxx.xxx.xxx" }

熟悉 Golang 的小伙伴不难发现上面这段示例代码的问题:每次只能接受一条数据进行处理。那么我们继续对它进行一些简单的调整:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
package main

import (
 "bufio"
 "fmt"
 "os"
 "strings"
)

func main() {
 monthLabels := []string{"\"Jan\"", "\"Feb\"", "\"Mar\"", "\"Apr\"", "\"May\"", "\"Jun\"", "\"Jul\"", "\"Aug\"", "\"Sep\"", "\"Oct\"", "\"Nov\"", "\"Dec\""}
 monthValues := []string{"\"01\"", "\"02\"", "\"03\"", "\"04\"", "\"05\"", "\"06\"", "\"07\"", "\"08\"", "\"09\"", "\"10\"", "\"11\"", "\"12\""}

 scanner := bufio.NewScanner(os.Stdin)
 for scanner.Scan() {
  src := scanner.Text()
  for i, monthLabel := range monthLabels {
   if strings.Contains(src, monthLabel) {
    dest := strings.Replace(src, monthLabel, monthValues[i], -1)
    fmt.Println(dest)
    break
   }
  }
 }
}

简单调整之后,这个小工具就能和 cat 等 Linux 工具正常协作,进行大文件的流式处理啦。如果你愿意的话,还可以进一步进行优化,比如拆分工作线程。以上面这段示例代码为例,处理 2G 不到的文件,大概需要 9s 左右,如果进行优化的话,应该时间消耗能够降低到 1~3s,感兴趣的朋友可以试试。

考虑到这个工具需要和第二步中的 lognormalizer 一起使用,所以我们在进行容器构建的时候,可以复用第二步创建的镜像。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
FROM soulteary/lognormalizer:2.0.6 AS Builder
RUN apk add go
COPY datepatcher.go /
RUN go build datepatcher.go

FROM soulteary/lognormalizer:2.0.6
COPY --from=Builder /datepatcher /bin/

为了方便使用,我同样地将这个镜像上传到了 DockerHub:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker pull soulteary/lognormalizer-with-datapatcher:2.0.6

这部分代码,我也上传到了 GitHub,可以根据实际需求进行调整。在完成了转换工具镜像的准备后,我们可以编写一个容器编排配置,来使用这个镜像:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
version: "2"

services:

  converter:
    image: soulteary/lognormalizer-with-datapatcher:2.0.6
    container_name: lognormalizer
    command: tail -f /etc/hostname
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - ./logs:/logs
    tmpfs:
      - /cache

使用 docker-compose down && docker-compose up -d 启动镜像,将我们需要处理的日志和前文中提到的 parser.rule 放置在 logs 目录中,然后就可以执行命令进行日志转换了。

这里可以考虑借助 TmpFS 进行数据读写加速,比如先将要处理的数据文件移动至 TmpFS 目录(转换速度至少提升15倍以上):

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker exec -it lognormalizer sh -c "cp /logs/2021.log /cache/2021.log"

根据你的文件位置,适当调整下面的命令,然后开始转换,等待计算完成即可。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker exec -it lognormalizer sh -c "cat /cache/2021.log | lognormalizer -r /logs/parser.rule -e json | datepatcher > /cache/data.log"

最后,将计算完成的文件使用 docker cp 或者移动到我们挂载出来的目录即可准备导入 ClickHouse。

为了节约空间,你还可以对刚刚我们创建的容器进行一个收尾清理:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
docker kill lognormalizer
docker rm lognormalizer

第四步:导入 ClickHouse

你可以选择参考《快速上手 ClickHouse》一文中的方式搭建一个 ClickHouse 示例,或者直接使用云端的 ClickHouse 数据库进行操作。我们以容器为例,展开接下来的内容。

使用 docker exec -it clickhouse clickhouse-client 进入 Clickhouse 交互控制台,创建一个数据库:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CREATE DATABASE IF NOT EXISTS soulteary

然后创建一个临时表,用于存放我们的日志数据。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CREATE TABLE IF NOT EXISTS soulteary.tmp
(
    `year` String,
    `month` String,
    `day` String,
    `rtime` String,
    `clientip` String,
    `ident` String,
    `auth` String,
    `verb` String,
    `request` String,
    `httpversion` String,
    `response` UInt16,
    `bytes` UInt64,
    `referrer` String,
    `agent` String,
    `blob` String
)
ENGINE = MergeTree
ORDER BY (year, month, day, rtime)

有的同学会好奇,上面的表结构看起来已经很完善了,为啥还要创建临时表呢,直接当正式表来用不可以吗?

这是因为在前几步转换出来的数据将“日期”、“时间”字段进行了拆分,如果我们想要基于时间维度进行快速排序或者统计分析,不论是基于基础的“数字”类型,还是基于基础的“文本”类型,在分析的过程中都会比较低效,所以我们需要考虑使用程序生成这两个字段。那么正式表的表结构又是怎样的呢?

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
CREATE TABLE IF NOT EXISTS soulteary.nginx
(
    `date` Date,
    `time` DateTime,
    `year` UInt16,
    `month` UInt16,
    `day` UInt16,
    `rtime` String,
    `clientip` String,
    `ident` String,
    `auth` String,
    `verb` String,
    `request` String,
    `httpversion` String,
    `response` UInt16,
    `bytes` UInt64,
    `referrer` String,
    `agent` String,
    `blob` String
)
ENGINE = MergeTree
ORDER BY (year, month, day, rtime)
SETTINGS index_granularity = 8192

可以看到,在正式表中,我们的字段类型有了一些调整,除此之外,也多了 datetime 两个字段。

退出交互式控制台,使用 docker exec -it clickhouse clickhouse-client 进入 ClickHouse 容器中,执行命令将前三步中的数据正式导入 Clickhouse。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
cat /var/lib/clickhouse/data.log | clickhouse-client -n --query="SET input_format_skip_unknown_fields=1; INSERT INTO soulteary.tmp FORMAT JSONEachRow"

稍等片刻,命令执行完毕之后,执行 clickhouse-client 再次进入 ClickHouse 交互式控制台,然后执行语句,开始进行临时表到正式表到数据迁移,和字段补全:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
INSERT INTO soulteary.nginx SELECT
    toDateTime(concat(year, '-', month, '-', day, ' ', rtime)) AS fullDateLabel,
    toDate(fullDateLabel),
    year,
    month,
    day,
    rtime,
    clientip,
    ident,
    auth,
    verb,
    request,
    httpversion,
    response,
    bytes,
    referrer,
    agent,
    blob
FROM soulteary.tmp

执行完毕,会看到类似下面的日志输出:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
Query id: 43a1fcbc-1078-4add-b6f7-7c425085ca4b

Ok.

0 rows in set. Elapsed: 4.848 sec. Processed 3.71 million rows, 1.09 GB (764.84 thousand rows/s., 225.44 MB/s.)

第五步:检查数据

数据迁移完毕,我们可以使用命令检查一下,确保数据迁移完毕。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SELECT
    prod,
    tmp
FROM
(
    SELECT count() AS prod
    FROM soulteary.nginx
) AS table_prod,
(
    SELECT count() AS tmp
    FROM soulteary.tmp
) AS table_tmp

Query id: 2415f48b-39f2-4bcd-8c5b-0971e4ada6a3

┌────prod─┬─────tmp─┐
│ 37077763707776 │
└─────────┴─────────┘

1 rows in set. Elapsed: 0.004 sec. 

再手动随便执行一条具体内容的查询:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
SELECT *
FROM soulteary.nginx
LIMIT 1


┌───────date─┬────────────────time─┬─year─┬─month─┬─day─┬─rtime────┬─clientip───────┬─ident─┬─auth─┬─verb─┬─request─┬─httpversion─┬─response─┬─bytes─┬─referrer────────────────────┬─agent─────────────────────────────────────────────┬─blob─┐
│ 2021-01-012021-01-01 00:00:0020211100:00:24111.231.78.131--GET/feed/1.120015130 │ https://soulteary.com/feed/ │ FreshRSS/1.16.3-dev (Linux; https://freshrss.org) │      │
└────────────┴─────────────────────┴──────┴───────┴─────┴──────────┴────────────────┴───────┴──────┴──────┴─────────┴─────────────┴──────────┴───────┴─────────────────────────────┴───────────────────────────────────────────────────┴──────┘

可以看到数据正确的迁移到了正式表,并且缺失的 datetime 字段也被正确的补全了。

最后

写到这里,如何使用 Clickhouse 处理离线的半结构化数据的话题也就结束了。

或许下一篇 ClickHouse 相关的内容里,我会接着《装在笔记本里的私有云环境:监控篇》的话题,聊一聊集成 Grafana 进行可视化。

--EOF

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-11-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 折腾技术 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Pentaho Work with Big Data(五)—— 格式化原始web日志
本示例说明如何使用Pentaho MapReduce把原始web日志解析成格式化的记录。 一、向HDFS导入示例数据文件 将weblogs_rebuild.txt文件放到HDFS的/user/grid/raw/目录下(因资源有限,本示例只取了这个文件的前10行数据) 参考: http://blog.csdn.net/wzy0623/article/details/51133760 二、建立一个用于Mapper的转换 1. 新建一个转换,如图1所示。
用户1148526
2022/05/07
2110
Pentaho Work with Big Data(五)—— 格式化原始web日志
Kettle与Hadoop(五)执行MapReduce
本示例说明如何使用Pentaho MapReduce把原始web日志解析成格式化的记录。
用户1148526
2020/06/04
5760
logstash 配置
https://github.com/chudaozhe/efk/tree/master/logstash
崔哥
2022/05/25
5700
利用ELK分析Nginx日志生产实战(高清多图)
本文以api.mingongge.com.cn域名为测试对象进行统计,日志为crm.mingongge.com.cn和risk.mingongge.com.cn请求之和(此二者域名不具生产换环境统计意义),生产环境请根据具体需要统计的域名进行统计。
民工哥
2020/09/16
2K0
rsyslog的安装、使用、详解
Rsyslogd的配置文件是/etc/rsyslog.conf,一般在/etc目录下,先看看rsyslog client的配置:
sunsky
2020/08/20
2.9K0
rsyslog的安装、使用、详解
graylog日志分析系统上手教程
日志分析系统可以实时收集、分析、监控日志并报警,当然也可以非实时的分析日志。splunk是功能强大且用起来最省心的,但是要收费,免费版有每天500M的限制,超过500M的日志就没法处理了。ELK系统是最常见的,缺点是配置麻烦一些,比较重量级。graylog是开源免费的,配置上要比ELK系统简单。综上,本文尝试容器方式搭建一套graylog系统,不做实时收集日志和报警的配置,只完成非实时被动接收网站日志,分析日志各项指标的功能。 docker官方镜像国内速度我觉得慢,改成国内镜像。新建文件daemon.json如下
震八方紫面昆仑侠
2020/09/01
8.7K1
graylog日志分析系统上手教程
Logstash:Data转换,分析,提取,丰富及核心操作
在今天的这篇文章中,着重介绍 Logstash 在数据转换,分析,提取及核心操作方便的内容。首先,希望大家已经按照我之前的文章 “如何安装Elastic栈中的Logstash” 把 Logstash 安装好。
腾讯云大数据
2020/07/30
2.3K0
Logstash:Data转换,分析,提取,丰富及核心操作
性能监控之Telegraf+InfluxDB+Grafana实现结构化日志实时监控
由于我们的自研客户端压测工具的测试结果是结构化日志文件,而考虑到目前性能监控需要做到实时化和集中化,那么需要一种定时和批量采集结构化日志文件的采集 agent,而刚好 Telegraf Logparser插件可以满足这个需求。
高楼Zee
2019/10/24
2.7K0
性能监控之Telegraf+InfluxDB+Grafana实现结构化日志实时监控
Logstash 配置 Grok 语法
Grok 是一种采用组合多个预定义的正则表达式。用来匹配分割文本,并且映射到关键字的工具。主要用来对日志数据进行预处理。Logstash 的 filter 模块中 grok 插件就是其应用。其实主要思想就是用正则的方式匹配出字段,然后映射成某个字段。
王小明_HIT
2019/09/06
9.3K0
Logstash 配置 Grok 语法
一文快速上手Logstash
Elasticsearch是当前主流的分布式大数据存储和搜索引擎,可以为用户提供强大的全文本检索能力,广泛应用于日志检索,全站搜索等领域。Logstash作为Elasicsearch常用的实时数据采集引擎,可以采集来自不同数据源的数据,并对数据进行处理后输出到多种输出源,是Elastic Stack 的重要组成部分。本文从Logstash的工作原理,使用示例,部署方式及性能调优等方面入手,为大家提供一个快速入门Logstash的方式。文章最后也给出了一些深入了解Logstash的的链接,以方便大家根据需要详细了解。
michelmu
2018/10/10
51.9K13
一文快速上手Logstash
日志分析处理:GoAccess 篇
这篇文章原计划在 2020 年中智源大会举办完毕之后整理出来,奈何各种事情阻塞,一直拖延至今。恰逢年末跑一些数据,以及计划搭建一些日常辅助业务运营的实时看板,借着机会把内容整理出来。
soulteary
2020/12/16
8970
日志分析处理:GoAccess 篇
了解Logstash
Logstash是一个开源数据收集引擎,具有实时管道功能。Logstash可以动态地将来自不同数据源的数据统一起来,并将数据标准化到你所选择的目的地。
java架构师
2019/01/02
1.4K0
【Elasticsearch系列四】ELK Stack
ELK Stack 是由 Elasticsearch、Logstash 和 Kibana 三个开源工具组成的日志分析平台。它能够高效地处理和分析大量日志数据,帮助用户快速发现、分析和可视化数据。
kwan的解忧杂货铺
2024/09/16
4850
使用fluent bit+ClickHouse 实现K8s日志采集
Fluent bit是一个用C写成的插件式、轻量级、多平台开源日志收集工具。它允许从不同的源收集数据并发送到多个目的地。完全兼容docker和kubernetes生态环境。
灵雀云
2021/12/28
2.8K0
使用fluent bit+ClickHouse 实现K8s日志采集
一文了解ClickHouse
ClickHouse是Yandex(俄罗斯最大的搜索引擎)开源的一个用于实时数据分析的基于列存储的数据库,其处理数据的速度比传统方法快100-1000倍。ClickHouse的性能超过了目前市场上可比的面向列的DBMS,每秒钟每台服务器每秒处理数亿至十亿多行和数十千兆字节的数据。
用户1278550
2020/05/15
1.5K0
利用 ELK系统分析Nginx日志并对数据进行可视化展示
这篇文章介绍的是单独监控nginx 日志分析再进行可视化图形展示,并在用户前端使用nginx 来代理kibana的请求响应,访问权限方面暂时使用HTTP 基本认证加密用户登录。(关于elk权限控制,我所了解的还有一种方式-Shield),等以后有时间了去搞下。下面开始正文吧。。。
星哥玩云
2022/06/18
1K0
利用 ELK系统分析Nginx日志并对数据进行可视化展示
基于Clickhouse的日志体系
1、flink对微服务的topic数据清洗后,丢到一个新的Kafka的topic里面
保持热爱奔赴山海
2022/01/11
3.4K0
基于Clickhouse的日志体系
Clickhouse分布式集群搭建
安装zookeeper集群,也可以使用现成的,本次使用现成的,配置如下,后续加入配置文件中
职场亮哥
2020/10/10
3.9K0
Elastic Stack日志收集系统笔记 (logstash部分)
Logstash管道有两个必需的元素,input和output,以及一个可选的元素filter。输入插件使用来自源的数据,过滤器插件在您指定时修改数据,输出插件将数据写入目标。
没有故事的陈师傅
2019/07/27
3.4K0
ClickHouse(06)ClickHouse建表语句DDL详细解析
创建新表具有几种种语法形式,具体取决于用例。默认情况下,仅在当前服务器上创建表。分布式DDL查询作为子句实现,该子句另外描述。
张飞的猪
2024/03/09
1K0
ClickHouse(06)ClickHouse建表语句DDL详细解析
相关推荐
Pentaho Work with Big Data(五)—— 格式化原始web日志
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档