信頼できるデータベースアラートの作成方法

アラート疲労を軽減し、DBAが重要な事象に対応できるよう支援するデータベースアラートのベストプラクティス

ほとんどのデータベースチームが抱えているのは、アラートの問題ではなく、信頼性の問題です。ここでは、セッションで取り上げられたデータベースアラートのベストプラクティスについて概説します。このブログでは、データベースの専門家が優れたアラートの条件や、ノイズをシグナルに変える方法について解説しています。また、スロットリング、ダイジェスト、エスカレーションパス、ベースラインについても取り上げ、SolarWindsのツールがこれらをどのようにサポートしているかについても説明しています。

データベースのアラートに関するベストプラクティスは、ある単純な事実から始まります。それは、データこそがITにおける最も重要な資産であるということです。私がキャリアを始めたばかりの頃、大規模なシステム障害により、高価なサーバーがダウンしたことがありました。CIOはハードウェアの状態について尋ねることはなく、代わりに「私のデータはどうなったのか？」と尋ねました。だからこそ、DBAにとってアラートは極めて重要なのです。

私たちの多くは過剰なアラートに悩まされており、そのほとんどは対応を必要としません。しかし、アラート一つひとつに時間と注意を割かなければなりません。その結果、アラート疲労が生じます。ノイズに囲まれていると、重要なシグナルを見落とし始め、ミスが連鎖します。

この例ではSQL Serverを使用していますが、その原則はどのプラットフォームにも当てはまります。

データベースのアラートに関するベストプラクティスは、優れたアラートから始まる

アラートはモニタリングとは異なります。モニタリングはテレメトリデータを収集するものですが、アラートは対応を必要とするものです。私にとって、アラートとは「行動」そのものです。データベースのアラート設定におけるベストプラクティスは、シンプルな基準を定めています。各アラートは以下の条件を満たすべきです。この基準を満たさないアラートは、単なるノイズに過ぎません。例えば、SQL Serverは以前はバックアップが成功した際にも通知をしていました。しかし、私が知る必要があるのは、バックアップが失敗したとき、実行時間が長すぎる場合、あるいは完了しない場合だけです。

• ・有益であること。 次のステップに進むために必要な情報が得られること。
• ・実行可能であること。 あなた自身、あるいはスクリプトが、それに対して何らかの対応をとることができます。
• ・追跡可能であること。 何がアラートをトリガーしたのかを遡って確認できます。
• ・優先順位が明確であること。 今すぐ、1時間以内、あるいは翌朝までに、どのアラートに対応すべきかがわかります。
• ・決定論的であること。 同じ状況では常に同じアラートが発生します。

ノイズをシグナルに変える

注目すべきノイズもある。それは、集計して初めて重要になるのだ。

ログイン失敗が1、2回程度なら、パスワードの入力ミスに過ぎません。しかし、短期間に数千回も発生すれば、侵入の試みを示唆している可能性があります。同様に、SQLの構文エラーが数件程度なら正常範囲内ですが、急激に増加した場合はSQLインジェクション攻撃の兆候である可能性があります。

したがって、イベントごとに自分自身に通知を送る必要はありません。代わりに、優先度の低いイベントはログに記録し、経時的に追跡しましょう。そして、その件数が通常範囲を超えた時点でアラートを発信します。その時点で、ノイズはシグナルへと変わるのです。

アラート疲労を軽減するためのデータベースアラートのベストプラクティス6選

データベースアラートのベストプラクティスを実践すれば、事後対応から予防策への転換が可能になります。

1. メンテナンスウィンドウを活用しましょう。 毎月第1火曜日にパッチ適用を行う場合は、その時間帯にアラートを抑制し、終了後に再び有効にしてください。
2. 応答を制限しましょう。 CPU使用率が急上昇してもすぐに正常値に戻る場合は、アラートを送信する価値はありません。状態が、例えば3分から10分間継続する場合にのみアラートを送信してください。これにより、アラートストームも防げます。レプリケーションの障害が発生すると、数分の間に数千件ものメッセージが送信されることがあります。
3. 対応を必要としない通知はスキップしましょう。 代わりに、情報系アラートを集約してください。
4. ジョブの失敗についてはダイジェストを送信しましょう。 SQL Server Agentのジョブ失敗を一箇所に集約し、キューとしてまとめて確認します。
5. 特定のエラー番号に注目する。 多くの深刻なエラーは、シビアリティが高くない場合があります。たとえば、エラー 825 はストレージの問題を示す早期の警告です。私はシビアリティ 18 以上のアラートを有効にし、さらにエラー番号を追加しています。Microsoft は SQL Server Agent におけるシビアリティベースのアラート について文書化しています。
6. アラートの監査を行う。 私のチームは、およそ 6 ヶ月ごとにアラートを見直していました。発火しなくなったアラートを廃止し、他のアラートの優先順位を見直し、新しいアラートを追加していました。

必ず誰かが対応するようにする

アラートは、適切な担当者に届き、行動を起こすのに十分な情報が含まれていて初めて意味があります。多くのサーバーでは、GUI を使用するのではなく、アラートをスクリプト化してください。Azure SQL には SQL Server Agent がありません。そこで、Extended Events セッションを使用して、重大度 16 以上のエラーに加え、重要な低重大度のエラーも捕捉してください。

• 個別のメールアドレスではなく、配布リストを使用してください。 対応体制が、ある 1 人の休暇に左右されてはいけません。
• フェイルセーフなオペレーターを設定してください。 サーバーが過負荷でメールを送信できない場合でも、その事態を把握できるようにします。
• エスカレーション経路を構築してください。 重大なアラートに対して誰も時間内に確認応答しない場合は、管理チームへ、さらに経営陣へとエスカレーションします。
• 件名に必須情報を記載してください。 サーバー名、深刻度、エラー番号、およびメッセージの一部を含めます。午前3時であっても、それだけでベッドから起き上がるべきかどうかが判断できます。
• 初期対応を自動化しましょう。 アラートによって、sp_WhoIsActiveの出力を取得するジョブを実行できます。私の知るあるDBAは、ログドライブ上に5 GBの空のファイルを常時保持しています。ドライブが満杯になると、アラートがそのファイルを削除し、原因を修正するための時間を確保します。

固定のしきい値ではなく、ベースラインを使用する

CPU使用率が90%を超えるといった固定のしきい値は有用ですが、不完全です。サーバーの通常のCPU使用率が30%～35%の場合、突然10%に低下したことも重大な問題となります。私の環境では、これがルーターの故障を意味し、ある部門全体がサーバーにアクセスできなくなっていました。90%というしきい値では、この事態に気づくことは決してなかったでしょう。

「正常」が何であるかを知らなければ、異常を認識することはできません。したがって、ベースラインを構築し、正常値から1～2標準偏差といった逸脱に対してアラートを設定しましょう。月末にワークロードが変化する場合は、その期間用に別のベースラインを作成してください。