今日は「Redash Advent Calendar 2017」21日目の記事として，小ネタだけど，Redash で提供されているモニタリング用のメトリクスを紹介したいと思う．会社で Redash の活用が普及してくると，Redash の障害がビジネス的な影響に繋がる場合もあったりして（依存度が高すぎるのかもしれないけど），ツールとは言え，適切にモニタリングをしてあげる必要があると感じることが多い．Redash Ops も重要．

プロビジョニング

会社で運用中の Redash は AWS の AMI から起動しているけど，以下の3点だけは Chef でプロビジョニングを行っている．今回紹介するモニタリングの話に関係するのは Zabbix Agent の部分となる．

/opt/redash/.env の配布
Zabbix Agent のインストールと監視スクリプトの配布（合わせて jq もインストールしている）
PostgreSQL バックアップスクリプトの配布
- Redash を Backup & Restore する - kakakakakku blog

`/status.json` とは

Redash で提供されているモニタリング用のメトリクスは /status.json というエンドポイントになっていて，公式ドキュメントにも記載されている．1点注意点があり，メトリクスを取得できるのは管理者権限（管理者ユーザーもしくは admin グループに所属したユーザー）に限られる．よって，管理者権限を持っていればブラウザでも確認することができるけど，Zabbix などのツールと連携する場合は Get パラメータに api_key を付与する必要があり /status.json?api_key=xxx のようになる．

Ongoing Maintenance and Basic Operations · Redash Help Center

取得できるメトリクスの一覧は以下となっている（公式ドキュメントから抜粋）．正直言ってメトリクスは充実してなく，Redash / Python / PostgreSQL / Redis など，もっとメトリクスが増えると良さそう．他にどんなメトリクスがあれば良いだろうか．

{
    "dashboards_count": 30,
    "manager": {
        "last_refresh_at": "1465392784.433638",
        "outdated_queries_count": 1,
        "query_ids": "[34]",
        "queues": {
            "queries": {
                "data_sources": "Redshift data, redash metadata, MySQL data, MySQL read-only, Redshift read-only",
                "size": 1
            },
            "scheduled_queries": {
                "data_sources": "Redshift data, redash metadata, MySQL data, MySQL read-only, Redshift read-only",
                "size": 0
            }
        }
    },
    "queries_count": 204,
    "query_results_count": 11161,
    "redis_used_memory": "6.09M",
    "unused_query_results_count": 32,
    "version": "0.10.0+b1774",
    "widgets_count": 176,
    "workers": []
}

Zabbix でメトリクスを取得する

Zabbix の userparams を活用すれば，簡単にメトリクスを取得できる．具体的には以下のようなファイルを作成している．

UserParameter=redash.dashboards_count,           curl -s http://localhost/status.json?api_key=xxx | jq '.dashboards_count'
UserParameter=redash.queries_count,              curl -s http://localhost/status.json?api_key=xxx | jq '.queries_count'
UserParameter=redash.query_results_count,        curl -s http://localhost/status.json?api_key=xxx | jq '.query_results_count'
UserParameter=redash.unused_query_results_count, curl -s http://localhost/status.json?api_key=xxx | jq '.unused_query_results_count'
UserParameter=redash.redis_used_memory,          curl -s http://localhost/status.json?api_key=xxx | jq '.redis_used_memory'

すると，モニタリングできるようになるので，例えば，ダッシュボード数とクエリ数の推移から活用されている状況を把握することができる．query_results_count もクエリ実行の状況を把握するときに確認している．

f:id:kakku22:20171221025333p:plain

f:id:kakku22:20171221025345p:plain

System Status 画面

管理者権限（管理者ユーザーもしくは admin グループに所属したユーザー）を持っている場合，ヘッダー右側のメニューから「System Status」画面に遷移することができる．URL は /admin/status になる．ここに表示される値は，紹介した /status.json から取得されているため，最新データを確認するだけなら，この画面で十分と言える．

f:id:kakku22:20171221023502p:plain

（ハンズオン画面）

EBS BurstBalance

モニタリングの観点（AWS で Redash を動かす場合）だと，EBS タイプを気にする必要がある場合もある．既に Redash の知見をブログに多く書かれている id:ariarijp にお話を聞いたところ「クエリ結果を大量に書くようなユースケースだと gp2 の BurstBalance を使い切る場合がある」とのことだった．

Redashって意外と小さく始めることができて、たとえばAWS EC2のt2.smallでも環境や使い方によっては実用に困らない程度に動いてくれます。ただし、クエリ結果をDBに書くため、gp2 EBSのバースト食い切ってしまうことがあるので、たぶんMagneticにしたほうがいいです。
— Takuya Arita (@ariarijp) 2017年12月6日

とは言え，Magnetic を残しておきたくもなく，会社で運用中の環境では gp2 ( 30GiB で 100 IOPS ) を使っているけど，今のところ問題になったことはなく，未来のためにモニタリングをしているという感じ．Redash ガチ勢のユースケースだと gp2 では無理なのかも？

f:id:kakku22:20171221022614p:plain

Redis のメトリクスには注意する

現在 Redis のメトリクスで redis_used_memory が取得できるけど，これは redis-cli info から取得できる used_memory_human の値になっていて，単位付きの値になってしまっている．よって，メトリクスをグラフ化しにくく，困ってしまうので注意する必要がある．

そんな背景もあり，今年3月に redis_used_memory と redis_used_memory_human にメトリクスを分割したプルリクを出しているんだけど，今のところ取り込んでもらえていなく，どうしようー？という感じ．そこそこ多くリアクションももらえているのになー．あくまで暫定だけど，会社で運用中の Redash では，直接 redash/monitor.py を修正してモニタリングできるように対応している．

追記 : 2018/02/12 に Merge してもらった！

github.com