1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

NE株式会社開発統括部所属の大嶋(@atsusics) です。
この記事はNew Relic Advent Calendar 202217日目の記事になります。

概要

弊社では今年からサーバー監視ツールをNewRelicに切り替えました、その際にNewRelicの機能に合わせ監視設計見直しを行いました。その時に考えたことを紹介させていただきます。

前提情報

ネクストエンジン

弊社ではEC運営支援プラットフォームであるネクストエンジンを提供しています
このプロダクトは大きく分けると3つに分類することができます

  • メイン機能
    • ネクストエンジンで提供される基本的な機能
  • プラットフォーム
    • ログイン、サポート用の機能
  • 各種アプリ
    • 各種モール専用アプリ、効率化アプリなど

それぞれAWS上で稼働しており、アラート対応などについてはSREメンバーだけでなく、アプリケーションエンジニアと協力して対応しています。

以前の監視設計でもSlack通知する際のルールを決め設計していたが、運用していく中でいくつか課題が浮き彫りになってきました。
そこで、NewRelic導入のタイミングで再度監視設計をしました。

課題

  • 「アラートが鳴っている(Alert or Notify)」と「Alertチャンネルで鳴っている」がわかりづらかった
    • image.png
  • 要対応としていてユーザー影響が出るものをAlertチャンネルに通知するとしていたが、雑多なアラートが増え、さまざまなAlertチャンネルが乱立することで狼アラートの増加やSlackチャンネルの不参加による障害検知遅れの可能性が高まってきた
  • NewRelicでは閾値設定でCritical、Warningとなるので、Slackチャンネルとの紐付けわかりづらくなる恐れがあった
    • image.png
  • ユーザー影響がなく緊急性はないが、作業が必要なタスクが漏れてしまうこ恐れがあった

解決策

概要

プロダクトは大きく分けると3つに分類することができます

  • メイン機能
    • ネクストエンジンで提供される基本的な機能
  • プラットフォーム
    • ログイン、サポート用の機能
  • 各種アプリ
    • 各種モール専用アプリ、効率化アプリなど

としているので、通知も大きく3つに分け、それぞれに閾値criticalに対応したcritical_XXXX、閾値warningに対応したwarning_XXXXの合計6個のSlackチャンネルにアラート通知をするようにした。

また、

ユーザー影響がなく緊急性はないが、作業が必要なタスクが漏れる

を解決するために、弊社で採用しているタスク管理ツールAsanaにNewRelicから直接タスク作成するようにした。

概要図

image.png

次からは各項目について続けていきます

Slackチャンネル

それぞれの違いは以下に記載しています。
共通するのは温度感が違うにしても、対応が必要なものだけを通知している点です
すぐに対応が必要でないものはAsanaにタスクするようにしています

critical_XXXX

ユーザー影響が出ている場合に通知されるチャンネル
基本的には通知がならない(ようにしたい!)。逆に通知された場合は障害として最優先で対応する

参加者

  • エンジニア
  • カスタマーサクセスメンバー
  • 営業メンバー

といったエンジニア以外も参加

warning_XXXX

ユーザー影響が出ていないが何かしらの対応が必要な場合に通知されるチャンネル
通知されたら障害になる前にエンジニアが対応する

参加者

  • エンジニア

基本的にはエンジニアのみ参加+任意

Policy

以下4つを作成する

  • Asana
  • MainFunction
  • Platform
  • Apps

Condition

各Policy内にConditionを作成していく
基本的には本番環境のみを監視する。
AWSであれば、newrelic.cloudIntegrations.providerAccountName で絞っていく

以下2パターンがある

  • 閾値を1つだけ設定
    • Slack通知する場合はcritical_XXXXに通知されるので、1発でユーザー影響があるようなものの場合はこのパターン
    • Asanaにタスク追加するものもこのパターン
  • 閾値を2つ設定
    • 閾値warningを違反した場合はwarning_XXXXに通知される
    • 閾値criticalを違反した場合はcritical_XXXXに通知される
    • なので、閾値criticalはかなり厳しめに設定しておき、warningで問題を早めにキャッチアップし対応、本当にやばい時はcriticalで検知し障害として対応

Workflow

Slack通知

2(Critical,Warning)*3(Mainfunction,Platfrom,Apps)
=6個
の組み合わせで作成する

それぞれ、Policy(policyName)と閾値(priority)をフィルターに設定することで、特定のPolicy内の特定の閾値ごとに通知するSlackチャンネルを分けることができる

例:
image.png

Asanaタスク追加

PolicyをAsanaに絞り、webhookからタスク追加
(詳細は後日)
image.png

まとめ

NewRelicのCondition、Workflow等の設定項目から素直に監視設計したものを紹介させていただきました。
この記事が少しでも監視設計をする際に役に立てればと思っております。
またもし、もっと良い方法など知っている方はご教授いただけると嬉しいです!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?