Alertas para o espaço de trabalho

Administradores de espaço de trabalho podem configurar alertas de Configurações do sistema → Alertas de espaço de trabalho. As notificações estão desligadas até que um administrador salve um destino e os habilite. Cada espaço de trabalho tem seu próprio histórico de destino e incidentes.

Usar um público HTTPS endpoint aceitando JSON Pedidos POST. Endereços privados/locais, redirecionamentos, nomes de usuário/senha incorporados e fragmentos de URL são rejeitados. SubLane criptografa o destino, exibe apenas sua máquina e nunca o revela automaticamente. Deixe o URL em branco ao editá- lo para mantê- lo. Removendo o destino desabilita as notificações e apaga seu histórico de notificações pendente.

Condições

As verificações usam o estado local persistido aproximadamente uma vez por minuto; não enviam solicitações de modelo ou credenciais de assinatura de teste. O alerta de agrupamento original verifica a saúde da conta. Opcionalmente habilita os alertas de modelo e configura um limite de quota usado de 1- 99 (em branco o desactiva); ambos estão desligados por padrão. Só são avaliados modelos previamente observados e quotas novas. Observações desconhecidas ou não provam falha ou recuperação; a saturação de concorrência sozinho não ativa um alerta de modelo. Os instantâneos de improviso podem expirar, e as verificações não atualizam metadados. Uma descolagem limpa após um pedido bem sucedido ou a ação de recuperação de um administrador pode resolver um incidente de pool.

Entrega e recuperação

Um incidente inalterado envia uma notificação. Uma condição que limpa após o seu evento de disparo foi aceite envia uma resolved Evento. O estado do incidente sobrevive ao reinício. Falhas de entrega voltam a tentar após um minuto e depois recuam até 30 minutos; cada tentativa de passagem em no máximo dez entregas através da instância. Grandes filas pendentes podem levar passes adicionais.

O receptor deve retornar um status 2xx em cinco segundos. Desduplicar usando id, que também é enviado no Idempotency-Key header: um reconhecimento perdido ou um reinício entre a aceitação do receptor e a persistência local podem causar uma entrega repetida. Salvar configurações não envia nenhum teste. Após salvar um destino, explicitamente Enviar notificação de teste, mesmo com notificações desligadas. kind e status are test. Um teste por minuto é permitido em reinícios; as falhas não são repetidas e o estado do incidente está inalterado. A página de configurações exibe falha de entrega e o tempo de notificação mais recente aceito; salvar um URL sozinho não prova que funciona.

Evento de exemplo usando IDs sintéticos:

{
  "id": "11111111111111111111111111111111",
  "workspace_id": 1,
  "kind": "pool_unavailable",
  "subject": "2",
  "status": "firing",
  "observed_at": 1900000000
}

Uso de eventos de modelo model_unavailable, com ID de pool e ID de modelo nativo unidos por um cólon como seu assunto. quota_low, com uma identificação de conta como seu sujeito.

Apenas são enviados identificadores (incluindo o ID do modelo nativo para eventos de modelo), tipo de condição, estado e tempo de observação. Os nomes das contas, identidades de membros, chaves, URLs do webhook, prompts, respostas e erros brutos são excluídos. Este é um formato genérico do webhook; as aplicações de chat podem necessitar de um adaptador para o seu formato de mensagem.

Os backups incluem destinos criptografados e histórico de incidentes com a chave do cofre correspondente. Restaurar um instantâneo antigo pode reproduzir incidentes subsequentes, de modo que os receptores devem manter seu histórico de deduplicação.