Zabbix 3.2でsidekiqのキューなどを監視する - Amazon Linux編

前回の[Zabbix 3.2でsidekiqを監視する - Amazon Linux編](http://qiita.com/wapa5pow/items/538a982787f71b6ee49d)では、sidekiqのプロセス監視などをしましたが、sidekiqにどのくらいのキューがたまっているかなどは監視できていませんでした。

キューの数を監視することにより、キューの数が溜まっていたらsidekiqの処理能力が限界を迎えている可能性があるので、ワーカーの数を増やす必要があるので、重要な監視項目です。

# [Stats](https://github.com/mperham/sidekiq/wiki/API#stats)

sidekiqには監視APIがついており設定にもよりますが、`/admin/sidekiq/stats`のURLにアクセスすると以下のようなJSONが取得できます。

```json
{
  "sidekiq": {
    "processed": 166,
    "failed": 79,
    "busy": 0,
    "processes": 1,
    "enqueued": 0,
    "scheduled": 0,
    "retries": 0,
    "dead": 12,
    "default_latency": 0
  },
  "redis": {
    "redis_version": "2.8.23",
    "uptime_in_days": "310",
    "connected_clients": "42",
    "used_memory_human": "61.38M",
    "used_memory_peak_human": "65.63M"
  }
}
```

今回redisは監視しないですが、sidekiqの項目について以下に記します。

* processed: デフォルトで5年間のうちに処理したジョブの数が取得できます。5年だと多いので、1時間に処理した数とかに変えて自分で取得するのもよさそうです。
* failed: 同じく5年間でジョブが失敗した数
* busy: 現在実行されているジョブの数
* processes: 現在実行されているsidekiqのプロセス数
* enqueued: Queueに積まれているジョブの数(retriesとscheduledは含まない)
* scheduled: [Scheduled Jobs](https://github.com/mperham/sidekiq/wiki/Scheduled-Jobs)のジョブ数
* retries: ジョブ実行中に失敗した[Retries待ち](https://github.com/mperham/sidekiq/wiki/API#retries)のジョブの数
* dead: デフォルトで25回(`DEFAULT_MAX_RETRY_ATTEMPTS`)リトライした後に、まだ失敗していれば、sidekiqはジョブをDead Job Queueに入れます。そのDead Job Queueの数です。[ここ](https://github.com/mperham/sidekiq/wiki/Error-Handling#best-practices)と[ここ](https://github.com/mperham/sidekiq/wiki/Error-Handling#dead-job-queue)に詳細があります。
* default_latency: [ここ](https://github.com/mperham/sidekiq/issues/3003)によるとキューの最初につまれているジョブの積まれた時間と現在の時間との差です。要するに、ジョブがどのくらい実行されるまで待っていた時間です。

# 各監視項目の取得方法

JSONでレスポンスが帰ってくるのでjqでパースすることにします。なおjqは`yum install jq`でインストールできます。
以下のようにするとprocessedの値がとれます。その他は同じようにして取得できます。

```bash
curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.processed'
```

# Zabbixで監視項目に加える

まず、userparameterを作ります。

```
vi /etc/zabbix/zabbix_agentd.d/userparameter_sidekiq.conf

以下の項目を追加します。
UserParameter=sidekiq.processed,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.processed'
UserParameter=sidekiq.failed,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.failed'
UserParameter=sidekiq.busy,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.busy'
UserParameter=sidekiq.processes,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.processes'
UserParameter=sidekiq.enqueued,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.enqueued'
UserParameter=sidekiq.scheduled,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.scheduled'
UserParameter=sidekiq.retries,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.retries'
UserParameter=sidekiq.dead,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.dead'
UserParameter=sidekiq.default_latency,curl -s http://127.0.0.1/admin/sidekiq/stats | jq -r '.sidekiq.default_latency'
```

zabbixを再起動してキーの値がすべて取れるか確認します。

```
# 再起動
sudo service zabbix-agent restart

# 確認
zabbix_get -s 127.0.0.1 -k sidekiq.processes --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.failed --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.busy --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.processes --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.enqueued --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.scheduled --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.retries --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.dead --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
zabbix_get -s 127.0.0.1 -k sidekiq.default_latency --tls-connect=psk --tls-psk-identity=zabbix_agent --tls-psk-file=/etc/zabbix/zabbix_agentd.psk
```

前回作った`Template App Sidekiq Service`に上記の項目を加えていきます。
以下に例を示します。Triggerの値はプロジェクトによると思うので各自設定してください。
Enqueued、Retries、Default Latencyくらいを監視するのがよさそうです。

![Cursor_と_zabbix_conobie_jp__アイテムの設定.png](https://qiita-image-store.s3.amazonaws.com/0/30079/0ac21c34-75c0-cf85-54ff-65670e4392d8.png)

![Cursor_と_zabbix_conobie_jp__グラフの設定.png](https://qiita-image-store.s3.amazonaws.com/0/30079/2d0ebb53-d50e-274a-07cd-21750ead5e3d.png)

# テンプレートスクリーンの作成

テンプレートにスクリーンを作れる項目がありますが、こちらはマップをつくらないと、参照することができません。([ここ](https://twitter.com/ken_hikita/status/251570794390515714)にあるようにすごくわかりにくい）

![Cursor_と_zabbix_conobie_jp__スクリーンの設定_と_「Zabbix_3_2でsidekiqのキューなどを監視する_-_Amazon_Linux編」を編集_-_Qiita.png](https://qiita-image-store.s3.amazonaws.com/0/30079/94f7280b-aa29-8226-bb0c-3d1712cffebc.png)

上記のようなスクリーンを作ってから、マップをつくります。

マップは[監視データ]->[マップ]から作成できます。

![Cursor_と_zabbix_conobie_jp__ネットワークマップ.png](https://qiita-image-store.s3.amazonaws.com/0/30079/76b8623e-7126-9e15-51e0-21f06c4693c9.png)

上記のようにクリックしたらホストインベントリを選ぶとスクリーンが表示されます。[監視データ]->[スクリーン]からはいけないのですごく不便ですorz.. 

マップの変更は、マップ画面にて、右上のほうにあるマップ変更というボタンを押してやるのですが、以下のように適用を押してもポップアップ画面が消えないので、適用されたかわかりにくいです。（適用はされています）

![Cursor_と_zabbix_conobie_jp__ネットワークマップの設定.png](https://qiita-image-store.s3.amazonaws.com/0/30079/0be28ea9-1525-b153-81d0-6f8c492e2956.png)


# まとめ

上記の手順でZabbixのキューや実行までのレイテンシーが計測できるようになりました。
ジョブキューは時間によっては負荷が高くなったりするのでその際も正しく捌けているか確認するためにも監視は重要となってきます。