一休.com Developers Blog

一休のエンジニア、デザイナー、ディレクターが情報を発信していきます

Datadog Log Management でアプリケーション稼働モニタリング

エンジニア

こんにちは。 システム本部CTO室のakasakasです。

今回は、Datadog Log Management を使ってアプリケーション稼働モニタリングをしている話をしたいと思います。

一休のモニタリング周りの話

Datadog Log Management とアプリケーション稼働モニタリングの話をする前に、一休でどのような監視をしているのか？という話を簡単にします。

一休ではDatadogをモニタリングツールとして使っています。 主な用途は2つあります。

  • インフラのリソースモニタリング
  • 外形監視

インフラのリソースモニタリング

インフラメトリクスのダッシュボードとアラートの設定は運用として乗っています。 具体的には、サービス（宿泊・レストランetc）毎のアプリケーションサーバやDBサーバのモニタリングをしています。

CPUで閾値を超えたら、Slack通知が飛び、エンジニアが対応するという形をとっています。

f:id:akasakas:20200111192017p:plain
インフラメトリクスのダッシュボード

f:id:akasakas:20200111192054p:plain:w500

外形監視

Datadog Synthetics API Tests を使って、外形監視をしています。 こちらも同様に、外形監視で異常が起きたら、Slackに通知が飛び、エンジニアが対応します。

f:id:akasakas:20200111192141p:plain
Synthetics API Tests

f:id:akasakas:20200111192211p:plain:w500

モニタリング観点で一休が抱えていた課題

インフラレイヤーでのモニタリングはできているが、アプリケーションレイヤーでのモニタリングはできていないというのが課題感としてありました。

ここでいうアプリケーションレイヤーでのモニタリングとは

  • 予約が正常にできているかどうか
    • エラーが多発してないか？
  • 予約通知メールが正常に送られているかどうか
    • メール送信件数が適切か？異常に多い、少ないということはないか？
  • 検索導線でのリクエスト数がどの程度あるのか？エラーがどの程度あるのか？

というサービスの状態がヘルシーかどうかという観点です。

※レイテンシーやエラーレートといったAPMとは異なります。Datadog APMは一部のサービスで運用しています。

これらを時系列で監視し(e.g. 10分毎の予約件数/1日ごとのメール送信件数) 異変があれば、アラートを飛ばすという仕組みがあれば、いち早く障害に気づけると考えました。

Datadog Log Management

このアプリケーション観点の監視をするために、Datadog Log Managementが有効だと考えました。

Datadog Log Management は Datadog 上でログを管理するサービスです。

一休では昨年ログ管理サービスをLogentriesからDatadog Log Management に完全移行しました。

導入方法や詳細な使い方は割愛します。

docs.datadoghq.com

Datadog Log Management を使って、アプリケーションログ・アクセスログをベースに時系列の予約状況・検索数の推移・メール送信件数etcを集計&ダッシュボードでグラフ化&アラートの設定ができれば、アプリケーション稼働モニタリングが実現できると考えました。

Datadog Log Management からダッシュボード作成

実際にDatadog Log Management から作成したアプリケーションモニタリングのダッシュボードがこちらです。

f:id:akasakas:20200111194244p:plain
宿泊スマートフォン予約状況

f:id:akasakas:20200111194316p:plain
宿泊PC・スマホ検索導線のアクセス推移とエラー状況

グラフの作成方法は

  • LogEvents を選択
  • タグで絞り込み

のみで、簡単です。

f:id:akasakas:20200111202201p:plain:w500

Datadog Log Management からアラート作成

予約状況の監視もアラートで検知することもできます。

f:id:akasakas:20200111200618p:plain:w500

New Monitor から Logs を選択し、検索クエリを指定すれば、Monitorが作成できます。

f:id:akasakas:20200111203513p:plain:w500

必要なメトリクスはカスタムメトリクスを作る

Datadog Log Management では取得できないメトリクスもあると思います。 その場合は、Datadog API を使って、カスタムメトリクスを作ります。

メトリクス API については下記をご覧ください。 docs.datadoghq.com

Datadog API を扱う際はRubyとPythonでそれぞれ API Clientがあるので、そちらを使うのがいいと思います。

GitHub - DataDog/datadogpy: The Datadog Python library

GitHub - DataDog/dogapi-rb: Ruby client for Datadog's API

カスタムメトリクスを作る例として、一休では検索にSolrを使っています。 SolrのIndex数を監視したいという場合は、SolrからIndex数を取得し、APIを使ってカスタムメトリクスを作成しDatadogに送信します。

具体的には下記のようなスクリプトをLambdaで定期実行するイメージです。

from datadog import initialize, api
import time
import requests

options = {
    'api_key': '<DATADOG_API_KEY>'
}

initialize(**options)

# Solrにリクエスト
r = requests.get('<Solr Endpoint>')

# Index数取得
index_count = r.json()['index_count']

now = time.time()

# Solrのindex数をカスタムメトリクスにして、Datadogに送信
api.Metric.send(metric="solr.index.count", points=(now, index_count), type="count")

カスタムメトリクスが作成できれば、Datadog上でダッシュボードとアラートが設定できます。

f:id:akasakas:20200114132046p:plain:w500
カスタムメトリクスから作成したSorのインデックス数

Datadog Log Management から取得できないが、監視したい項目については カスタムメトリクスを作るのもアリだと思います。

graph_snapshot API を使って、デイリーレポート

ただ、単純に

  • ダッシュボード作りました
  • アラート作りました

だけだと、せっかく作ったダッシュボードやアラートがエンジニアから忘れ去られそうという懸念がありました。

なので、「アプリケーションちゃんと動いているよ！エラーちょっと多いよ！」というのを伝える意味も込めて、デイリーレポートをslackに投稿するようにしました。

下記のようなイメージです。

f:id:akasakas:20200111193048p:plain:w500
アプリケーション稼働モニタリングのデイリーレポート

デイリーレポートをすることで、「エラーちょっと多いから確認した方がよくない？」みたいなことになり、調査&対応するという方向でエンジニアが動いてくれます。

f:id:akasakas:20200114155125p:plain:w500

これは graph_snapshot API を使って、キャプチャを作り、Slackに投稿するスクリプトをLambdaで日時で動かしています。

graph_snapshot API については下記をご覧ください。

docs.datadoghq.com

graph_snapshot API については細かいところを含めて、いくつか注意点があるので書いときます。

1.デフォルトの Rate Limitiing がけっこう厳しい

https://docs.datadoghq.com/ja/api/?lang=bash#rate-limiting に記載がある通り、

graph_snapshot API 呼び出しのレート制限値は、60/時間/Organization です。これは、オンデマンドで増やすことができます。

とあるので、無邪気にAPIを叩いていると、すぐに引っかかります。

2. graph_snapshot API のタイムゾーンがUTC固定

graph_snapshot API のタイムゾーンはUTCになっていて、任意のタイムゾーンに変更できません。

3. API リクエストで渡すパラメータがちょっと複雑

graph_snapshot API でグラフを作成する場合のAPIリクエストでJSONを扱う場合があるので、ちょっと面倒です。

DashBoardと同様のグラフを作りたい場合は、該当するグラフのJSONをリクエストにつめる必要があります。

f:id:akasakas:20200111232123p:plain

GitHub - DataDog/datadogpy: The Datadog Python library を使ったサンプル例が以下になりますが、JSONが長くなってしまうのが少し煩わしく感じるかもしれません。

from datadog import initialize, api
import time

options = {
    'api_key': '<DATADOG_API_KEY>',
    'app_key': '<DATADOG_APPLICATION_KEY>'
}

initialize(**options)

# Take a graph snapshot
end = int(time.time())
start = end - (60 * 60)
resp = api.Graph.create(
    graph_def='{\
        "viz": "timeseries", \
        "requests": [ \
            { \
                "q": "xxxxxxxxxxx", \
                "type": "bars", \
                "style": { \
                    "palette": "dog_classic", \
                    "type": "solid", \
                    "width": "normal" \
                } \
            } \
        ], \
        "yaxis": { \
            "scale": "linear", \
            "min": "auto", \
            "max": "auto", \
            "includeZero": true, \
            "label": "" \
        }, \
        "markers": [] \
    }',
    start=start,
    end=end
)

print(resp["snapshot_url"])

まとめ

今回は、Datadog Log Management を使って、アプリケーション稼働モニタリングを実現した話をしました。

単純なログ管理ツールとして使うだけでも、Datadog Log Management は便利ですが、 ダッシュボードやアラートなどを組み合わせることで、アプリケーションの状態が一目でわかるというのはいいと思いました。

最後に

Datadogのサポートの皆様にはいつも助けられています。 どんな問い合わせに対しても、いつも丁寧にサポート頂いているDatadogの皆様に御礼申し上げます。

Copyright© 株式会社一休®, All Rights Reserved.