cndo2021 Dashboard as Codeでダッシュボード管理は改善するか？

発表資料です。

Transcript

1. Dashboard as Code
   の夢と目覚め
   Keiichiro Seto
   

   View Slide

2. 自己紹介
   瀨戸 啓一朗（せと けいいちろう）
   ● Application Engineer
   ● 2019年新卒で楽天株式会社に入社
   ● 主な技術領域はKubernetes, Ruby
   ● 趣味は競技プログラミング
   ● AtCoder赤色になりたい
   ● 競プロ仲間募集中です（切実）
   ● Twitter: @Erb_Owl
   2
   

   View Slide

3. 目次
   ● Dashboard as Codeって何が美味しいの？
   ● Grafana × Jsonnetでやってみる
   ● Dashboard as Codeの導入可能性
   3
   

   View Slide

4. Dashboard as Codeとは
   ● GrafanaやKibanaなどのDashboardの設定ファイルを
   ソースコードのように管理するプラクティス
   ● Dashboard as CodeはUI上で直接編集する場合と比較して
   どんな課題を解決するのだろう？
   4
   特にトレンドがあるわけではないみたい
   

   View Slide

5. UI上で編集する際の課題
   5
   内容・スタイルに
   一貫性を保てない
   誰でも編集することができる
   (権限管理はしたうえで)
   再利用性がない
   履歴・差分が追えないため
   編集・レビューしずらい
   履歴が残らない
   UI上で直接編集する場合の特徴
   Dashboardが乱立する
   そこから引き起こされる問題
   

   View Slide

6. UI上で編集する際の課題
   ● 内容・スタイルの一貫性
   ヘルスチェックのリクエストはクエリから除く？
   Nginxの499（クライアントからの切断）の扱いはどうする？
   エラー時は何色にする？
   ● 履歴や差分がわからず編集やレビューがしずらい
   誰が変更したかわからないので勝手に直せない
   ● Dashboardが乱立する
   既存のDashboardを理解し、編集するより作ったほうが早い
   新規の人はどのDashboardを見ればいいのかわからなくなる
   6
   

   View Slide

7. Dashboard as Codeはどう解決する？
   ● 一貫性の問題
   クエリやスタイルは変数や関数で再利用できるので一貫性を保ちやすくなる
   ● 履歴や差分がわからないので編集・レビューがしずらい
   ソースコードと同様にgitで管理するため、通常のコードと同等レベルで追えるように
   ● Dashboardが乱立する
   コードレビューのタイミングで必要なDashboardの認識を揃えることができる
   本当にDashboard as Codeが問題を解決するのかを手を動かしながら考えてみる
   7
   

   View Slide

8. 目次
   ● Dashboard as Codeって何が美味しいの？
   ● Grafana × Jsonnetでやってみる
   ● Dashboard as Codeの導入可能性
   8
   

   View Slide

9. Grafana × Jsonnet
   ● 今回はGrafanaのDashboardを例にして共通化を図っていく
   ● GrafanaのDashboardのデータはJSONで管理されているので
   少なくともJSONとしてはgit管理可能
   ● ただし、サイズの観点からJSONを直接管理するのは難しい（というか嫌だw）
   8枚のグラフからなるDashboardで1500行、1000プロパティで結構大きい
   ● そこでJsonnetというJSONのテンプレート言語を利用する
   9
   

   View Slide

10. Jsonnetとは？
    ● JSONに変数・関数・importなどの便利機能を盛り込んだテンプレート言語
    ● https://jsonnet.org/ で実際に動かしながら機能を確認することができる
    ● もちろん、JSONを最終的に出力することができれば良いので
    Dashboard as Codeを行う上ではシェルコマンドでもRubyでも構わない
    ● Jsonnetを使うことで比較的学習コスト少なくJSONを共通化することができる
    ● grafana/grafonnet-lib のような公式ライブラリを利用することができる
    ● JSON自体もJsonnetとして扱うことができるので既存のJSONを使うことも可能
    10
    

    View Slide

11. 今回作ってみるDashboard
    ● Nginxのパフォーマンスの変化を確認するためのDashboardで
    1行に14日前のグラフと、現在のグラフが横並びで表示されている
    ● 上記のRPSに加えて、latency、success rateのグラフも用意する
    （再利用できそうなパーツが発生するためのシチュエーションを作っています）
    11
    

    View Slide

12. Jsonnetによるアプローチ
    Jsonnetで共通化するにあたり3つのアプローチを考えてみました。
    実践的な例というよりは、DashboardをCodeのように管理するならどうなるかのイメージ
    のための例です。
    12
    意味重視 形式重視 折衷案
    

    View Slide

13. 意味重視のアプローチ
    ● grafana/grafonnet-lib というJsonnetのラ
    イブラリを利用することで右のように書
    ける（サイズの都合で省略あります）
    ● ライブラリ自体は非常にシンプルな作り
    でOpenAPIで書かれたJSONの仕様から生
    成されている
    ● プロパティが関数の引数になっていてデ
    フォルト値があらかじめ設定されている
    13
    addPanel(
    graph.new(
    ”nginx rps(current)",
    datasource=”Elasticsearch",
    )
    .addTarget(
    "query": "kubernetes.container.name:
    $containers"
    ),
    gridPos={
    x: 0,
    y: 0,
    w: 24,
    h: 3,
    }
    )
    

    View Slide

14. 形式重視のアプローチ
    ● JSONの意味を極力考えずに
    差分だけを記述するアプローチ
    ● グラフA、BのJSONの共通部分Cを取り出す
    ● グラフAと共通部分Cの差分を取り出す
    ● グラフA = C + AとCの差分
    ● GrafanaのJSONの意味を理解していなくても
    結果的に差分だけを記述することができる
    ● もともと複製して作成した図でなければ
    差分が大きいので共通化のメリットがなさそう
    14
    panels: [
    nginx_rps + {
    gridPos: {
    x: 0,
    },
    timeShift: '$before’,
    title: 'nginx rps($before ago)’,
    },
    nginx_rps + {
    gridPos: {
    x: 12,
    },
    title: 'nginx rps(current)’,
    },
    

    View Slide

15. 意味と形式の比較・折衷案
    ● 意味重視の方法だと元のJSONの仕様やライブラリの使い方を学ぶ必要がある
    ● 形式重視の方法だと元のJSONに含まれていた不要な項目が入ってしまうので、
    効率優先で目を瞑るか、適宜取り除いていく必要がある
    ● 最初から100%を目指さないやり方であれば、とりあえず意味を考えずに形式的な操作
    でJSONを整理して、徐々に無駄を削っていくという方法が良さそう。
    15
    

    View Slide

16. 目次
    ● Dashboard as Codeって何が美味しいの？
    ● Grafana × Jsonnetでやってみる
    ● Dashboard as Codeの導入可能性
    16
    

    View Slide

17. Dashboard as Code導入の代価
    No pain, no gain.
    ● Dashboardの生産スピードダウン
    ● JsonnetやJSONそのものに対する学習コスト
    ● JSONを反映させるパイプライン構築のためのイニシャルコスト
    後ろ2つはDashboardを更新する頻度が少なければ回収が難しい
    17
    

    View Slide

18. 段階的な導入の可能性
    0か1でDashboard as Codeに切り替えなくても規模・質的に段階を設けて導入できる
    規模：Dashboardのうちの一部だけをCodeとして管理する
    質 ：Codeとしての管理も最初から共通化を頑張らずに最初は素のJSONで管理して、
    徐々に共通化を図っていく
    18
    

    View Slide

19. 結論：贔屓目に見ても導入は難しい
    ● 学習やパイプライン構築の初期コストを考えると小さい規模だと割に
    合わなさそう。
    ● ライブラリなどを利用しても、JSON管理の難易度が高いので残念な
    がら現状は「運用でカバー」する方が軍配をあげそう。
    ● 事例自体見つからなかったので、成功事例を聞いてみたい。
    ● ただ、段階的な導入も可能なので部分的に取り入れるのはありかも。
    19
    

    View Slide

20. 参考資料
    ● https://grafana.com/blog/2020/02/26/how-to-configure-grafana-as-
    code/
    ● https://archive.fosdem.org/2020/schedule/event/grafana_as_code/
    ● https://grafana.com/docs/grafana/latest/best-practices/dashboard-
    management-maturity-levels/
    ● https://www.slideshare.net/SanoojManangat/dashboards-as-code-
    194359213
    20
    

    View Slide