Dashboard as Code の夢と目覚め Keiichiro Seto 

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

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

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

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

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

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

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

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

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

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

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

意味重視のアプローチ ● 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, } ) 

形式重視のアプローチ ● 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)’, }, 

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

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

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

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

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

参考資料 ● 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