Help us understand the problem. What is going on with this article?

監視ツールのDataDogが便利だった

More than 3 years have passed since last update.

今更ですが、サービスで使ってみて便利だったので簡単にまとめます。
本家はこちら
https://www.datadoghq.com/lpg/

便利だった部分としては「メトリクスにタグを付けてドリルダウンで分析」とシンプルにここなんですが、諸々の設定とかも楽でした。

Datadogの概略

Datadogとは

サーバなどのモニタリングサービスをSaaS形式で提供してくれる。
ホストの監視はもちろんアプリ側からもユーザー動向等を飛ばしてログ化できるなど広くサポート。
グラフの描画が綺麗なのと、tagを使った多次元解析が便利です。

基本用語

Metrics

サーバーなど各種ホストから送られてくる情報。key value+タグの構造。とれるvalueの形式は限られている模様(参照:http://docs.datadoghq.com/ja/guides/metrics/ )

event

テキスト形式の監視状況等を伝える情報。タグ付け優先順付けコメントなどで、対応完了までをウォッチできる

Monitor

Metricsを監視し、dataがこない、閾値を超えたなどの情報をもとにeventやメールなどで通知を飛ばす。Chatworkなど外部サービスとの連携も可能

初期設定

サーバーへのインストール

agentをinstallするコマンドを管理画面から取得し、サーバー上で叩くとインストール・起動まで完了する
※トップ→Integration→Agentに行くと以下の様なスクリプトが準備されている

DD_API_KEY=xxxxxxxxx bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/xxxxx.sh)"

タグの付与

各サーバーごとにタグを付与し、タグごとにまとめてグラフ表示、モニタリングが可能。
運用では、必要に応じてAPIの役割ごとや、本番/Stageなどの環境ごとにタグをつけています

諸々の監視設定(例 サービスの死活監視設定)

サーバーのメモリ使用量などなど基本的なことはデフォルトでやってくれますが、
サービスの死活監視等をやりたいとなると設定が必要です。

例としてUnicronのプロセス監視の方法を載せてみます(もっといい方法があるのかもしれませんが。。)
Datadogのagent check機能を使い、Unicornのmaster process数を監視する
checks.d/api_unicorn.pyとconf.d/apiunicorn.yamlの2ファイルを作成し、dd-agentをリスタートする

/etc/dd-agent/conf.d/api_unicorn.yaml
init_config:

instances:
    [{}]
/etc/dd-agent/checks.d/api_unicorn.py
from checks import AgentCheck
import subprocess
class ApiUnicornCheck(AgentCheck):
  def check(self, instance):
    cmd = "ps aux | grep '[u]nicorn master.*xxxxxx' | wc -l"
    proc = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    out,err = proc.communicate()
    self.gauge('your.metrics.name', out)

dd-agentのリスタートすることで監視がスタートします
sudo /etc/init.d/datadog-agent restart

その他にも「ELB経由でのhttpアクセスの監視」などなど監視していますが、
設定は簡単でした。

その他

Datadogとchatworkの連携

chatworkと連携して、イベントを通知することもできます。
トップ→integrations→chatwork configure
ガイダンスに従って設定する
Room NameはDatadog内での呼び名。chatworkのroom名と一致している必要はない
Room idはchatworkのページurlの#!rid以降
例:https://www.chatwork.com/#!rid12345678 なら 12345678

今回便利だったこと

前置きが長くなりましたが、

Railsアプリであるモデルのafter_createでhas_manyのinstance数分だけsidekiqのプロセスが走って、値を集計するようなプログラムが有り、
どいつかわからんけど集計されていない(sidekiqのプロセスは死んでいない)ということがあったんですが、
Datadogのincrementログを仕込んで、必要情報はタグでペタペタつけていったら、
あとから分析が一発でした。
アプリ側のログ的な使い方もできるようです。

グラフはこんな感じで出せます
モザイクばかりでなんのことかわかりにくいですが、
対象のメトリクスに対して、tagで絞り込み、さらに別のtag毎にグラフを描画したりできます。
tagの絞り込みも複数で来たり表示の仕方もいろいろ選べるので、柔軟性が高そうです。

mdスクリーンショット 2016-02-04 17.02.20.png

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした