トラブルシューティング: 何を見たいときに何を使うか

Wantedly のプロダクト開発チームは、ソフトウェア開発のライフサイクル全てにオーナーシップを持っています。これにより、ライフサイクルを通した学びのフィードバックがチーム内に蓄積し、全体が効率化することで、ソフトウェアの価値提供をより素早く行うことが可能になります。この考え方は Netflix によって Full Cycle Developers と呼ばれて広く知られています。

開発するシステムの運用にも責任を持っているということは、インフラエンジニア以外であってもシステムに問題が発生した場合に調査・解決する能力が求められ、いわゆる Embedded SRE のような能力や立ち振る舞いが必要となります。

本章では「こういう事象のときはまずここを見る」を逆引きの形でまとめます。各ツールの詳細な使い方は Honeybadger と Datadog を参照してください。

事象	まず見る場所
アプリケーションのエラーを調べたい	Honeybadger のプロジェクト画面
エラーが発生したリクエストの全体像を見たい	Honeybadger 詳細画面の「Context」欄にある datadogTraceUrl から Datadog Trace へ
特定の API / エンドポイントの遅さを調べたい	Datadog APM の Service Catalog
ALB のアクセスを Path / IP / UA などで集計したい	Datadog Logs (service:elb で絞り込み)、attribute が足りないときは BigQuery
DB のメトリクスを見たい	Datadog Dashboard DB Metrics
Redis のメトリクスを見たい	Datadog Dashboard Redis
Sidekiq のメトリクスを見たい	Datadog Dashboard Sidekiq
HPA (Pod のオートスケール) の状態を見たい	Datadog Dashboard HPA
BigQuery の Slot 使用率を見たい	Datadog Dashboard BigQuery
(D)DoS 攻撃を疑うとき・WAF 経由のリクエスト数を見たい	Datadog Dashboard Request Count (WAF)
Pod 内のプロセスごとのリソース消費を見たい (OOM 調査など)	Datadog Infrastructure: Processes
任意のメトリクスを時系列で確認したい	Datadog Metrics Explore
Dashboard では表現しづらい複雑な分析を作成・共有したい	Datadog Notebooks
fork した環境でエラーやトレースを追いたい	Datadog APM Traces で @fork-identifier フィルター