論文には間に合わなくて書けないけど，グラフ構造（ノード，フロー，フローの統計メトリックデータ）をどこに保持させてどの経路で問い合わせるのがいいかを考えている．今は中央の[[Postgres]]に保存することになってるけど，フローの可視化だけにPostgresを運用するのは，めんどくさい．用途として，データの完全性や可用性は高くは求めなくてよいから，中央のDBをもたなくてもよいようにしたい． 各ホストにインストールするエージェントがローカルに自身のホストに紐づくフローデータを保持し，エージェントに対して問い合わせるとフローデータを取得できる． 1. 分散リレー方式: 任意のエージェントに問い合わせると，他の全エージェントに問い合わせて，フローデータをマージする． 2. 専用リレー方式: 専用のリレーコンポーネントをセットアップして，リレーコンポーネントに問い合わせると，リレーコンポーネントが全エージェントに問い合わせて，フローデータをマージする． エージェントのローカルデータストアは，エージェントと合わせて，ホストあたり，コンテナ1つで完結するように，エージェントにDBを組み込む方式を考えている．Go言語であれば，bboltやnutsdb，badgerがある． [etcd-io/bbolt](https://github.com/etcd-io/bbolt) [[B-tree]] - [xujiajun/nutsdb](https://github.com/xujiajun/nutsdb) - [dgraph-io/badger](https://github.com/dgraph-io/badger) LSMツリーのGCでCPU負荷がかかる． bboltとbadger，オプションの持ち方が違う． ノードがダウンしたときのために，別ノードでキャッシュを保持しておいて，キャッシュからデータを引けるようにしたい．問い合わせるのは人間なので，問い合わせ時にキャッシュを更新するだけだと，いざというときにキャッシュがなくて困るかもしれない．キャッシュを自動で更新する仕組みがいりそう．幸い，各ローカルデータストア同士でデータが競合することはない．また，一時的にデータが欠けたりすることは問題にならない．他のreplication factor個のノードに複製を置いて，ノードダウン時には，複製ノードからデータを取得する仕組みがあればよい． - [hashicorp/memberlist](https://github.com/hashicorp/memberlist) - [weaveworks/mesh](https://github.com/weaveworks/mesh) メトリックは，Prometheusにscrapeさせるか，ローカルデータストアに保持するか．両方できるのがよいけど，実装の手間がかかる． [[Grafana]]のエコシステムにうまく乗ってWeb UIを実装したい．GrafanaのPane pluginで，ネットワークトポロジを描いて，[Backend plugin](https://grafana.com/docs/grafana/latest/developers/plugins/backend/) からフローのデータストアを叩く． あとはネットワークグラフをロール単位でグループ化するにはどうしたらいいか考えないといけない．グルーピングのための設定は，クラウドのコンパネやk8s，監視ツールなどに一次情報があるため，API問い合わせ時に，これらのメタ情報をプラグイン形式で取得して，フローデータと突き合わせる．