Skip to content

mo ob benchmark v0.7.0

Jump to bottom
EZ4BRUCE edited this page Apr 10, 2023 · 2 revisions

metric

测试环境

  1. 数据源：go程序提供metrics api模拟数据源
  2. 数据采集：fluentbit input插件进行采集
  3. 数据发送：fluentbit output插件并添加label发送至mo-agent
  4. 数据处理：mo-agent 进行数据处理后写入mo内表
  5. 数据存储：单机版mo（in docker），nightly-796d73d6 3月23日

数据情况

使用当个fluentbit input充当一个node的数据，以下是一个node的数据情况

// 共3200个seies，意味着一次采集有2000条数据分布在2000个指标表中
const Counter = 400   // 400 SERIES
const Gauge = 400     // 400 SERIES
const Histogram = 200 // 实际对应 600 个子指标 1600 SERIES
const Summary = 200   // 实际对应 600 个子指标 800 SERIES
  • 一个node采集一次共3200条数据，对应存在2000个metric数据表中，一个node第一次采集时还会额外存3200条label到labels表中

所以n个node一起采集的时候，采集一次会有 n3200 条数据也是存在2000个metric数据表中，第一次同时采集时也会有n3200 条label到labels表中

为了还原真实情况，为每条数据都加上了k8s的label：

{
    "app_kubernetes_io_component": "\"metrics\"",
    "app_kubernetes_io_instance": "\"mo-agent-stack\"",
    "app_kubernetes_io_managed_by": "\"Helm\"",
    "app_kubernetes_io_name": "\"prometheus-node-exporter\"",
    "app_kubernetes_io_part_of": "\"prometheus-node-exporter\"",
    "app_kubernetes_io_version": "\"1.5.0\"",
    "cpu": "\"0\"",
    "helm_sh_chart": "\"prometheus-node-exporter-4.8.0\"",
    "instance": "\"00.0.0.009100\"",
    "job": "\"kubernetes-service-endpoints\"",
    "mode": "\"iowait\"",
    "namespace": "\"mo-ob\"",
    "node": "\"ip-12-3-4-56.cv-1111-1.compute.internal\"",
    "service": "\"mo-agent-stack-prometheus-node-exporter\"",
    "worker_num": "\"worker1\""
}

测试表现

表格说明：

  1. CPU情况，使用100表示1C用满，200表示2C用满
  2. MEN使用MB

测试1

mo-agent：

  • 资源限制：1C2G，采集间隔1分钟
  • 冷启动时因为需要建表和插入labels，一开始的资源占用会有所提升（尤其是内存，一开始大量labels插入堆积）label只会在一开始进行插入
  • mo-agent的内存占用主要体现在 cache 大量的series id中，一个series就有一个id，一个id是一个长度为32个字符的string：1be201876c0cb38527670a48a7282067​​ 即32 Byte，10万个大概是3MB
  • 预建表：提前建好已知需要存储的表，减少冷启动压力
  • 预加载：将已经在数据库中的label id和metric表名加载到内存

MO：

  • 刚开始冷启动时大量的建表操作和插入会使cpu到200%，后面稳定后会降回

冷启动（无预建表和预加载），稳定运行10分钟时：

node个数 采集间隔 指标数 单次采集series量（等于总label数） agent情况 整体情况
1 1m 2000 3200 CPU：0-5MEN：68~80 数据插入正常，无阻塞
2 1m 2000 6400 CPU：0-5MEN：144~160 数据插入正常，无阻塞
6 1m 2000 19200 CPU：0-5MEN：240~250 数据插入正常，无阻塞
10 1m 2000 32000 CPU：0-5MEN：260~320 数据插入正常，无阻塞（fluentbit内存也200M）
20 1m 2000 64000 CPU：0-5MEN：250~500 一开始labels插入没完成的时候内存占用比较高（达到800m）后面稳定下来（当前版本需要8-9分钟）内存占用就会恢复到400M左右，数据没有堆积阻塞
30 1m 2000 96000 CPU：8MEN：稳定后700-850M 同上，label20分钟才插完稳定，需要优化成并发
40 1m 2000 128000 CPU：8MEN：OOM 失败：同上，一开始2000M内存爆了metric数据管道开始零星出现个位数堆积，随即很快就归0，此时插入一次数据没法很快就全部插完

以上的情况都是一次同时处理的数据，如果能让不同的node错开上报的时间就会很友好，而不是一次同时大量数据

随着数据量上升，主要瓶颈在于单线程插入labels速度较慢

Clone this wiki locally