HTTPリクエストアクションは、イベントへのレスポンスでHTTPリクエストを送信します。このタイプのアクションにより、Splunk AppDynamics のポリシーとサードパーティの 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リクエストテンプレートの作成または修正

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

テンプレートを作成したら、下にある [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. [Type] ドロップダウンから [BASIC ] 認証タイプを選択します。
  2. 認証ユーザー名とパスワードを指定します。

OAuth 2.0 認証

OAuth 2.0 を使用する場合は、[Type] ドロップダウンから [OAuth 2.0] を選択し、次の 2 つのオプションのいずれかを使用してアクセストークンを生成します。

  • クライアントクレデンシャル OAuth
  • 承認コードOAuth

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

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

アクセストークンが [Token] フィールドに表示されます。この方法を使用してアクセストークンを生成すると、Splunk AppDynamics は有効期限が切れたときに自動的にアクセストークンを更新します。

承認コード 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. [Authorization Code] を入力します。
    コードは、アプリケーションの承認後に OAuth サーバーによって提供され、トークンを生成するために必要です。この承認コードは、承認を承認した後に URL で使用できるようになります。
  4. [Token] フィールドの横にある [Generate token] をクリックします。

アクセストークンが [Token] フィールドに表示されます。

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

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

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

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

  • Atlassian
  • Dropbox
  • GitHub
  • Google
  • メタ
  • Okta
  • Pagerduty
  • ServiceNow
  • Spotify
  • Slack


前述のプロバイダーのリストに加えて、既存の OAuth 2.0 プロバイダーを使用してトークンの生成を試すことができます。OAuth 2.0 プロバイダーがサポートされていない場合は、Cisco AppDynamics サポートセンターにお問い合わせください。

相互 TLS 認証

TLS 証明書をアップロードし、相互 TLS オプションを有効にして、Slack、PagerDuty、ServiceNow などのサードパーティ アプリケーションで Splunk AppDynamics コントローラを認証することもできます。この相互認証により、サードパーティ アプリケーションに送信されたアラート（HTTP リクエストアクション）が Splunk AppDynamics からのものであり、悪意のあるエンティティからのものではないことが確認されます。「相互 TLS 認証の設定と有効化」を参照してください。

デフォルトでは、相互 TLS 構成機能は、Account Owner ロールを持つコントローラテナント UI でのみ使用できます。カスタムロールを作成して、この機能を有効にすることもできます。ロールの詳細については、「カスタムロールの管理」を参照してください。

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

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

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

ペイロード

ペイロードを HTTP リクエストに含めるには、ドロップダウンから [MIME Type] を定義します。ペイロードは 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 オプションで指定された Status code

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

イベントクランプの制限

[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 アクションテンプレート、あるいはその両方を修正する必要があります。

サンプル テンプレート

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