Kibana AlertにおけるConnector (コネクター)とは

Posted at 2026-04-29

この記事はKibana Alertingについての連続記事の一部です。
Alertについての連続記事の一部です。

ConnectorとIntegrationの概念・保存形式・設定方法について解説します。

Connectorとは

Connector は、KibanaのActionが外部システムへ通知・操作を行う際に必要な接続設定を保持するオブジェクトです。外部サービスのAPIエンドポイント、認証情報（APIキー・パスワードなど）をConnectorとして一元管理することで、同じ接続設定を複数のRuleのActionから再利用できます。

ConnectorとActionの関係

Connector: 「どの外部システムへ」「どの認証情報で」接続するかを定義
Action: 「いつ」「どのような内容で」送信するかを定義

たとえば「Slackワークスペースへの接続設定」をConnectorとして作成しておけば、複数のRuleで同じConnectorを指定して異なるメッセージを送信できます。

スペース単位の管理

ConnectorはKibanaのスペース単位で管理されます。あるスペースで作成したConnectorは、他のスペースからは参照できません。スペースをまたいで共通のConnectorを使いたい場合は、後述のPreconfigured Connectorを利用します。

Connectorの保存形式

ConnectorはRuleと同じ .kibana_alerting_cases インデックスに、Saved Objectタイプ action として保存されます。

主要なフィールド：

フィールド	説明
`name`	Connectorの表示名
`actionTypeId`	Connector TypeのID（例: `.slack`、`.email`、`.webhook`）
`config`	接続設定（エンドポイントURL、オプションなど。平文で保存）
`secrets`	認証情報（APIキー、パスワードなど。暗号化保存）
`isMissingSecrets`	認証情報が未設定かどうか
`isPreconfigured`	`kibana.yml` で定義されたPreconfigured Connectorかどうか

認証情報の暗号化

secrets フィールドはKibanaの Encrypted Saved Objects という仕組みで暗号化されてElasticsearchに保存されます。暗号化にはKibanaの設定で指定する暗号化キー（xpack.encryptedSavedObjects.encryptionKey）が使われるため、暗号化キーなしにElasticsearchのデータから直接secrets（APIキーやパスワード）を読み取ることはできません。

主要なConnector Typeの設定方法

Stack Management > Alerts and Insights > Connectors から「Create connector」で新しいConnectorを作成できます。以下では代表的なConnector Typeの設定項目を説明します。

Slack

SlackへのメッセージをKibanaから送信するConnectorです。接続方法として Slack API と Slack Webhook の2種類があります。

Slack API（推奨）

設定項目	説明
API Token	Slack AppのBot User OAuth Token（`xoxb-` で始まる）

事前にSlack AppをワークスペースにインストールしてBot Token Scopeに chat:write を付与する必要があります。

Slack Webhook

設定項目	説明
Webhook URL	Slack Appの Incoming Webhook URL

こちらはWebhook URLを取得するだけで設定できるため手順がシンプルです。

Email

SMTPサーバー経由でメールを送信するConnectorです。

設定項目	説明
Sender	送信元メールアドレス
Host	SMTPサーバーのホスト名
Port	SMTPポート番号（通常587または465）
Secure	TLS/SSL接続を使用するか
Username	SMTP認証のユーザー名（認証が必要な場合）
Password	SMTP認証のパスワード（認証が必要な場合）

GmailやAWS SESなどのクラウドメールサービスを使う場合は、各サービスでSMTPアクセスを有効にしてアプリパスワードを発行する必要があります。

Webhook

任意のHTTPエンドポイントへリクエストを送信する汎用Connectorです。

設定項目	説明
URL	リクエスト送信先のURL
Method	HTTPメソッド（POST または PUT）
Headers	追加するHTTPヘッダー（例: `Content-Type: application/json`）
Authentication	認証方式（なし / Basic認証 / SSL証明書）
Username / Password	Basic認証の場合に指定

PagerDuty

PagerDutyのインシデント・アラートを作成・更新・解決するConnectorです。

設定項目	説明
API URL	PagerDuty APIのエンドポイントURL（デフォルトで設定済み）
Integration Key	PagerDuty ServiceのEvents API v2 Integration Key

Integration Keyは PagerDuty のサービス設定から「Events API v2」インテグレーションを追加することで取得できます。

Jira

Jiraプロジェクトにチケット（Issue）を作成・更新するConnectorです。

設定項目	説明
URL	JiraインスタンスのURL（例: `https://your-org.atlassian.net`）
Project key	チケットを作成するJiraプロジェクトのキー（例: `OPS`）
Email	Jiraアカウントのメールアドレス
API token	Jiraで発行したAPIトークン

APIトークンはJiraのアカウント設定（Profile > Security > API tokens）から発行できます。

Preconfigured Connector

Preconfigured Connector は、kibana.yml に定義するConnectorです。通常のConnectorと異なり以下の特徴があります。

全スペースで利用可能: スペースをまたいで使用できる
変更不可: KibanaのUIからは編集・削除できない（鍵アイコンで表示される）
Secrets不要のローテーション: 認証情報はkibana.ymlで管理されるため、UIからsecretsを再入力することなく設定変更できる

kibana.ymlへの記述例

kibana.yml の xpack.actions.preconfigured セクションに定義します。キーがConnectorのIDになります。

Webhook

xpack.actions.preconfigured:
  my-webhook:
    name: 'My Webhook'
    actionTypeId: .webhook
    config:
      method: post
      url: 'https://webhook.example.com/alert'
      headers:
        Content-Type: application/json
    secrets:
      user: 'webhookuser'
      password: 'webhookpassword'

Email

xpack.actions.preconfigured:
  my-email:
    name: 'Alert Email'
    actionTypeId: .email
    config:
      from: 'alerts@example.com'
      host: 'smtp.example.com'
      port: 587
      secure: true
      hasAuth: true
    secrets:
      user: 'alerts@example.com'
      password: 'smtppassword'

Slack（Webhook）

xpack.actions.preconfigured:
  my-slack:
    name: 'Slack Alerts'
    actionTypeId: .slack
    config: {}
    secrets:
      webhookUrl: 'https://hooks.slack.com/services/xxxx/yyyy/zzzz'

暗号化キーの設定

Preconfigured ConnectorのSecretsは kibana.yml に平文で記述されますが、Elasticの公式推奨としてkibana.ymlへのアクセス制御と、本番環境での設定管理ツール（Vault等）の活用を推奨しています。Kibana自体のEncrypted Saved Objectsとは別の仕組みで管理されます。

ConnectorのAPI

KibanaのDev Toolsから kbn: プレフィックスを使ってConnectorを操作できます。

Connector一覧の取得

GET kbn:/api/actions/connectors

スペース内のすべてのConnectorを返します。Preconfigured Connectorも含まれます。

Connector Typeの一覧取得

GET kbn:/api/actions/connector_types

利用可能なConnector Typeの一覧（ID・名前・必要なフィーチャーなど）を返します。

Connectorの作成

POST kbn:/api/actions/connector
{
  "name": "My Slack",
  "connector_type_id": ".slack",
  "config": {},
  "secrets": {
    "webhookUrl": "https://hooks.slack.com/services/xxxx/yyyy/zzzz"
  }
}

Connectorのテスト実行

POST kbn:/api/actions/connector/<connector-id>/_execute
{
  "params": {
    "message": "テスト通知"
  }
}

作成したConnectorが正しく動作するか確認する際に使えます。

Connectorの削除

DELETE kbn:/api/actions/connector/<connector-id>

Preconfigured Connectorは kibana.yml で管理されるためAPIからは削除できません。

IntegrationとConnectorの関係

Kibana AlertingのドキュメントではConnectorが接続する外部サービス（Slack、PagerDuty、Jiraなど）を Integration と呼ぶことがあります。

Integration: Kibanaと連携する外部サービス・プラットフォームそのもの
Connector: そのIntegrationへの接続設定

KibanaのUI上では Stack Management > Alerts and Insights > Connectors の画面がConnector（Integration接続）の管理場所となっています。

Elastic Agent / Fleet の「Integrations」との違い

Elastic Stackには同じく「Integrations」という概念がもう一つあります。Elastic Agent / Fleetの「Integrations」 はログ・メトリクスの収集設定（インプット）を指すものであり、Alerting ConnectorのIntegrationとは全く異なります。混同に注意してください。

	Alerting の Integration	Fleet の Integration
用途	アラート通知先の外部サービス	ログ・メトリクスの収集設定
管理場所	Stack Management > Connectors	Fleet > Integrations
例	Slack、PagerDuty、Jira	Nginx、AWS、Kubernetes

Elastic WorkflowsとAlertingの連携

Elastic Workflows は、複数のステップを組み合わせた自動化処理をYAMLで定義できるElastic Stackの機能です（https://www.elastic.co/docs/explore-analyze/workflows）。Elasticsearchへのクエリ・更新、AIによる分析・要約、ケースの作成、外部サービスへの通知など、多様なステップを組み合わせたワークフローを構築できます。

AltertingからWorkflowsを呼び出す

KibanaのAlertingルールのAction設定で、通常のConnector（Slack、Webhookなど）と同様に 「Workflows」 を選択できます。Ruleが発火したとき、選択したWorkflowが自動的に実行されます。

設定手順：

事前にElastic WorkflowsでWorkflowを作成・有効化しておく
Ruleの編集画面でActionsに「Workflows」を追加
ドロップダウンから実行したいWorkflowを選択
Action frequencyを設定する（通常のActionと同様）

Security Detection Rulesでも同じ手順でWorkflowsをActionとして設定できます。

Workflowsが受け取るアラートコンテキスト

Workflow実行時、Ruleが生成したAlertの情報が event フィールドを通じてWorkflowに渡されます。Workflow内でこのデータを使って次のような処理を自動化できます。

アラートの詳細情報をもとにしたエンリッチメント（追加データの付与）
アラート重要度に応じた通知ルーティング
ケースの自動作成と担当者の割り当て
LLMを使ったアラート内容の要約・解釈

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up