Datadog

Datadog は、主にインフラレイヤのミドルウェア (or 任意) のメトリクスを記録・観測するために使われています。また、メトリクスの変化を元に事前に決められたしきい値を超えたことを検出してアラートを発火させることも行っています。

「観測したい事象に対してどのツールを使えばよいか」については トラブルシューティング を参照してください。

使い方の基本

どの画面でも選択したパラメータが URL に追加されていくようになっており、実質パーマリンクとして機能します。このため、障害対応時に何かしらのメトリクスを観測したとき 自分の考察・解釈とは別に観測した事実として Datadog のスクショと URL を Slack や GitHub の Issue に貼り付ける ことを意識しています。

「メトリクス」は Datadog の基本的な観測単位で、それらを組み合わせて Dashboard や Notebook のような高度な観測が実現されています。以下は技術的な構成順に紹介しますが、エンジニアが日常的に見るのは Dashboard が中心です。

Metrics Explore

Datadog が記録しているメトリクスを絞り込んで時系列で表示する一番基礎的な機能です。Dashboard になっていなかったり、新しく追加したメトリクスはここで確認します。

Notebooks

Dashboard では表現しづらい複雑な分析 (Timeshift や Forecast などの関数を組み合わせたグラフなど) を作成・保存し、他人と共有するために使います。

Dashboards

グラフの配置が柔軟にでき、各グラフのパラメータの一括設定もできる、より高機能な Notebook のようなものです。すでに過去のインフラチームやエンジニアが、観測したいプロダクト・ミドルウェアごとに作成しています。おおよそ必要なものはすでに揃っているので、新しくプロダクトやミドルウェアを導入するなどしない限り、新規作成する機会は少ないです。

エンジニアは主に Dashboard 単位でメトリクスを観測します。よく見る Dashboard には以下があります。

DB Metrics

AWS の RDS (PostgreSQL) の各種メトリクスが観測できます。

BigQuery

Wantedly では BigQuery の定額プランを契約しているものの、同時に使えるリソース (Slot) は有限なので、それらのリソースを観測するために使います。BigQuery が重いと感じたら Slot を使い切っている可能性があるので確認してみるとよいでしょう。

Request Count (WAF)

WAF を通過した HTTP リクエスト数を可視化する Dashboard です。主に (D)DoS 攻撃を疑うときに、リクエスト数の急増や送信元 IP / Path / Host の偏りから攻撃の有無や規模を確認するために使います。

Infrastructure: Processes

Kubernetes の Pod (Container) 内で実行されているプロセス名 (コマンド) ごとに、CPU やメモリといったリソースの消費量が可視化できます。最近 OOM killer で殺されることが多いと感じたら、これでどの時間帯にどのプロセスがリソースを大量に消費しているのか調査できます。

APM

APM の Service Catalog から観測したいアプリケーションを選択して、エンドポイントごとのパフォーマンスや、リクエストのどの部分でどのくらい時間がかかっているか、どのマイクロサービスへリクエストが行われているかなどを確認できます。

自分が fork したリクエストのみ確認する

APM の Traces から、すべてのアプリケーションに対する trace を確認できます。ここで画像のように @fork-identifier フィルターを指定すると、fork したリクエストのみに絞ることができます。

fork については fork (internal) を参照してください。

話を聞きに行きたい

• Slack: #infra (internal)