9月14日に開催されるAutomated Diagnosticsウェビナーイベントに登録し、一般的なコンポーネントの一般的な診断方法と、すぐに始められるジョブテンプレートの提供方法について学びましょう。
今回は、PagerDuty Process Automationポートフォリオの一般的なユースケースであるAutomated Diagnosticsに関するシリーズの２回目です。
前回は、Automated Diagnosticsの基本について、また、Automated Diagnosticsを利用することで専門家へのエスカレーションを減らし、レスポンダーがより早くアクションを起こせるようにする方法についてお伝えしました。今回のブログでは、ユーザーにとって最も関係の深いコンポーネントの基本的な診断例について説明します。
しかし、その前に、前回の記事についてTwitterに寄せられた読者の声をもとに、Automated Diagnosticsが該当しないことを明確にしておきましょう。
- Automated Diagnosticsとアラート相関は異なります。 アラート相関は、指定された信号の深さと、相関のある信号を適切に識別できるエンジンに依存します。Automated Diagnosticsの目的は、第一レスポンダーが問題の原因を三角測量し、問題を迅速に解決するか、より正確にエスカレーションするかです。
- Automated Diagnosticsとモニタリングは別物です。 モニタリングは、パフォーマンスやアクティビティーにおいて望ましくない状態を特定することを目的としています。つまり、ほとんどのモニタリングは、第一レスポンダーのアクティビティーをエミュレートして真偽を確認したり、最初に取るべきアクションを特定したりすることを目的としていないのです。モニタリングは、アラートを上げることに重点を置いています。自動化された診断は、アラートが既に作成された後に、問題を修正する方法を決定することに重点を置いています。
とはいえ、Automated Diagnosticsでは監視ツールで収集したデータを利用することができます。ほとんどの人は、収集した全てのデータポイントに閾値を適用しているわけではありません。 実際、私たちがより一般的に使用している診断インテグレーションの１つは、CloudWatchのログ照会です。ログアグリゲーターを監視ツールと考えるかもしれませんが、純粋に問題を診断するために存在する監視ツールのデータを見ることが調査の最初のステップである場合もあるのです。
レスポンダーに自身の環境のオンデマンドまたは事前診断機能を提供することで、第一レスポンダーが原因を迅速に特定できるようになり、その結果、インシデントをサポートするために必要な人員を減らすことができます。通常、専門家でなければ取得できない「診断」データをレスポンダーに提供することで、トラブルシューティングのために多くの人員を投入する必要性が大幅に軽減されます。これにより、インシデントのコストを削減し、通常は手作業で行われる調査手順を自動化することで、平均応答時間（MTTR）を短縮することができます。
現状を把握する。インシデント対応の自動化
運用管理者は、自己回復や自動修復を可能にするというアイデアに期待することがよくあります。自動化によって解決を早めることは、「治療法を適用すること」と考えるのは自然な傾向です。しかし、多くの場合、「まったく同じインシデントは２つとない」という業界の理論が頭をもたげてきます。変動が大きい場合、自動化が実行される可能性が低くなるため、そのような自動化の価値は低下します。例えば、今日の問題を解決するためにコアサービスを再起動することは正しい方法かもしれませんが、明日には障害が連鎖し、さらに大きなインシデントにつながる可能性があります。
読者はここで、対応の初期段階に認知のギアを切り替えます。
しかし、非常に繰り返しが多くなる傾向があるのは何か、ご存知でしょうか。何が問題だったのかを診断し、何が起こったのかを判断するためにレスポンダーが行う調査手順そのものです。繰り返しが多いということは、自動化によって得られる価値も多いということです。例えば、Kubernetesディストリビューションでインシデントが発生したとします。インシデントの性質的にイメージリポジトリーかロードバランサーかを問わず、おそらくKubernetesログを引き出すという同じ診断ステップを取ることになるでしょう。
これらの診断手順はほとんどの場合、固定です。作業しているコンポーネントにより、発生したインシデントの優先順位は関係ありません。Automated Diagnosticsは、異なる種類のインシデントに適用できます。繰り返し発生する同種のインシデント専用に構築する必要はなく、一般的なコンポーネントのあらゆる種類と深刻度を対象に、お客様の環境に合わせてカスタマイズして適用することができます。これは、病院に行くようなものだと考えてください。特定の症状で緊急医療を受ける場合でも、年に一度の健康診断を受ける場合でも、診察室に入ってから体温、血圧、体重を測定します。
一般的な例
開発者の環境はそれぞれ異なりますが、一旦蓋を開けてみると、多くの環境は非常によく似ています。レスポンスの初期段階では、ほとんどの診断が３つの主要なデータソースから行われます。
- アプリケーションデータ
- システムデータ
- 環境データ
一般的な診断やコンポーネントは、レスポンス開始時に自動的に引き出される例がいくつかあります。これはレスポンダーがインシデントの重大性をよりよく理解するのに役立つだけでなく、レスポンダーが多くの専門家を巻き込みすぎて通常の業務を中断させないようにするのにも役立つでしょう。例えば、インシデント発生時にレスポンダーが使用するコンポーネントとしてKubernetes（k8s）を見てみましょう。k8s環境内でインシデントが発生した場合、この技術を維持するインフラエンジニアは通常、次のようなアクションを実行することになります。
- k8sのPodからテールログを取得する
- k8sからセレクターラベルでログを取得する
- イメージリポジトリーを確認する
- デプロイメントを記述する
- Podでコマンドを実行する
これらのアクションに共通することは、１つだけです。インシデントを受任した一般的なL1レスポンダーは、これらのアクションをどのように構成すれば良いのか分かりません。しかし、PagerDutyのAutomated Diagnosticsのすぐに使えるジョブがあれば、L1レスポンダーは自動的にこれらの診断を実行し、ジョブを実行することができます。
一般的な診断やアラートの例としては、以下のようなものがあります。
- CPU／メモリ消費型サービス
- よくあるアラート： CPU／メモリ使用率が高い
- よくある質問： どのサービスがCPUやメモリを消費しているか
- ファイルサイズ ／ ディスク消費量
- よくあるアラート： CPU／メモリ使用率が高い
- よくある質問： どのファイル／ディレクトリーが最も容量を消費しているか
- システムログ：Linux／Windowsコマンド
- よくあるアラート： サーバー／サービスの問題
- よくある質問： OSの問題か、アプリの問題か
- SQLデータベースコマンド
- よくあるアラート： データベースブロック／デッドロック
- よくある質問： 長時間稼働しているクエリーが他のデータベース要求をブロックしていないか
- ホストの可用性
- よくあるアラート： ホストの停止
- よくある質問： 実際にダウンしているのか、それとも誤検出による到達性の問題か
- アプリケーションのエラー：アプリケーションログまたはトレース
- よくあるアラート： 400／500エラーコード
- よくある質問： スタックトレースとは何か
既知の部品に対する一般的な診断のいくつかの例を示します。
- Cloudwatchのログ： 特定のアプリケーションとVPCのログを表面化させる。
- ECS： 停止したECSタスクのエラーを表示させる。
- ELB： 利用できないターゲットグループインスタンスをデバッグする。
- Kubernetes： Podsからセレクターラベルでログを取得する。
- Linux： サービスステータスを取得する。
- Nginx： エラーログを取得する。
- Redis： ログエントリーを低速にする。
また、これらはAutomated Diagnosticsソリューションガイドに掲載されている、ユーザーのために構築した30以上のすぐ使えるジョブテンプレートの一部に過ぎません。Automated Diagnosticsソリューションを使用するには、PagerDutyランブックオートメーションライセンスまたはProcess Automation（旧Rundeck Enterprise）ライセンスのいずれかが必要です。使用方法の詳細については、FAQを参照してください。どちらのライセンスもお持ちでない場合は、弊社までお問い合わせください。
PagerDuty内の診断の自動化
レスポンダーに通知されるインシデントには、アラートに対して「近視眼的な」見方をする監視ツールから提供される情報が多く含まれます。よくある例としては、CPU使用率の高さがアラートのトリガーとなり、レスポンダーに通知されるというものです。しかし、アラートに含まれる情報は表面的なもので、急増したCPUの原因が何であるかが特定されていません。
診断データ は、インシデントの「なぜ」「どこで」という質問に答えるのに役立つ、より深いレベルの情報です。モニタリングや相関ツールの中には、ユーザーに根本的な原因分析を提供するのに役立つものもありますが、そのほとんどは、異種のデータソースを統合ビューに照合するレスポンダーの調査／トラブルシューティングの手順をエミュレートする能力において不足しています。オンデマンドまたは事前実行の診断機能をレスポンダーに提供することで、最初のレスポンダーが自分で問題を解決する確率が高まり、インシデントを支援するための人員も少なくて済む可能性が高まります。Automated Diagnosticsの出番です。
使用するコンポーネントの一般的な診断についてもっと知りたいですか？PagerDutyのシニアソリューションコンサルタントのJustyn Robertsが登壇する9月14日に開催されるウェビナーイベントにご登録ください。Process Automationは初めてですか？デモをリクエストしてください。既にPageDutyのProcess Automationをお使いですか？Automated Dianosticsソリューションガイドをご覧になり、完全なソリューションを実現するためのエンドツーエンドプロセスをご確認ください。ご質問は、Twitterで@sordnamに直接ください。お話ししましょう。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：インテグレーション＆ガイド
