モニタリングツールの統一に向けて

モニタリングツールがプロダクトやエンジニアごとにばらばらで、Mackerel、Cloud Monitoring、CloudWatch、New Relicが併用されていた。

また実際のモニタリングにおいてもダッシュボードを作り込むなどせず各ツールのデフォルトのものを見る事が多く、 その値が何を意味しているのかを理解しないまま見ていたため、モニタリングする意味を見いだせていなかった。

メトリクスデータの保存についても1年未満となっているものが多く、年周期での変動があるプロダクトにおいて昨年の状況が視えないというのは致命的でもあった。

そんな中SRE部が立ち上がり、まず可観測性を確保するところに着手しようということでo11yツールの統一にむけ動くこととなった。 o11yツールを移行するのは過去データ損失という大きなデメリットがつきまとうため、一度で決めたいという思いがあった。

• Datadog
• Mackerel
• (GCP)Cloud Monitoring / (AWS)CloudWatch

• メトリクスデータを分解能1minで保持できる期限の長さ
• グラフの表現方法（重ね合わせ、対数軸、グラフの種類）
• ダッシュボードの作りやすさ
• コンテナサービスを主につかった場合の金額のわかりやすさ

• ユーザ数とデータ量による計算となる、課金体系のわかりやすさ
  • Datadogはコンテナ系の金額計算が難しかった
• 選択した時間幅が含まれたショートカットリンク生成の容易さ
  • 情報共有時に便利なため
• メトリクスデータについては1min分解能で13ヶ月間保持
  • APMやログデータについてもData Plusを契約することで延長可能
• NRQLによる柔軟なデータ変形・演算

• o11yツールが全社的に統一できたため、同じ指標・同じ計測・同じ表現方法で複数のプロダクトを比較できるようになった
• SLOの初期設定がボタン一つと容易なため、「とりあえずSLO」を入れる事により日頃見る指標を少なくできる
• SQL-likeな言語であるNRQLを使うことで、柔軟なデータの重ね合わせが可能となる。SQLがわかる人であれば独自の集計を書く事も容易なため、各エンジニアが独自の視点を得ることができている

• プロダクト数が多く、その分GCP Projectも多かったためTerraformの構成・適用に時間がかかった
• モニタリングする文化が無かったため、何をどう見るかという基準づくりと、それに対応したダッシュボードの作成が大変だった
• APMなどの一部機能でデータを見るためにもフルプラットフォームユーザが必要なケースがあるが、全エンジニアに渡せるほど予算がないためユーザ配分に苦慮している

NRQLをつかった集計の柔軟さが大きなポイントです。「UI任せだと今ひとつ思い通りにならない」という課題があるのなら、検討してみる価値はあると思います。

また、2年ほど前はできなかったグラフの色指定・左右Y軸振り分けなどが可能となり、より表現の自由度が増えています。