剛開始的時候直接使用的系統暴露的prometheus metrics，發現越高的版本反而性能越差，期間使用過了
perf 打算使用perf 生成火焰圖的，但是因為符號缺失，只找到了占用較高的任務，詳細的暫時沒有取到
以前大概知道一個工具perf-map-agent 可以用來生成缺失的符號，但是只是不太好，發現了async-profiler
工具，使用方便，支持的版本都，同時也支持基於容器的部署模型，但是容器運行暫時有點問題，所以直接
使用虛擬機運行，配置的分片為1，副本也為1
使用async-profiler 獲取指標
- 下載工具
參考github 項目https://github.com/jvm-profiling-tools/async-profiler - 命令
./profiler.sh -d 120 -o collapsed -f more8 `pid of java`
- 生成火焰圖
使用FlameGraph/flamegraph
下載地址
https://github.com/brendangregg/FlameGraph
生成火焰圖命令
./FlameGraph/flamegraph.pl more8 > flamegraph8.svg
- 效果
發現大部分的占用都是raft 的讀 
幾個問題
- 實際看到磁盤寫很大
從火焰圖我們可以看出讀取占用較多的時間，但是檢測磁盤的話，我們發現磁盤寫很大，可選的排查工具iostat 以及使用async-profiler
使用iostat 我們發現寫是偶然的很大，基本都在20M左右，和我們實際看到的情況一致
使用async-profiler 可以使用tree 模式 ./profiler.sh -d 30 -t -o flat,tree -f zeebe-demo.txt pid of java 我們會發現有寫，但是占用的cpu
時間並不高，如下： 
- 分區與線程的關系
官方有一個介紹是關於分區數與線程的關系，一個分區占用2個線程，和我們看到的raft-server-raft-atomix-partition 任務一致
比如下邊的為4個分區的，從界面看到大概有兩類，后邊再看看atomix 的原理（zeebe 狀態維護的底層依賴） 
目前的幾個結論
- zeebe 目前版本還不太穩定
但是0.21.1 版本比以前的版本穩定 - zeebe 分區個數會嚴重影響系統性能
cpu 核數，磁盤io，以及集群規模都會都系統的響應有很大的影響，推薦部署使用ssd - exporter 對於系統有影響，但是並不大
在測試的過程中，為了簡單exporter 的影響，刪除了對於es exporter的配置，對於系統響應並不提大（通過prometheus metrics 查看） - 后邊還是研究下atomix 的實現原理以及優化（zeebe 強依賴）
參考資料
一個簡單的基於docker-compose 的基礎環境https://github.com/rongfengliang/zeebe-debughttp-exporter-demo 實際運行結合場景
修改下配置
https://docs.zeebe.io/basics/partitions.html
https://github.com/jvm-profiling-tools/async-profiler
https://github.com/brendangregg/FlameGraph
https://github.com/atomix/atomix
https://github.com/Netflix/flamescope