ダッシュボードを活用したSLO運用やAPM活用

ツール導入前の課題

リリースして４ヶ月ほどの新規サービスFindy Toolsでは、規模も小さくベータ版であることや、当時の開発エンジニアも2人程度だったため、監視ツールは導入していなかった。

また、インフラとして使っているECSのメトリクスを確認したり、APMがなく、アラートの設定やSLOを策定した運用もしていなかった。

そのため、障害が発生した場合にもすぐに気がつける手段がなく、調査も大変な状況だった。

どのような状態を目指していたか

障害が発生した時に、アラートですぐに気がつけるようになることやSLOを策定し、レスポンスタイムなどを一定水準を保てるようになること。

また、障害時の調査がスムーズにできるようになり、結果的に復旧が早くなる状態を目指していた。

• APMに関してはSentry Tracingと比較し、Datadog APMを採用
• Error TrackingとSentry Issuesと比較したが、Sentry Issuesを採用

• 社内の導入事例
• 利便性
• 価格

• 社内で導入事例があったこと
• 関わるエンジニアが利用経験があり使い勝手は良いことを知っていたこと

改善したかった課題はどれくらい解決されたか

• 障害が発生した時に、アラートですぐに気がつけるようになった
• SLOを策定しユーザ向けのレスポンスタイムなどを一定水準に保てるようになった
• 障害時の調査がスムーズにできるようになった

DatadogのRubyのTrace gemである datadog/auto_instrument をRailsに導入したが、自動でTraceされるものが多すぎて、1リクエスト内でTrace Spanが大量にできていた。

そこで、Spanの時間が短いものはフィルタする設定を記述し、余計なTraceを送らないようにした。このフィルタの設定が細かく制御できるのは便利。

設定例

Datadog.configure do |c|
  Datadog::Tracing.before_flush(
    Datadog::Tracing::Pipeline::SpanFilter.new do |span|
      span.duration < 0.01.seconds
    end
  )
end