blipdrop

受信 URL

外部サービスの Webhook をそのまま受けます。URL を貼るだけで、認証のヘッダーは要りません。

POST https://api.nodd.blipdrop.net/in/{integration}/{inbound_key}

URL の発行

アプリのチャンネルの詳細で「連携を追加」を開き、連携の種類を選んで、Face ID で発行します。URL は発行時にだけ表示します。分からなくなったら失効して発行し直してください。発行できるのは Manager、Owner、Admin です。

URL そのものが秘密です。 漏れても承認は求められません。受信 URL はボタンの要らない通知だけを受けます。

種類

slackIncoming Webhook の形式です。text、なければ attachments[0].text、attachments[0].fallback を読みます。1 行目が見出し、2 行目以降が本文です。フォーム形式の payload= も読みます
grafanaGrafana の Webhook の連絡先です
alertmanagerAlertmanager の webhook_configs です
datadogDatadog の Webhooks 連携です。回復で解消します
sentrySentry の Internal Integration とアラートルールです。解消も連動します
pagerdutyPagerDuty の Generic Webhooks (v3) です。解消も連動します
genericPOST /v1/messages と同じ形式で、notice、progress、alert だけを受けます。approval と choice は 422 です

Datadog、Sentry、PagerDuty の URL は Nodd 1.1 以降のアプリで発行できます。

generic のURLは、アプリの「連携を追加 → 汎用Webhook」から発行します。認証ヘッダーを付けられないサービスから送るときに使います。

例

curl https://api.nodd.blipdrop.net/in/slack/nodd_live_i_... \
  -H "Content-Type: application/json" \
  -d '{"text":"デプロイ完了\nv2.4.1 を反映しました"}'
receivers:
  - name: nodd
    webhook_configs:
      - url: https://api.nodd.blipdrop.net/in/alertmanager/nodd_live_i_...
        send_resolved: true
curl https://api.nodd.blipdrop.net/in/generic/nodd_live_i_... \
  -H "Content-Type: application/json" \
  -d '{"kind":"alert","level":"high","title":"ディスクの残りが 5% です","alert_key":"disk.full:web-1"}'

Datadog

  1. アプリで Datadog の URL を発行します
  2. Datadog の Integrations で Webhooks を開き、新しい Webhook に URL を貼ります
  3. Payload に次の JSON を入れます
  4. モニターの通知の本文に @webhook-名前 を書きます
{"alert_id":"$ALERT_ID","scope":"$ALERT_SCOPE","title":"$EVENT_TITLE","message":"$TEXT_ONLY_MSG","transition":"$ALERT_TRANSITION","priority":"$ALERT_PRIORITY","url":"$LINK"}

回復の通知（Recovered）で、同じアラートを解消します。$ALERT_ID と $ALERT_SCOPE の組み合わせで、発火と回復を結びます。

Sentry

  1. アプリで Sentry の URL を発行します
  2. Sentry の Settings で Developer Settings を開き、Internal Integration を作ります
  3. Webhook URL に URL を貼り、Webhooks の Issue を有効にします
  4. アラートルールからも送るときは、Alert Rule Action を有効にして、ルールのアクションに選びます

Issue の作成で通知し、resolved で解消します。指標のアラートは critical で通知し、warning は normal にし、resolved で解消します。そのほかの知らせは 202 で受け取るだけで、通知しません。

PagerDuty

  1. アプリで PagerDuty の URL を発行します
  2. PagerDuty の Integrations で Generic Webhooks (v3) を開き、新しい Webhook に URL を貼ります
  3. イベントに incident.triggered と incident.resolved を選びます

incident.resolved で同じアラートを解消します。incident.reopened も選ぶと、再開も通知します。確認などのほかのイベントは受け取るだけで、通知しません。

Datadog、Sentry、PagerDuty の変換

種類すべて alert です
見出しDatadog は title、Sentry は Issue の title、PagerDuty はインシデントの title。120 文字で切ります
本文Datadog は message、Sentry は culprit、PagerDuty はサービス名。1,000 文字で切ります
重要度Datadog は Warn、Re-Warn、P3 から P5 が normal、ほかは high。Sentry は fatal、error が high、debug が low、ほかは normal。PagerDuty は urgency: low が normal、ほかは high
リンク発生元の URL が https なら 1 件付けます
alert_key, dedupe_key発火と回復が同じ値になるよう、サービスごとの ID から作ります

n8n、Zapier などの自動化ツール

応答が要らなければ、HTTP の処理から generic の URL へ送ります。応答が要るなら、送信キーで POST /v1/messages を呼び、GET /v1/messages/{id} をポーリングして結果を読みます。詳しくは API をご覧ください。

Grafana と Alertmanager の変換

種類発火は alert になり、status: resolved は同じアラートの解消になります
見出しラベルの alertname、なければ注釈の summary
本文注釈の description、なければ summary
重要度severity が critical、page、high、error なら high、info、low、none なら low、ほかは normal
項目alertname と severity を除くラベルを 6 件まで
リンクgeneratorURL、dashboardURL、panelURL のうち https のものを 2 件まで
alert_key, dedupe_keyfingerprint。使えなければラベルから導きます。発火と回復は同じ値になります

上限

← ドキュメント マニュアル サポート / FAQ English