Usando o Jabber para enviar mensagens de rede

Question

Precisamos enviar alertas de área de trabalho para vários usuários (conformidade, produção) em uma rede quando outros usuários enviaram conteúdo on-line para um relatório.

Atualmente estamos usando NET SEND, mas isso não tem garantia de entrega e provou não ser confiável tanto do ponto de vista do cliente quanto do servidor (e concluo que não será suportado em versões posteriores do Windows; atualmente estamos executando o XP).

Estamos considerando uma solução baseada em Jabber, mas alguém usou um cliente do Jabber para exibir mensagens de alerta na tela, como o NET SEND faz, em vez de simplesmente trazer uma janela de bate-papo para a frente ou exibir uma mensagem temporária 'brinde' perto da bandeja do sistema.

Precisamos que a mensagem de alerta seja persistente e seja descartada apenas pelo usuário, indicando que eles a viram. Os pop-ups ao estilo de torradas seriam bons desde que não fosse apenas por um tempo limitado e novamente tivessem que ser dispensados pelo usuário.

Alguma solução?

    

Answer 1

Temos algo parecido em casa. Usamos o cliente Miranda IM com os plugins notifyanything e popup.

Notifyanything permite que o cliente receba mensagens do udp em uma porta especificada. O pop-up faz exatamente isso, exibe a mensagem na janela na parte superior da tela do usuário.

No nosso caso, tudo está na rede interna, portanto a perda de pacotes UPD não é uma preocupação.

Aqui está um exemplo do script python que executamos para enviar as mensagens do udp dos servidores para os usuários:

#!/usr/bin/python

import socket, sys

hosts = (
  ('10.0.0.1',  15000),
  ('10.0.0.2',  15000),
  ('10.0.0.3',  15000),
)

def send(txt):
  s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
  for h,p in hosts:
    s.sendto(txt, 0, (h,p))
  del s

if len(sys.argv) > 1:
  s = "\n".join(sys.argv[-2:])
  send(s)

    

Answer 2

Eu me deparei com esse problema exato. O objetivo era entregar cada alerta ao longo de um caminho de escalonamento - enviando o alerta para a próxima pessoa na lista, se não fosse reconhecido em um determinado período de tempo. Determinamos que o Jabber era a melhor solução, mas para fazer isso corretamente, tínhamos que estender o protocolo ou investigar mais clientes. (O protocolo presta-se muito bem à extensão e há inúmeros clientes disponíveis). Esse problema foi porque frequentemente era desejável reconhecer alguns alertas, mas não outros.

Por exemplo. O caminho final de um alerta:

Send to admin A via Jabber.
No acknowledgement after 5 minutes, sent to admin B via Jabber.
No acknowledgement after 5 minutes, sent to admin A via SMS.
No acknowledgement after 5 minutes, sent to admin B via SMS.
No acknowledgement after 5 minutes, sent to admin A and B's manager via Jabber.
No acknowledgement after 5 minutes, sent to admin A and B's manager via SMS.
Manager evaluates the alert, acknowledge it or phones admin A or B.

O problema é que, se um segundo alerta for gerado no meio deste processo, o administrador A ou B pode desejar reconhecê-lo, mas não reconhecer o primeiro alerta. Por exemplo, se eles estiverem ocupados com um problema separado que gerou o outro alerta ou se não estiverem perto de um computador, saiba que o segundo alerta não é sério, mas que o primeiro alerta precisa ser tratado por alguém próximo a um alerta. computador e o mecanismo de escalonamento é a maneira mais eficiente de encontrar a pessoa certa.

Havia dois tipos de entrega de mensagens no Jabber. (Acredito que chamado normal vs chat) É possível que um dos dois tipos tenha permitido uma diferenciação na qual a mensagem foi respondida. Infelizmente, o tipo de mensagem que poderia ter permitido isso causou extrema inconveniência com os clientes que testamos se uma grande quantidade de mensagens foi recebida. (Também não tenho certeza se o teste das pessoas determinou se era possível realmente diferenciar o que estava sendo respondido, devido a esse problema sobrecarregar o teste).

Como era exploratório e não tivemos tempo de implementar uma solução completa, não determinamos se o problema era apenas escolher um cliente melhor ou se extensões ao protocolo eram necessárias. Eu ainda acho que o Jabber é o melhor método para entregar alertas. Para qualquer sistema de encaminhamento / entrega de alertas, uma pessoa que reconhece um alerta deve assumir a propriedade do alerta e deve haver repercussões para todos não reconhecerem um alerta. Isso tem que funcionar com o sistema, compreendendo a melhor maneira de alcançar uma pessoa, uma rotação de plantão, o risco de inundações de alerta, a emissão de alertas criados por uma pessoa que está atualmente fora da rotação e quaisquer considerações políticas causadas por um sistema de alerta que cria acidentalmente a responsabilidade se o sistema existente não possui nenhum.

    

Answer 3

Desculpe, esta não é uma resposta exata para a sua pergunta (sobre o Jabber), mas você pode querer verificar o ReachAlert.

link

Isso impediria as pessoas de corromperem a implementação do jabber, já que elas poderiam decidir usá-lo para outra coisa (conversando, enviando mensagens para outros usuários).

Também concordo com o envio de rede. Está indo embora e é uma prática comum desativá-lo, já que foi usado como spam.

Deixe-me saber o que você pensa e como vai; -)

    

Answer 4

Esta pode ser uma pergunta melhor sobre o Stackoverflow, mas parece que existem bibliotecas python e perl para o Jabber, então isso deve ser possível.

link

link

    

Answer 5

Usou o PSI jabber client. Tem notificações pop-up junto com notificações sonoras. O mesmo vale para o cliente jabber JAJC.

    

Answer 6

Acho que isso pode ser conseguido através de uma solução de monitoramento como o ZAbbix, você pode desencadear uma ação em qualquer evento remoto por script remoto, uma vez que a ação foi acionada, o Zabbix pode fazer escalações. As ações podem estar executando script remoto, enviando e-mail ou alertas via jabber até que o gatilho seja reconhecido.