数据工程后端【免费下载链接】logstashLogstash - transport and process your logs, events, or other data项目地址https://gitcode.com/gh_mirrors/lo/logstash点击查看免费下载本文围绕 Logstash 官方仓库.buildkite/scripts/benchmark/目录下的基准测试Benchmark方案展开系统讲解如何在一台 GCP 虚拟机n2-standard-16 Ubuntu上搭建一套「flog 造数 → Filebeat 采集 → Logstash 处理 → Elasticsearch Cloud 存储与可视化」的完整压测链路并介绍其核心脚本main.sh/marathon.sh的参数体系、运行机制与结果数据结构。读完本文你将掌握如何复现 Logstash 官方 CI 使用的吞吐量EPS基准测试环境如何自由切换队列类型内存队列 / 持久化队列、worker 数量与 batch size 组合以及如何把压测摘要写入benchmark_summary索引并用 Kibana 仪表盘进行多版本横向对比。基准测试方案概览一次压测的完整数据链路基准测试的物理拓扑是「Filebeatdocker→ Logstashdocker→ ES Cloud」即官方 CI 在 Buildkite 上自动运行的压测流程见 .buildkite/benchmark_pipeline.yml 中Benchmark Snapshot步骤。整个链路包含三层数据生成层使用mingrammer/flog容器生成约 2GB 的日志文件默认 4 个文件、每个 500MB作为 Filebeat 的读取源采集与处理层若干个 Filebeat 容器默认 4 个以log类型 input 读取 flog 生成的日志通过localhost:5044送入 Logstash 容器Logstash 同时运行两条流水线main 流水线beatsinput →elasticsearchoutput把事件写入数据流logs-generic-default承担真实的压测负载node_stats 流水线通过http_poller每 30 秒拉取一次 Logstash 自身/_node/stats指标写入数据流metrics-nodestats-logstash用于监控压测过程中的资源占用结果汇总层脚本对每个测试组合聚合吞吐量与资源指标生成摘要文档写入benchmark_summary索引实际指向benchmark_summary_v2索引最终由 Kibana 仪表盘展示。这两条流水线的完整定义位于 .buildkite/scripts/benchmark/config/pipelines.ymlmain 流水线直接使用beats与elasticsearch插件node_stats 流水线在mutatefilter 中为每条监控记录打上[benchmark][label]形如${QTYPE}_w${WORKER}b${BATCH_SIZE}从而在可视化时区分不同的测试组合。第一步创建并初始化 GCP 基准测试实例官方 README 给出了最小化的环境准备步骤以下为完整可复现操作创建虚拟机机型n2-standard-1616 vCPU镜像Ubuntu官方 CI 实际使用platform-ingest-logstash-ubuntu-2204镜像族磁盘 100GB、pd-ssd见 .buildkite/benchmark_pipeline.yml安装 Dockersudo snap install docker sudo usermod -a -G docker $USER安装后需要重新登录或执行newgrp docker使 docker 组权限生效。安装 jq压测脚本全程依赖jq解析 Vault 返回的 JSON 凭据以及/_node/stats指标可用sudo apt install jq或 snap安装。安装 Vault 并读取凭据脚本通过 HashiCorp Vault 获取 Elasticsearch 连接凭据而非把明文写入配置文件sudo snap install vault vault login --method github vault kv get -format json secret/ci/elastic-logstash/benchmarkvault kv get返回的 JSON 中脚本见 .buildkite/scripts/benchmark/core.sh 中get_secret()会提取六项凭据es_host/es_user/es_pw压测数据写入的目标 ElasticsearchBENCHMARK_ES_*monitor_es_host/monitor_es_user/monitor_es_pw监控指标写入的目标 ElasticsearchMONITOR_ES_*。设计上压测数据与监控数据可以指向不同的集群这正是为了避免污染共享基准集群而预留的能力。第二步初始化 Elasticsearch 索引与别名在 Elasticsearch 中执行setup/目录下两个请求文件.buildkite/scripts/benchmark/setup/benchmark_summary_v2 与 .buildkite/scripts/benchmark/setup/alias为benchmark_summary_v2索引创建 mapping覆盖脚本send_summary()写出的全部字段timestampdate、version、cpu、mem、workers、batch_size、queue_type、total_events_out、max_eps_1m、max_eps_5m、max_worker_utilization、max_worker_concurrency、avg_cpu_percentage、avg_heap、avg_non_heap、avg_virtual_memory、max_queue_events、max_queue_bytes_size以及tags通过POST /_aliases把别名benchmark_summary挂到benchmark_summary_v2上使脚本以benchmark_summary为索引名的 bulk 写入自动落到 v2 索引。mapping 中所有数值指标均附带keyword子字段便于 Kibana 中做聚合与排序。第三步导入 Kibana 仪表盘save-objects/benchmark_objects.ndjson.buildkite/scripts/benchmark/save-objects/包含两类可视化资产仪表盘Dashboardsdaily snapshot、released versions数据视图Data Viewsbenchmark带有两个 runtime fieldsversions_numlong把语义化版本号转换为数字用于图表排序releasebooleanversion含 SNAPSHOT 时为false否则为true用于过滤已发布版本与快照版本。导入方式在 Kibana 中进入Stack Management Saved Objects点击Import选择该 ndjson 文件即可。第四步运行基准测试脚本环境就绪后执行主脚本# 使用默认参数4 个 Filebeat同时测试内存队列与持久化队列 bash .buildkite/scripts/benchmark/main.sh # 指定参数4 个 Filebeat仅测内存队列容器分配 4 CPU / 4GB 内存 bash .buildkite/scripts/benchmark/main.sh 4 memory 4 4 # 后台长时间运行并保留日志 nohup bash -x main.sh log.log 21 参数体系main.sh支持四个位置参数源码见 .buildkite/scripts/benchmark/main.sh位置参数含义默认值FB_CNT并发 Filebeat 容器数4QTYPE队列类型persisted/memory/all两者都测allCPULogstash 容器分配的 CPU 数4MEMLogstash 容器分配的内存GB4同时支持一批环境变量精细控制压测矩阵在parse_args()中解析环境变量含义默认值LS_VERSIONLogstash docker tag如8.15.0-SNAPSHOT无自动取 main 分支最新 SNAPSHOTFB_VERSIONFilebeat docker tag8.13.4LS_JAVA_OPTSLogstash JVM 参数如-Xmx2g-Xmx$(MEM/2)g堆为内存一半MULTIPLIERSworker 乘数列表逗号分隔实际 worker CPU × 乘数1,2,4BATCH_SIZESbatch size 列表逗号分隔500FLOG_FILE_CNT生成的日志文件数4VAULT_PATH指向自己 Elasticsearch 凭据的 Vault 路径secret/ci/elastic-logstash/benchmarkTAGS附加到摘要文档的标签逗号分隔无main()的执行顺序为parse_args→get_secret→generate_logs→pull_images→check_logs→create_directory→queue/worker→clean_up。数据生成与镜像拉取日志生成generate_logs()以 detached 模式启动 flog 容器-b指定总字节数默认 4 × 500MB ≈ 2GB-p指定单文件大小输出到flog/log.logcheck_logs()会每 30 秒轮询一次最长等待 300 分钟直到文件生成完毕。镜像拉取pull_images()若未指定LS_VERSION脚本会从https://storage.googleapis.com/artifacts-api/snapshots/main.json获取 main 分支最新的 SNAPSHOT 版本号与 build_id下载对应的 docker 镜像 tar 包并docker load实现「每天自动压测最新快照」的效果Filebeat 则固定拉取docker.elastic.co/beats/filebeat:$FB_VERSION。Logstash 与 Filebeat 的启动方式start_logstash()会把 config/logstash.yml、pipelines.yml和uuid复制到工作目录随后以--nethost启动容器并通过--cpus$CPU、--memory${MEM}g限制资源通过环境变量把WORKER、BATCH_SIZE、QTYPE以及两组 ES 凭据注入配置模板。logstash.yml中对应的关键配置为api.http.host: 0.0.0.0 pipeline.workers: ${WORKER} pipeline.batch.size: ${BATCH_SIZE} queue.type: ${QTYPE} xpack.monitoring.allow_legacy_collection: true xpack.monitoring.enabled: true xpack.monitoring.elasticsearch.username: ${MONITOR_ES_USER} xpack.monitoring.elasticsearch.password: ${MONITOR_ES_PW} xpack.monitoring.elasticsearch.hosts: [${MONITOR_ES_HOST}]start_filebeat()则为每个索引fb0..fbN-1启动一个容器挂载filebeat.yml与 flog 日志目录。Filebeat 配置.buildkite/scripts/benchmark/config/filebeat.yml要点关闭自身 HTTP 监控http.enabled: false、读取/usr/share/filebeat/flog/*.log、输出到localhost:5044并设置了ttl: 10ms与bulk_max_size: 2048以贴近真实高吞吐场景。单组合测试流程与指标采集run_pipeline()定义一个测试组合的执行过程启动 Logstash 与 Filebeat 容器静置 3 分钟让系统进入稳态通过docker exec -i ls curl localhost:9600/_node/statsnode_stats()采集第一份快照之后每 30 秒采集一次共 8 次每次采集后若发现当前输出吞吐为 0max -g ${CURRENT/./} 0会打印fb0与ls的 docker 日志辅助排查aggregate_stats()对同一组合的所有快照求 max/avgsend_summary()组装摘要 JSON 并 bulk 写入benchmark_summary。capture_stats()采集的指标包括flow.output_throughputcurrent / last_1_minute / last_5_minutes、worker_utilization、worker_concurrency、process.cpu.percent、jvm.mem.heap_used_in_bytes与non_heap_used_in_bytes、pipelines.main.queue.events_count与queue_size_in_bytes以及pipelines.main.events.out——这些都是理解 Logstash flow 指标与队列背压状态的关键字段。组合的穷举逻辑位于queue()/worker()/batch()当QTYPEall时先遍历persisted、memory两种队列类型对每种类型按MULTIPLIERS计算 worker 数WORKER CPU × m对每个 worker 再遍历BATCH_SIZES。例如main.sh 4 all 4 4默认会跑 2 队列 × 3 worker 档4/8/16× 1 个 batch size 6 个组合每个组合约 7 分钟。每次组合结束后stop_pipeline()会删除容器并清理数据流logs-generic-default保证各组合起始状态一致。第五步多版本校准marathon.sh当更换硬件或需要建立不同版本间的性能基线时使用marathon.sh.buildkite/scripts/benchmark/marathon.shnohup bash -x all.sh log.log 21 它通过环境变量STACK_VERSIONS逗号分隔版本列表默认覆盖8.9.0至9.0.0的多个历史版本依次对每个版本执行完整的queue/worker组合测试其文档注释明确说明当硬件变化时运行 marathon 任务以建立新的基线。默认版本列表会随仓库更新实际值以脚本为准。它复用了core.sh的全部逻辑因此同样支持FB_CNT、QTYPE、CPU、MEM等参数。版本差异与注意事项README 明确列出三条重要的使用前提与限制仅可在相同硬件配置下横向对比基准测试结果受 CPU、内存、磁盘类型影响极大不同机器上的 EPS 绝对值不具备可比性基准对比必须限定同一硬件环境不要把测试数据写入共享基准集群默认VAULT_PATHsecret/ci/elastic-logstash/benchmark指向共享的基准集群。自行压测时应把VAULT_PATH指向自己的 Vault 路径如secret/ci/elastic-logstash/your/path让压测数据与监控指标都发送到自有 Elasticsearch避免污染共享集群的对比数据版本 8 与旧监控配置的兼容性logstash.yml中xpack.monitoring.allow_legacy_collection: true是 8.x 版本不认识的配置。core.sh中的remove_v9_config()会在 Logstash 主版本小于 9 时自动从logstash.yml中删除该行而要在 8.x 上跑基准测试应当使用对应分支如8.16的脚本而不是main分支的脚本相关变更见仓库 PR 记录。结果数据的解读与可视化每次组合的摘要文档包含运行环境标识version/cpu/mem/workers/batch_size/queue_type/tags与性能指标max_eps_1m、max_eps_5m、max_worker_utilization、max_worker_concurrency、avg_cpu_percentage、avg_heap、avg_non_heap、avg_virtual_memory、max_queue_events、max_queue_bytes_size、total_events_out。借助 Kibana 数据视图的 runtime fieldsversions_num用于版本排序、release用于区分发布版与快照版即可在「daily snapshot」与「released versions」仪表盘上观察各版本、各队列类型、各 worker/batch 组合下的吞吐与资源消耗曲线从而做出容量规划与回归判断。上述完整配置与脚本均位于 .buildkite/scripts/benchmark/ 目录包括main.sh、core.sh、marathon.sh、util.sh及config/、setup/、save-objects/子目录可直接作为自建 Logstash 性能压测体系的设计蓝本。赞分享数据工程后端【免费下载链接】logstashLogstash - transport and process your logs, events, or other data项目地址https://gitcode.com/gh_mirrors/lo/logstash点击查看免费下载相关推荐Fluent Bit性能基准测试与Vector、Filebeat性能对比Fluent Bit性能基准测试与Vector、Filebeat性能对比 在现代日志处理架构中选择一款高性能的日志收集器对系统稳定性和运维效率至关重要。Fl可观测性云原生实时日志监控告警管道实践Pathway 对接 Filebeat/Logstash、Kafka 与 ElasticSearch实时日志监控告警管道实践Pathway 对接 Filebeat/Logstash、Kafka 与 ElasticSearch 本文基于仓库中的端到端示例项目后端流处理实时分析数据工程人工智能RAG三步打造你的专业音乐播放器foobox美化方案全攻略三步打造你的专业音乐播放器foobox美化方案全攻略 还在为foobar2000单调的界面而烦恼吗你是否希望音乐播放器既有专业音质又有美观界面foobox桌面应用音视频创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考