DingTalk
DingTalk 統合は今日 通知のみ（発火したアラートを DingTalk グループに プッシュ）です。IM ブリッジの双方向モードは計画中ですが出荷していません。 バリデーターは前方互換のため stream/webhook モードで dingtalk を受け 入れます。
| モード | ステータス |
|---|---|
| 通知 | サポート。カスタムグループボット、署名付き。 |
| IM ブリッジ | スキャフォールド存在。本番サポートは延期。 |
ペイロード
DingTalk のカスタムボットは標準的なテキストメッセージ形式を受け入れます：
{
"msgtype": "text",
"text": {"content": "[CRITICAL] node-01 swap_high\nswap_in_pages > 1000 for 5m\nsource: alert\ndedupe: alert:swap_high:device=7"}
}ボディ自体は未署名です。DingTalk は代わりに URL クエリパラメータでリクエスト を認証します —— 署名 を参照。
これは Feishu と WeCom 送信者が使うのと同じフラットテキストフォーマッタで、 formatText が生成します。
署名
カスタムボットが 加签 (signed) をオンにしていると、DingTalk はリクエスト が timestamp と sign の URL クエリパラメータを持つことを要求します：
timestamp = milliseconds since epoch
stringToSign = timestamp + "\n" + secret
sign = base64(HMAC-SHA256(key=secret, message=stringToSign))署名キーは secret のみ（Feishu と異なり、Feishu では secret が string-to-sign の一部）。 signDingTalkURL ヘルパーが両方のクエリパラメータを付加します：
POST https://oapi.dingtalk.com/robot/send?access_token=…×tamp=1717012345000&sign=…ボディはプレーン JSON のままです。署名済み URL + ボディが DingTalk の 認証対象です。
ミリ秒タイムスタンプを使ってください
DingTalk の署名は秒ではなく ミリ秒 を期待します。署名者は time.Now().UnixMilli() を使います。秒精度のタイムスタンプだと 310000「sign invalid」レスポンスが返ります。
セットアップ
- 対象 DingTalk グループで → 群设置 → 智能群助手 → 添加机器人 → 自定义。名前とアバターを設定。
- 安全设置 → 加签 を選んで secret をコピー（IP allowlist や keyword filter を代わりに選んでも構いません。Ongrid 送信者はどれもサポート しますが、署名モード推奨）。
- webhook URL をコピー —— こんな感じ：
https://oapi.dingtalk.com/robot/send?access_token=<token>。 - Ongrid で：Settings → Channels → New → Provider =
dingtalk→ Endpoint = webhook URL → Secret = ステップ 2 の署名 secret （keyword または IP allowlist モードを選んだ場合はスキップ）。
テストメッセージはグループの「安全」ルールに合致する必要あり
keyword filter を選んだなら、テストメッセージボディはそのキーワードを 含む必要があります。さもなくば DingTalk が拒否します。Ongrid のデフォルト テストメッセージは [INFO] Ongrid test です。マッチするキーワード （Ongrid で動きます）を設定するか、署名モードを選んでください。
クセ
at はサポートされていない
現在の送信者は純粋な msgtype: text を出荷します。特定ユーザーへの メンション（atMobiles / atUserIds / isAtAll）はまだペイロード ビルダーに入っていません。今日それが必要なら 汎用 webhook 経由で追加してください。ネイティブサポートは将来のエンハンスメントです。
4xx でのリトライは意図的
DingTalk はプロトコルレベルの失敗（署名ミスマッチ、メッセージ長すぎ、 ボットのレート制限）でも HTTP 200 を返し、JSON ボディに errcode を 入れます。送信者は 2xx を成功として扱い、非 2xx の HTTP ステータスコード のみを表面化します。ボットがサイレントに配信を停止したら、manager ログで dingtalk: send_text: code=… を確認してください —— Feishu と DingTalk は 「200 OK + ボディに errcode」の同じパターンを共有します。
DingTalk メッセージのレート制限
DingTalk はカスタムボットメッセージをボットあたり毎分 20 件にキャップ します。アラートパイプラインのダンピング（dedupe key ごとデフォルト 5 分）は通常これより十分下に収まりますが、高カーディナリティクラスタ ではより高いダンピングウィンドウかルールごとのチャネルルーティングが 必要かもしれません。
Feishu との比較
| 観点 | DingTalk | Feishu |
|---|---|---|
| 署名クエリ / ボディ | URL クエリ（timestamp、sign） | ボディフィールド（timestamp、sign） |
| タイムスタンプ単位 | ミリ秒 | 秒 |
| 署名キー | secret | timestamp + "\n" + secret |
| HMAC アルゴリズム | SHA-256 | SHA-256 |
| 空ボディ署名 | いいえ（sign は stringToSign 対象） | はい（HMAC メッセージが空） |
表面的に似た 2 つのプロトコル、3 つの実際の違い。まさにこの理由で、別個の Sender として存在します。