Gmailは実際にダウンしていますか、それとも私だけですか？ HipChatとSalesforceはどうですか？ これらは、私のシステム管理者が聞くのにうんざりしていることを私が知っている質問です。 当社は、日常業務をサポートするために多くのクラウドサービスプロバイダーに依存しています。 そのため、同僚と私がオンザフライのコミュニケーションのためにHipChatにアクセスしたり、Salesforceにアクセスしてクライアント情報を追跡したりできない場合、TechOpsチームは、苦情が殺到する前に、問題の原因を特定するためにスクランブルをかけられたままになることがよくあります。
クラウドサービスプロバイダーがますますユビキタスになり、企業のシステムに不可欠な部分になるにつれて、LogicMonitorは、むらのあるサービスの可用性に関連する悪化の一部を軽減したいと考えていました。 これを行うために、私たちは提供を開始しました 内部サービスチェック 企業のアプリケーションやWebサイトのパフォーマンスの問題をすばやく特定するため。 これらのサービスチェックは次のように機能します。 コレクター 各オフィスまたはデータセンターにすでにインストールされている場合、指定された認証資格情報（ユーザー名、パスワード、エンドポイントドメイン）を使用して指定されたサイトまたはアプリケーションに定期的にアクセスを試みることにより、自動化されたエンドユーザーとして機能します。 コレクターがサービスに正常にアクセスできない場合は、すぐに通知されます。理想的には、実際のエンドユーザーが何か問題に気付く前に通知されます。
これらの内部サービスチェックは、アプリケーションの可用性に関するすべての問題にプロアクティブに対処するのに完全に適しているようです。 よくほとんど。 内部サービスチェック用のすぐに使用できる構成は、基本認証またはNTLM認証を使用するWebサイト/アプリケーションに最適です。 ただし、当社のサービスの多くには、動的トークンの存在を必要とする、より複雑なフォームベースのメソッドがあります。 この LogicMonitorチームに問題を提示しました：認証手段のXNUMXつが検証要求を発行した瞬間に作成された動的な値である自動サービスチェックを実行するにはどうすればよいですか？ LogicMonitorに合わせて ワンサイズはどれにも合いません 従来、私たちは、内部アプリケーションのそれぞれに合わせて調整できる、高度にカスタマイズ可能なサービスチェックのフレームワークを提供したいと考えていました。
新しくリリースされたものでこの課題に正面から向き合いました スクリプト内部サービスチェック、動的トークンの値をキャプチャして認証に渡すことができるGroovyベースの要求/応答スクリプトを記述できます。 定期的にスケジュールされたスクリプト内部サービスチェックを使用することで、TechOpsチームは可用性の問題に気をとられてしまうことを心配する必要がなくなり、問題が発生した場合は、同僚や私にサービス通知を積極的に投稿できます。
例としてHipChatを使用して、スクリプト化されたサービスチェックの特定の構造について詳しく見ていきましょう。 HipChatサービスチェックはXNUMXつのステップで構成され、各ステップには要求と応答のスクリプトが含まれ、後者は前者によって収集されたHTTP応答を解析する方法をLogicMonitorに指示します。 この基本的な形式は、プラットフォームで実行されるスクリプト内部サービスチェックの典型的なものです。
ステップXNUMX、リクエスト：
import staticcom.logicmonitor.service.groovyapi.PostDataType。*; import staticcom.logicmonitor.service.groovyapi.StatusCode。*; インポートcom.logicmonitor.service.groovyapi.StatusCode; インポートcom.logicmonitor.service.groovyapi.AuthType; インポートcom.logicmonitor.service.groovyapi.LMRequest; LMRequestリクエスト=新しいLMRequest（）; request.useHttp1_1（）。followRedirect（true）.needFullpageLoad（false）.get（）; LMHttpClient.request（request）;を返します。
ステップXNUMXのリクエストスクリプト（上記を参照）の目的は非常に単純です。GroovyAPIを使用して、の完全なHTTP応答をロードします。 https://hipchat.com/sign_in。 HTTP応答には、次のような形式のXSRFトークンが含まれます。
<input type="hidden" name = "xsrf_token" value = "1008991133" />
連続するResponseスクリプトを使用して、setContext（）APIコマンドを使用してトークンの値をキャプチャします。
ステップXNUMX、応答：
import staticcom.logicmonitor.service.groovyapi.StatusCode。*; インポートcom.logicmonitor.service.groovyapi.StatusCode; StatusCode status = STATUS_OK; 文字列本体= LMResponse.getBody（）; 結果=（body =〜/ xsrf_token（。+）\ / \> /）[0] [1]; result = result.replace（ '"'、 ''）; result = result.replace（ ''、 ''）; result = result.replace（ 'value ='、 ''）; LMResponse.setContext（ "token"、result）; ステータスを返します。
setContext（）コマンドは、キーが「トークン」として定義され、値が「結果」として定義されるキーと値のペアを作成します。これは、推移的に「結果=（body =〜/ xsrf_token（。+）\ / \> /）[0] [1]HTTP応答の」。
認証リクエストにトークンを入力する前に、一連のトークンを使用してトークンを再フォーマットする必要があります 結果.交換 XSRFトークンを囲む不要なスペースと文字を削除するためのコマンド。 これにより、トークンを分離し、その値を認証に渡すことができます。
ステップXNUMXがHipChatのログインページからHTTP応答を収集して適切に解析した後、認証プロセスを開始できます。 これでステップXNUMXに進みます。
ステップXNUMX、リクエスト：
import staticcom.logicmonitor.service.groovyapi.PostDataType。*; import staticcom.logicmonitor.service.groovyapi.StatusCode。*; インポートcom.logicmonitor.service.groovyapi.StatusCode; インポートcom.logicmonitor.service.groovyapi.AuthType; インポートcom.logicmonitor.service.groovyapi.LMRequest; パスワード= '## hipchat.pass ##'; トークン= LMHttpClient.getContext（ "token"）; LMRequestリクエスト=新しいLMRequest（）; request.useHttp1_1（）。followRedirect（true）.needFullpageLoad（false）.addHeader（ "Content-Type"、 "application / x-www-form-urlencoded"）。post（X_WWW_FORM_URLENCODED、 "signin = Log + in＆xsrf_token =" + token + "＆password =" + password + "＆email = sarah.tery％40logicmonitor.com"）; LMHttpClient.request（request）;を返します。
ステップXNUMXのリクエストスクリプトの主な目的は、ユーザー名、パスワード、XSRFトークンのXNUMXつの認証手段を使用してHipChatにログインすることです。 ベストプラクティスとして、LogicMonitorトークンを使用してこの情報をスクリプトに動的に入力できるように、パスワードをデバイス/サービスレベルのプロパティとして常に保存することをお勧めします。 このようにして、HipChatパスワードを ヒップチャットパス サービスプロパティ。 次に、前の手順で保存したXSRFトークンを取得するために、 getContext（） コマンド。ステップXNUMXで確立された「トークン」キーが入力されます。 setContext（）
ユーザー名とトークンを設定すると、これらの値をユーザー名（（[メール保護]）URL引数として確立されます：
"signin = Log + in＆xsrf_token =" + token + "＆password =" + password + "＆email = sarah.tery％40logicmonitor.com"）;
この時点で、HipChatへの認証に成功しました。 ログインページからのHTTP応答は、ステップXNUMXの応答ステージで評価されます。
ステップXNUMX、応答：
最終段階では、スクリプトから離れ、標準の設定構成を利用して以前のHTTP応答を評価しました。 設定構成で十分な場合は、サービスチェックの各段階でスクリプトを使用する必要がないことに注意してください。自由に組み合わせることができます。
このステップは、HTTP応答の本文に「ようこそ」が存在することを識別するように構成しました。 これは、HipChatへの認証に成功したため、アプリケーションが使用可能であることを示しています。
以下に示すテスト実行では、HTTP応答に文字列が含まれていることがわかります。 ようこそ、サラ。 HipChatが稼働しています！ 問題が検出されたときのあまり理想的ではないシナリオでは、TechOpsのチームの専用サービスダッシュボードにアラートが表示されます。
スクリプトを使用してサービスチェックを実行するということは、認証手段に関係なく、クラウドベースのアプリケーションを監視できることを意味します。 LogicMonitorでは、これにより、アプリケーションの可用性に対応する際の解決までの時間と内部プロセスが劇的に改善されました。 いつものように、時間とリソースを節約するために内部サービスチェックをどのように使用しているかを聞きたいので、LMアカウントの[フィードバック]ボタンをクリックして、考えや使用例を共有してください。
