DingTalk

Интеграция с DingTalk сегодня — только notification (пушит сработавшие алерты в DingTalk-группу). Двусторонний режим IM-bridge запланирован, но не поставлен; валидатор принимает dingtalk в stream/webhook-режиме для forward compatibility.

Режим	Статус
Notification	Поддерживается. Кастомный group-бот, подписан.
IM bridge	Scaffold присутствует; production-поддержка отложена.

Payload

Кастомный бот DingTalk принимает стандартную форму text-сообщения:

{
  "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 query-параметры вместо этого — см. подпись.

Это тот же flat-text форматтер, который используют senders Feishu и WeCom, производимый formatText.

Подпись

Когда у кастомного бота включена 加签 (signed), DingTalk требует, чтобы запрос нёс URL query-параметры timestamp и sign:

timestamp    = milliseconds since epoch
stringToSign = timestamp + "\n" + secret
sign         = base64(HMAC-SHA256(key=secret, message=stringToSign))

Ключ подписи — только secret (в отличие от Feishu, где secret — часть string-to-sign). Хелпер signDingTalkURL аппендит оба query-параметра:

POST https://oapi.dingtalk.com/robot/send?access_token=…&timestamp=1717012345000&sign=…

Тело остаётся обычным JSON. Подписанный URL плюс тело — это то, против чего DingTalk аутентифицирует.

Используйте миллисекундные timestamp

Подпись DingTalk ожидает миллисекунды, не секунды. Signer использует time.Now().UnixMilli(). Timestamp точности секунд даёт ответ 310000 "sign invalid".

Настройка

1. В целевой DingTalk-группе → 群设置 → 智能群助手 → 添加机器人 → 自定义. Дайте имя и аватар.
2. Выберите 安全设置 → 加签 и скопируйте secret. (Вы также можете выбрать IP allowlist или keyword filter; sender Ongrid поддерживает любой из них, но signed-режим рекомендуется.)
3. Скопируйте webhook URL — выглядит как https://oapi.dingtalk.com/robot/send?access_token=<token>.
4. В Ongrid: Settings → Channels → New → Provider = dingtalk → Endpoint = webhook URL → Secret = signing secret из шага 2 (пропустите, если выбрали режим keyword или IP allowlist).

Тестовое сообщение должно соответствовать «safety»-правилу группы

Если вы выбрали keyword filter, тело тестового сообщения ДОЛЖНО содержать этот keyword, иначе DingTalk его отвергнет. Дефолтное тестовое сообщение Ongrid — [INFO] Ongrid test. Либо сконфигурируйте keyword, который соответствует (Ongrid работает), либо выберите signed-режим.

Особенности

at не поддерживается

Текущий sender отгружает чистый msgtype: text. Упоминание конкретного пользователя (atMobiles / atUserIds / isAtAll) не в payload- билдере. Добавьте через generic webhook, если вам это нужно сегодня; нативная поддержка — future enhancement.

Retry на 4xx намеренный

DingTalk возвращает HTTP 200 даже для protocol-level отказов (signing mismatch, message too long, bot rate-limited), с errcode в JSON-теле. Sender трактует любой 2xx как успех и поднимает только non-2xx HTTP status codes. Если бот молча перестаёт доставлять, проверьте лог manager на dingtalk: send_text: code=… — Feishu и DingTalk разделяют тот же паттерн «200 OK + errcode в теле».

DingTalk message rate-limit

DingTalk ограничивает сообщения кастомного бота 20 в минуту на бот. Дампенинг конвейера алертов (по умолчанию 5м на dedupe key) обычно остаётся хорошо ниже этого; кластеры с высокой кардинальностью могут требовать более широкое окно дампенинга или per-rule channel routing.

Сравнение с Feishu

Аспект	DingTalk	Feishu
Подпись query / body	URL query (timestamp, sign)	Поля body (timestamp, sign)
Единица timestamp	Миллисекунды	Секунды
Ключ подписи	secret	timestamp + "\n" + secret
HMAC-алгоритм	SHA-256	SHA-256
Подписано пустое тело	Нет (sign over stringToSign)	Да (HMAC message пустой)

Два поверхностно похожих протокола, три реальных отличия. Они существуют в отдельных Sender ровно по этой причине.

Связанное

• Webhook — для протоколов, которые Ongrid не говорит нативно (Wecom Mass app, Microsoft Teams, Mattermost, Rocket Chat, OpsGenie, PagerDuty…).
• Обзор каналов — единая форма notify.Message, которую потребляет каждый Sender.