HTTPリクエストアクションは、イベントへのレスポンスでHTTPリクエストを送信します。このタイプのアクションにより、Splunk AppDynamics On-Premises で作成されたポリシーとサードパーティの HTTP API の統合が可能になります。

オンプレミスコントローラの HTTP/HTTPS プロキシを設定して、Web サーバーへのアクセスをフィルタリングできます。プロキシを設定すると、HTTP 要求アクションは、エンドポイントに応じて HTTP プロキシまたは HTTPS プロキシ経由でルーティングされます。「HTTP/HTTPS プロキシの設定」を参照してください。

HTTPリクエストテンプレートを使ってHTTPリクエストアクションを作成します。テンプレートは HTTP リクエストを記述するものであり、異なる HTTP 要求からでも Splunk AppDynamics アカウント内であれば再利用できます。

テンプレートを作成したら、コントローラUIのユーザーはそのテンプレートを使用するアクションを作成できます。ユーザーが [Create Action] ペインで [Make an HTTP Request] オプションを選択して [Configure Action] ペインにアクセスすると、テンプレートがオプションとして表示されます。

必要な権限

HTTP リクエストテンプレートを作成または修正するには、アカウントレベルの HTTP リクエストテンプレートの構成権限がユーザーに必要です。

HTTPアクションテンプレートへのアクセス

既存のテンプレートにアクセスするか、新しいテンプレートを作成するには、メニューバーで [Alert & Respond] をクリックし、次に [HTTP Request Templates] を選択します。

次のいずれかの操作を実行できます。

  • [HTTP Request Templates] リストから既存のテンプレートをクリックして、テンプレートを表示、編集、または削除します。
  • [New +] アイコンをクリックしてテンプレートを作成します。

HTTPリクエストテンプレートの作成または修正

テンプレートを作成または修正するときは、テンプレートの情報アイコンをクリックすると、構成の完了方法に関する情報が表示されます。 

テンプレートを作成したら、下にある [Save] をクリックしてテンプレートを保存します。

カスタムテンプレート変数

HTTPリクエストが送信されるときに、URLパスおよびペイロード内の値を置き換える変数を使用できます。for-eachループに対応しています。

テンプレートには、「定義済みのテンプレート変数」に記載されている定義済みの変数が用意されています。カスタムテンプレート変数を作成する前に、このリストを確認してください。利用したい変数がすでに定義されている場合があります。

定義済み変数ではすべてのニーズを満たせない場合、必要に応じてカスタム変数を構成することができます。定義済みの変数とカスタム変数の名前が同じ場合、テンプレートは定義済みの変数を使用します。

テンプレートは、Apache Velocity version 1.7を使用して変数を処理します。使用方法の詳細は『Velocity User Guide』を参照してください。

リクエストURL

Raw URLフィールドにリクエストのURLを入力し、プルダウンメニューからURLエンコードスキームを選択します。UTF-8とISO_8858-1 のみがサポートされています。Encoded URLが、送信する正しいリクエストであることを確認してください。

Request URL

認証

次のいずれかの認証タイプを使用して、サード パーティ アプリケーションに HTTP 要求アクションを送信できます。

  • 基本
  • OAuth 2.0
通信が暗号化されていない場合は、認証を使用しないことをお勧めします。

基本認証

  1. [Create HTTP Request Template] で、[Type] ドロップダウンから BASIC 認証タイプを選択します。
  2. 認証ユーザー名とパスワードを指定します。

OAuth 2.0 認証

  1. [Create HTTP Request Template] で、[Type] ドロップダウンから [OAuth 2.0] を選択します。
  2. 次のいずれかのオプションを使用して、アクセストークンを生成します。

クライアントクレデンシャル OAuth を使用してアクセストークンを生成するには、次の手順を実行します。

  1. 次を入力します。
    1. Token URL：トークンプロバイダーの URL。「サポートされているトークンプロバイダー」を参照してください。
    2. Client ID：承認に必要なクライアントの ID。
    3. Client Secret：承認に必要なクライアントの秘密キー。
  2. [Token] フィールドの横にある [Generate token] をクリックします。

この方法を使用してアクセストークンを生成すると、Splunk AppDynamics On-Premises は有効期限が切れたときに自動的にアクセストークンを更新します。



承認コード OAuth を使用してアクセストークンを生成するには、次の手順を実行します。

  1. 次を入力します。
    1. Token URL：トークンプロバイダーの URL。「サポートされているトークンプロバイダー」を参照してください。
    2. Client ID：承認に必要なアプリケーションの ID。
    3. Client Secret：承認に必要なアプリケーションの秘密キー。
    4. Redirect URL：承認後に OAuth サーバーによってユーザーがリダイレクトされるアプリケーションの URL。
    5. Auth URL：アプリケーションを承認する OAuth サーバーの URL。
  2. [承認（Authorize）] をクリックします。
  3. 承認コードを入力します。
    コードは、アプリケーションの承認後に OAuth サーバーによって提供され、トークンを生成するために必要です。この承認コードは、承認を承認した後に URL で使用できるようになります。
  4. [Token] フィールドの横にある [Generate token] をクリックします。

この方法を使用してアクセストークンを生成すると、Splunk AppDynamics On-Premises は更新トークンが利用できないか、有効期限が切れた場合に自動的にアクセストークンを更新できません。このようなシナリオでは、アクセストークンが期限切れになる前に、電子メール通知がアカウント所有者に送信されます。アカウント所有者は、前述の手順に従ってアクセストークンを手動で生成する必要があります。

承認コードフロー中に更新トークンを取得する方法については、トークンプロバイダーにお問い合わせください。

サポートされているトークンプロバイダー

Splunk AppDynamics では、次の OAuth 2.0 プロバイダーをサポートしています。

  • Atlassian
  • Dropbox
  • GitHub
  • Google
  • メタ
  • Okta
  • Pagerduty
  • ServiceNow
  • Spotify
  • Slack
OAuth 2.0 プロバイダーがサポートされていない場合は、Cisco AppDynamics サポートセンターにお問い合わせください。


カスタムリクエストヘッダー

HTTPリクエストのカスタムヘッダーを定義できます。カスタムリクエストヘッダーには、$(VARIABLE_NAME) のようにエンコードしたカスタムテンプレート変数または定義済みテンプレート変数を含めることができます。

すべての定義済み変数のリストについては、「定義済みのテンプレート変数」を参照してください。カスタムテンプレート変数を作成する前に、このリストを確認してください。詳細については、『Velocity User Guide』を参照してください。

ペイロード

ペイロードを HTTP リクエストに含めるには、ドロップダウンから MIME タイプを定義します。ペイロードは UTF-8 または ISO-8859-1 エンコーディングを使用してエンコードできます。 

レスポンス処理の基準

成功または失敗

成功または失敗のレスポンス処理の基準を指定しない場合、HTTPレスポンスはいつも成功になります。

そうでない場合は、次のようになります。

  • 失敗基準は成功基準より先に評価されます。失敗基準に適合する項目が見つかり次第、レスポンスは失敗と設定され、その後さらに失敗に適合する項目が見つかっても評価されません。
  • 失敗基準に適合する項目がない場合、成功基準が評価されます。

成功基準が設定されてない場合で過去にも失敗基準と適合していない場合、レスポンスはいつも成功になります。

そうでない場合は、次のようになります。

  • 1つでも成功基準を指定した場合、成功のレスポンスを得るには、成功基準に適合する必要があります。言い換えると、成功基準が設定されても、適合しなければレスポンスは失敗になります。

失敗および成功基準は、テンプレートに出現する順に評価されます。

ペイロードありの基準とペイロードなしの基準

同じステータスコードに異なる基準を設定できます。例えば、ペイロードのあるステータスの基準を成功と設定し、ペイロードのない同じコードの別の基準を失敗と設定することができます。

または、異なるコンテンツタイプのペイロードを持つ、同じステータスコードに異なる基準を設定できます。たとえば application/xml と application/xhtml+xml タイプのペイロードが成功の場合でも、他のタイプのペイロードで失敗する場合があります。

ペイロードのコンテンツタイプ

[Expect Payload] チェックボックスがオンになっている場合に表示される、リクエスト用のドロップダウンでペイロードのコンテンツタイプを指定できます。

コンテンツタイプが不明な状態でリクエストがペイロードを要求する場合、*/* を使用してすべてのコンテンツタイプを指定します。

この構成では、ステータスコードが 200 で XML ペイロードがある場合に成功のレスポンスが返されます。それ以外のコードでは、リクエストによって失敗のレスポンスが返されます。

Response Handling Criteria

イベントごとに1つのリクエスト

いくつもの個別のイベントや、別々に発生する同じイベントにより、同じHTTPアクションが呼び出される場合があります。

[One Request Per Event] 設定を使用すると、アクションによって HTTP リクエストをバンドルするかどうかを制御できます。

このチェックボックスがオフになっている場合、その時間枠内でアクションをトリガーしたイベントの数にかかわらず、HTTP リクエストは 1 分ごとに送信されます。これはデフォルトです。

このチェックボックスをオンにすると、イベントがトリガーするごとにリクエストが送信されます。イベントがアクションを10回トリガーした場合、すべてのイベントが1分間の間に起こったとしても、HTTPリクエストが10回送信されます。 

チケットを記録しようとしているのに、チケットシステムAPIでバルク作成がサポートされていない場合、イベントごとに1リクエストを送信（チェックボックスをオンに）すると良いでしょう。サポートされている場合は、単一のバルクリクエストを毎分行う（チェックボックスをオフにする）ことをおすすめします。

失敗時の再試行

HTTP リクエストを失敗した後に再送する場合、[Retry on Failures] オプションを選択できます。再試行の最大回数は 2 回です。

再試行メカニズムは、次の理由で HTTP アクションが失敗した場合に機能します。

  • CONNECT_TIMEOUT_EXCEPTION

  • CONNECTION_POOL_TIMEOUT_EXCEPTION
  • NO_HTTP_RESPONSE_EXCEPTION
  • JAVA_NET_SOCKET_EXCEPTION
  • JAVA_NET_CONNECT_EXCEPTION
  • テンプレートの [Failure Criteria] オプションで指定されたステータスコード

コントローラを再起動すると、再試行キューにあるすべてのイベントが削除されます。

イベントクランプの制限

[One Request Per Event] チェックボックスがオフで、トリガーとなるイベントのリストが長くなる可能性がある場合、アクションをトリガーしたイベントの応答への表示を制限することができます。クランプの制限は、最近 n 件のトリガーとなるイベントです。デフォルトの -1 は無制限を意味します。[One Request Per Event] がオンの場合、この設定は無視されます。

タイムアウトとリダイレクト

  • Connect Timeout：リクエストがサーバーに到達するまで待機する最長時間（ミリ秒）。
  • Socket Timeout：応答を受け取るまでに待機する最長時間（ミリ秒）。
  • Max Redirects：1 つのリクエストでリダイレクトできる最大回数。

テンプレートのテスト

テンプレートをテストするには、テンプレート構成の下側にある [Test] をクリックします。

テストの構成

[Template Test] 構成ペインで、テストに使用するテスト変数を指定します。この変数は、HTTP アクションが継続中に自動送信される、実際のリクエストで使われるものと異なる場合があります。

また、トリガーとなるイベントのタイプをテスト用に指定します。

ログレベルは [INFO] がデフォルトですが、[Log Level] ドロップダウンリストを使用して変更できます。

このサンプルテストテンプレート設定は、このアクションをトリガーする 3 つの POLICY OPEN CRITICAL イベントをシミュレーションしています。トリガーの追加が可能です。

HTTP Action Template Test

[テストの実行（Run Test）]

テストを実行すると、トリガー時にリクエストが送信されます。実行のトランスクリプションを受け取れます。

思い通りの結果が得られなかった場合は、実際にテンプレートを使用する前に、テンプレートのテスト構成または HTTP アクションテンプレート、あるいはその両方を修正する必要があります。

サンプル テンプレート

次のサードパーティ アプリケーションのテンプレート例：