Skip to content

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.

ModoStatus
NotificaçãoSuportado. Bot custom de grupo, assinado.
Ponte IMScaffold presente; suporte de produção adiado.

Payload

O bot custom do DingTalk aceita o formato padrão de mensagem de texto:

json
{
  "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:

text
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:

text
POST https://oapi.dingtalk.com/robot/send?access_token=…&timestamp=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

  1. No grupo DingTalk alvo → 群设置 → 智能群助手 → 添加机器人 → 自定义. Dê nome e avatar.
  2. 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.)
  3. Copie a URL do webhook — algo como https://oapi.dingtalk.com/robot/send?access_token=<token>.
  4. 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

AspectoDingTalkFeishu
Query / body assinadoQuery da URL (timestamp, sign)Campos do body (timestamp, sign)
Unidade do timestampMilissegundosSegundos
Chave de assinaturasecrettimestamp + "\n" + secret
Algoritmo HMACSHA-256SHA-256
Body vazio assinadoNã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.Message que cada Sender consome.