@Laci Mészáros @Fabien Wernli Thanks for your reply. You really inspired me. I thinks I should make the new Websocket Destination support two mode in its configuration 1) client mode Just send the log message to another Websocket Server 2) Server mode The new WebSocket destination itself serves as a Websocket Server. It has a log messages buffer. The log messages send to the destination are stored in the buffer (If the buffer is full then the oldest message is overrided). Then other WebSocket clients(Such as a web browser) can directly connect to the Websocket Server to subscribe the messsage. This is the pub-sub communication that @faxmodem and @Fabien mentioned. Then I plan to define some syntax that the WebSocket destination can understand to filter the log message. So the WebSocket Client can send its filter definition and get the logs it want from the new WebSocket destination. What do you think about this idea? Any suggestions? 2016-03-16 22:25 GMT+08:00 Fabien Wernli <wernli@in2p3.fr>:
Hi,
On Wed, Mar 16, 2016 at 08:31:47AM +0800, Yilin Li wrote:
1) WebSocket support two-way communication. However, I found only one-way communication will be used in the project Idea. If this destination will be used for alerting, what are the advantages of using Websocket? Is it mainly for supporting another new protocol or better performance of WebSocket ?
As I previously said [1] I think it would be great to have a subscription mechanism, so the client would sent its filter definition (e.g. `program(sshd)`) and the destination would send it the logs that match this filter.
But maybe this is out of scope?
[1] https://lists.balabit.hu/pipermail/syslog-ng/2016-February/022686.html
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
-- Thanks, Yilin Li -- Institute of Software Chinese Academy of Sciences