オンプレ×PagerDutyの相性は最高

前職はクラウド自動化ツールの会社にいたり、CloudNative Daysの運営をしていたりとクラウド系の人材だと思われがちな私ですが、実はオンプレ大好きです。

国内通信事業者でPaaSの開発をやっていましたので、インフラレイヤーからミドルウェアまで幅広く経験してきましたし、自宅にはvSphereを積んだおうちサーバークラスタと10GbEで組んだSANが動いています。

2023年のvExpertの受賞もしたりしました。

さて自分の話はこの辺にして。

クラウドばかりに注目が集まる昨今ですが、今後もオンプレは重要でありつづけます。むしろ、GartnerがNewオンプレミスという概念を発表するなどオンプレ回帰の動きもあるほどです。

Newオンプレミスでは、従来のようなハードウェアと仮想化基盤という要素だけでなく、Kubernetesのようなクラウドネイティブ技術やハイパーコンバージドインフラといった新しい要素までも積極的に組み合わせたスタックになります。これまでパブリッククラウドじゃないと出来なかったようなモダンでスケーラブルなアプリケーションをオンプレでも同じように実現出来ることになります。

しかしその分、運用しなければいけない技術の幅も深さも拡大していきます。クラウドであればベンダーに一任できる、サーバーやネットワークといったインフラレイヤーも自分たちで面倒をみる必要があります。

インフラに障害が発生すると、おそらく上に乗っているプラットフォームやアプリケーションも影響を受けるでしょう。その際、クラウドと同じノリでアプリケーションの監視をしていては、根本原因の解消に時間がかかってしまう可能性があります。逆にインフラの監視をしているだけでは、アプリケーションにどのような影響が出ているか判断できず、ビジネスに影響を及ぼしてしまうかもしれません。

それに対応するためには、上から下まで全てのレイヤーで適切な監視を行い、インシデント発生時には横串で対応ができるような仕組み作りが重要になります。

そこで、PagerDutyが役に立つのです。

PagerDutyで依存関係の管理

PageDutyはあらゆるツールからのイベントを受信でき、豊富なインテグレーションが提供されています。インフラの監視ツールはもちろん、仮想化基盤からのアラートやストレージからの通知などを、PagerDutyに対して送りつけるのです。

PagerDuty内ではBusiness Serviceという枠組みを定義することができ、それらに対してより細かな粒度のTechnical Serviceを定義して紐付けるほか、Business Service間の関係性も定義できるようになっています。

このあたりを活用してそれぞれの要素ごとに定義しておけば、先ほど書いた

インフラに障害が発生すると、おそらく上に乗っているプラットフォームやアプリケーションも影響を受けるでしょう。

といったところを視覚化して管理できるわけですね。詳しくは以下の記事を参照してください。

PagerDutyでvCenterのアラートを受け取る

今回は、vCenter周りをひとつのTechnical Serviceとして定義して運用する形を想定します。

PagerDutyにイベントを送信するにはEvent APIやWebhookなどのいくつかの方法がありますが、vCenterとの連携において追加のソフトウェアを入れることなく利用できるのはEメールを使う方法です。

PagerDuty側の設定

まずはServicesタブからService Directoryを選択肢、 +New Service を押して新たなServiceを作成します。名前は自由に付けられますので、分かりやすい名前をつけておきましょう。

Escalation PolicyやAlert Groupingの設定は本記事の内容と逸れるので割愛しますが、Motoさんが書いてくれている記事が参考になります

次にIntegrationの設定です。ここではEmailを選択してください。

作成が終わったら、Email integrationの画面で Integration Email のラベルでメールアドレスが記載されていますので、これを控えておきましょう。

vCenter側の設定

次にvCenter側の設定をしていきましょう。

vCenterにログインし、Inventryを表示します。そして、vCenter ServerをクリックしConfigure->Generalを開いたのち、EDITをクリック。

次にMailをクリック。ここでメールサーバーの設定が可能です。利用できるメールサーバーと、送信元メールアドレスを設定してください。

次に、Alerm Definitionsに移動します。ここでは、どのエラーが起きたときにどこにアラートを送るかを設定可能です。ものすごく多い(vSphere8では320個近くある)ので、まずは頻度が多く発生しているエラーについて設定を行うが良いでしょう。

今回は試験をかねて設定したいため、新たに独自のアラームを設定します。
ADDをクリックし、アラームを追加していきましょう。

今回はtestと名前を付けます。Target typeは気軽に起こせるものであれば何でも良いですが、今回はVirtual Machinesを選択します。

次にAlarm Ruleを設定します。IFのところで、VM powered offを指定します。これで、ゲストVMが再起動したらアラームが発動するようになります。
THENではShow as Criticalを指定してみましょう。試験ですしね。

そして重要なのが、Send email notificationsをONにすることです。ここで、SubjectとEmail toが設定出来るようになるので、Email toにPagerDutyのEmail Integrationのアドレスを入れます。

次に、Reset Ruleの設定もしてみましょう。これはvCenter側でアラームがGreenになった際に何のアクションをするかの設定です。ここでは、同様にPagerDutyへのIntegration Emailを設定しておきます。
IFのコンディションにはVM startingを指定しておきましょう。これで、VMが落ちたらアラームがRedに、起動したらGreenになります。

これで設定完了です。

テストしてみる

それでは何か適当なVMをPowerOffしてみましょう。vCenter上でアラームが発動し赤くなるはずです。

そしてPagerDuty側を見てみると、Incidentがトリガーされているはずです。

では、vCenter側で問題が解決したことを想定して、先ほどのVMを起動してみましょう。
vCenter側でのアラームが消え、しばらくするとPagerDuty側でもResolvedになっているはずです。

このように、vCenter側からメールでトリガーできるようになりました。

実験が終わったら先ほど作成したアラームを削除することを忘れずに。

おまけ

vCenterで設定出来るメールサーバーにSMTP認証は指定できないの？

PagerDuty関係なくvCenterの設定の話ですが、さきほどのメールサーバーの設定画面にはアドレスを入れる欄だけでポート番号や認証方法を設定する項目がありませんでした。

これはvCenterが古い仕様を引きずっていることが理由で、デフォルトでは認証無し、ポートは25番が使われます。
新しいvCenterであれば、Advanced SettingsからSMTP認証のユーザー名、オアスワード、ポート番号などを指定することが可能です。ですが、TLS周りの設定などはまだ無い様子･･･VMwareの公式ドキュメントにも、MS365を使う前提の説明になっており、利用できないメールサーバーも多そうです。

その場合は、ローカルにSMTP Relayサーバーを組んでそれ経由で送るのが良いでしょう。ちょっとめんどくさいですね

SNMPを使ってPagerDutyをトリガーできないの？

ZabbixやNagiosなどの監視ツールを間に挟んであげる形で実現できます

EmailじゃなくてEvent APIやWebhookでトリガーできないの？

VMware Event Broker Applianceを組み合わせることで実現可能~~でした~~です

~~Broadcomへの買収の影響か、Flingsが利用できなくなっておりVEBAもダウンロード方法が行方不明になっています･･･~~

ドキュメントにあるUse casesにもPagerDutyが挙げられています。

~~もし再度利用可能になったら説明記事を書いてみる予定です。~~

12/16追記

gowatanaさんから、VMware Technology Networkから入手可能と教えて貰えました！

今後は、VMware以外にもオンプレ環境で利用されるプロダクトとPagerDutyの組み合わせを紹介していければなと思ってます。

では、今日はこのへんでおしまい