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

ObservabilityとDatadogで実現したいこと

はじめに

この記事はDatadog Advent Calendar 2019の12/12分です。

DatadogのAdvent Calendarにお誘いいただいたので、誕生日にAdvent Calendar&Qiitaデビューしてみました。

今年はNoOps Meetupとか、AWS SummitとかTech-onとか、いろんなところで、入門 監視の話を聞いたので、この世界観を実現するには、PrometheusやStackdriverやDatadog何だろうなと漠然と思っていて、たまたま周りでDatadogを使っていて、ロゴの犬のTシャツが可愛いので、使い始めてみました。

と言っても、ぼく自身は世界観を語るだけで、構築そのものは他のメンバーにお任せなので、このQiitaでもDatadogで実現したいことについて書きたいと思います。

雰囲気で監視をやっていた

オンプレでの監視はサーバ、ネットワーク、OS、アプリケーションと各コンポーネントそのものの状態が正常かどうかを判断するだけで、サービスが正常なのかどうかを判断するのが難しかった。外部からのサービス監視や、アプリケーションのログ監視で何かが起きていることを把握することはできても、原因の特定や相関を見つける時なんて、個々のデータをExcelに貼り付けて時系列に並べるなんてことをやっていた。

そもそも、メトリクス、ログ、トレースもある程度システムにおけるボトルネックにあたりをつけて仕掛けないと必要な情報もとれていない。障害対応も、その後の報告のための資料作成、対策の検討も時間がかかる。

パブリッククラウドを使い始めてからも、監視対象は物理から仮想ホストに変わるだけで、ツールも同じZabbix。Datadogも使い始めたけれど、どうしても開発優先になってしまい使いこなせていない。CloudWatchやCloudWatch Logsにデータは集約されていても、アラームが上がって、どこで何が起こっているかは、メトリクスを順番に見ていかなければいけない。あの障害(素晴らしい振り返り)のときもそうだった。

そう、ぼくたちは「雰囲気で監視をやっていた」。

Observability

オブザーバビリティとは、システムが運用する上で必要な内部状態の情報を取得できる状態にあること。

YAMAGUCHI::weblog「オブザーバビリティ(可観測性)がなぜ必要だと考えるのか

運用する上で必要な内部の状態とは。
パブリッククラウドにおいて、インフラのメトリクスと睨めっこする必要性は減っているはずで、サーバレスで構築されることも増えてきていて、サービスが正常に稼働しているかどうか、サービスにどんな影響が生じているかどうかを知りたい。そこで何を取得するか。

SRE(Site Reliability Engineering)の説明のなかで、「意思決定にデータを用いる=人の主観で判断しない(雰囲気で判断しない)」というのがあって、そのSREで用いる「データ」というのが、SLI、SLO、SLA、そしてエラーバジェット。

SLI (Service Level Indicator)
システムの安定稼働、ビジネスの成功に必要な指標
SLO (Service Level Objective)
SLIの許容限界値
SLA (Service Level Agreement)
SLOを達成・未達の場合の規約(SLO+規約)
エラーバジェット
許容可能なエラー率(時間・範囲・レベル)

ビジネスの成功に必要な指標という定義があって、これまでのSLAだけを基準に障害か障害でないかを判断していたのとは大きく違っていたし、SLAがあっても少しのサービス影響も許さない、過敏な運用設計もまた過剰であった。
ビジネスが成功していることが見えて、システムが安定稼働していることもわかる、そんなメトリクスを取得・収集すること。それがオブザーバビリティ(可観測性)。

Datadogでできること

Datadogでの監視設計については、村主さんの12/2のAdvent Calendarでも紹介されていたMonitoring Modern Infractructureにほとんど書いてあるので、詳しくはそちらでということで、オブザーバビリティ観点で、Datadogで実現したいことを書いてみます。

  1. Sevice毎にタグを付ける
    サービス毎の相関が見られるようにメトリクスにタグを付けておく。

  2. Synthetics
    API Tests(外形監視)やBrowser Testで、APIのエンドポイント毎、エンドユーザー観点でサービスの安定稼働を確認。稼働状況をダッシュボードで表示。

  3. モニタリング対象
    ワークメトリクス、リソースメトリクス、イベント、APM、ログに分けて取得対象を整理する。
    APMやログは、DevOpsにおける開発メンバーへの迅速なフィードバックにも有効。

  4. SLOウィジェットでSLOに対するエラーバジェットの状況を可視化
    Syntheticsやモニタリング対象からサービスレベルを可視化。ビジネスが健全に提供できているかがわかる。

  5. ビジネスのKPIもSLIとして設定する
    DAUやMAU、連携先サービスへの送客数などをダッシュボードに表示し、ビジネスの状況も可視化する。

まとめ

今回は雰囲気で監視していたところから、モダンな監視に移行する際の考え方の違いと、オブザーバビリティとDatadogで実現したいことについて書いてみました。

アラートの緊急度の話なんかも、狼少年にならないようにするために、すぐに対応が必要なものとそうでないものを明確にすることも大事だし、ダッシュボードの設計についても、かなり奥が深いので、この辺りについても、考察を深めてみたいと思ってます。

モダンな監視も運用も開発も、サービスを、ビジネスを意識するとより同じ目線で語れるので、それがDatadogというツールを通じてよりチームが一体になれたらいいなと思ってます。

kddi
KDDIは、通信を中心に周辺ビジネスを拡大する「通信とライフデザインの融合」をより一層推進し、国内はもとよりグローバルにおいても、5G/IoT時代における新たな価値創造を実現し、お客さまの期待を超える新たな体験価値の提供を追求してまいります。
http://www.kddi.com
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