I had conversations with Paul and Carolyn recently on #sipx: I thought I better write it down.
As some of you may recall I was advocating (re)using syslog for raising, transporting and centralizing alarms. We decided to go with a custom API instead - which is fine - but we now need something that would make implementing some alarm related functionality better. Some problems: - alarms are stored in a separate files - one per server - there is no centralized API that would let sipXconfig (or any other process for that matter) to search across the servers - alarms are part of logging infrastructure - they are not backed or restored, they are 'rolled' with other log files (which I am sure can be adjusted or prevented) - there isn't any good way of extracting the alarm from the server other than requesting the entire alarm events file - which makes it difficult to write various tools for analyzing and reporting alarms (that includes sipXconfig alarm history screen) I think that all this can be mitigated by implementing a centralized alarm sink service - similar to a 'call resolver service'. It can pull alarms from all servers, or it can allow for alarms to be pushed to it (whatever makes sense). It can devise it's own strategy for alarm persistence (DB, flat file, set of files) and integrate it into backup and restore infrastructure. It should provide an efficient search API (per date, per server, per alarm type). It might even make sense to locate some of the currently distributed notification services there offloading sipXsupervisor. I *know* it would allow to implement much nicer alarm UI in sipXconfig. I suspect it'd spur some innovation around integrating alarm system with 3rd party services. Damian _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
