DingTalk
A integração DingTalk é somente notificação hoje (push de alertas disparados para um grupo DingTalk). O modo two-way da ponte IM é planejado mas não distribuído; o validator aceita dingtalk em modo stream/webhook para forward compatibility.
| Modo | Status |
|---|---|
| Notificação | Suportado. Bot custom de grupo, assinado. |
| Ponte IM | Scaffold presente; suporte de produção adiado. |
Payload
O bot custom do DingTalk aceita o formato padrão de mensagem de texto:
{
"msgtype": "text",
"text": {"content": "[CRITICAL] node-01 swap_high\nswap_in_pages > 1000 for 5m\nsource: alert\ndedupe: alert:swap_high:device=7"}
}O body em si é não-assinado. O DingTalk autentica a requisição via parâmetros de query da URL em vez disso — veja assinatura.
Esse é o mesmo formatter de texto plano que os senders Feishu e WeCom usam, produzido por formatText.
Assinatura
Quando o bot custom tem 加签 (signed) ligado, o DingTalk exige que a requisição carregue um parâmetro de query timestamp e sign na URL:
timestamp = milliseconds since epoch
stringToSign = timestamp + "\n" + secret
sign = base64(HMAC-SHA256(key=secret, message=stringToSign))A chave de assinatura é o secret apenas (diferente do Feishu, onde o secret é parte do string-to-sign). O helper signDingTalkURL anexa ambos os query params:
POST https://oapi.dingtalk.com/robot/send?access_token=…×tamp=1717012345000&sign=…O body fica como JSON puro. A URL assinada mais o body é o que o DingTalk autentica contra.
Use timestamps em milissegundos
A assinatura do DingTalk espera milissegundos, não segundos. O signer usa time.Now().UnixMilli(). Um timestamp em precisão de segundo dá uma resposta 310000 "sign invalid".
Configuração
- No grupo DingTalk alvo → 群设置 → 智能群助手 → 添加机器人 → 自定义. Dê nome e avatar.
- Escolha 安全设置 → 加签 e copie o secret. (Você também pode escolher allowlist de IP ou filtro de keyword; o sender Ongrid suporta qualquer um deles, mas o modo signed é recomendado.)
- Copie a URL do webhook — algo como
https://oapi.dingtalk.com/robot/send?access_token=<token>. - No Ongrid: Settings → Channels → New → Provider =
dingtalk→ Endpoint = a URL do webhook → Secret = o secret de assinatura do passo 2 (pule se você escolheu modo keyword ou IP allowlist).
A mensagem de teste precisa casar com a regra "safety" do grupo
Se você escolheu filtro de keyword, o body da mensagem de teste PRECISA conter essa keyword ou o DingTalk rejeita. A mensagem de teste padrão do Ongrid é [INFO] Ongrid test. Ou configure uma keyword que case (Ongrid funciona) ou escolha modo signed.
Pegadinhas
at não é suportado
O sender atual distribui msgtype: text puro. Mencionar um usuário específico (atMobiles / atUserIds / isAtAll) não está no builder de payload ainda. Adicione via o webhook genérico se precisar hoje; suporte nativo é um enhancement futuro.
Retry em 4xx é intencional
O DingTalk retorna HTTP 200 mesmo para falhas de nível de protocolo (sign mismatch, mensagem longa demais, bot com rate-limit), com um errcode no body JSON. O sender trata qualquer 2xx como sucesso e expõe apenas códigos HTTP não-2xx. Se o bot silenciosamente para de entregar, cheque o log do manager por dingtalk: send_text: code=… — Feishu e DingTalk compartilham o mesmo padrão "200 OK + errcode no body".
Rate-limit de mensagem do DingTalk
O DingTalk limita mensagens de bot custom a 20 por minuto por bot. O dampening do pipeline de alerta (padrão 5m por dedupe key) geralmente fica bem abaixo disso; clusters de alta cardinalidade podem precisar de uma janela de dampening maior ou roteamento de canal por rule.
Comparação com Feishu
| Aspecto | DingTalk | Feishu |
|---|---|---|
| Query / body assinado | Query da URL (timestamp, sign) | Campos do body (timestamp, sign) |
| Unidade do timestamp | Milissegundos | Segundos |
| Chave de assinatura | secret | timestamp + "\n" + secret |
| Algoritmo HMAC | SHA-256 | SHA-256 |
| Body vazio assinado | Não (sign é sobre stringToSign) | Sim (mensagem HMAC é vazia) |
Dois protocolos superficialmente similares, três diferenças reais. Existem em Senders separados exatamente por isso.
Relacionado
- Webhook — para protocolos que o Ongrid não fala nativamente (app Wecom Mass, Microsoft Teams, Mattermost, Rocket Chat, OpsGenie, PagerDuty…).
- Visão geral dos canais — o formato unificado
notify.Messageque cada Sender consome.