[erlang-questions] Elarm (Erlang alarm library)

[Csaba Hoch]

Hi Ola,

That's a good point.

The reason for using gproc instead of erlang:register is that the former accepts any term, not only atoms. Even though the typical elarm usage will probably be to have one elarm server on one node, it is possible to create new elarm servers dynamically. If we simply used erlang:register for the elarm_summary_sum process of each elarm server, we would have needed to dynamically generate atoms, which is usually not a good idea. The simplest thing to do here was to use gproc.

That said, afterwards we added an elarm_registry module, which stores the pids of all elarm servers on the node. That could be used instead of gproc. Also, thanks to Anthony, we now have a ticket to discuss this question :) https://github.com/esl/elarm/issues/19

Csaba


On 2014 May 23, at 10:30, Ola Bäckström <Ola.Backstrom@REDACTED> wrote:

> This alarm lib looks interesting!
> 
> One quick question: gproc is used in the module elarm_summary_sup.erl. Is that really needed? Couldn't a simple named supervisor be used? In that case would the alarm library not have any dependencies apart from Erlang/OTP.
> 
> Regards,
> /Ola
> 
> -----Original Message-----
> From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Csaba Hoch
> Sent: den 22 maj 2014 21:02
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] [ANN] Elarm (Erlang alarm library)
> 
> Hi,
> 
> I would like to announce a new Erlang alarm library called Elarm (https://github.com/esl/elarm).
> 
> Elarm is an Alarm Manager for Erlang. It is designed to be easy to include in an Erlang based system and easy to use:
> 
>   ok = elarm:raise(partition_full, "/dev/hda2", [{level,90}])  # raise an alarm
>   ok = elarm:clear(partition_full, "/dev/hda2")                # clear the alarm
> 
> Elarm stores the alarms on the node (in ets by default, but the backend can be changed). This makes it easier for the node to have a REST/SNMP/web/etc. interface that shows the node's alarms, since those interfaces can ask Elarm for the list of alarms, which will include the alarm state (new or acknowledged), severity, and quite a few other
> fields:
> 
>    -record(alarm, {
>              alarm_id                                :: alarm_id(),   % e.g. 'partition_full'
>              alarm_type                              :: alarm_type(), % e.g. 'environment'
>              src                                     :: alarm_src(),  % e.g. "/dev/hda2"
>              event_time = calendar:universal_time()  :: timestamp(),
>              event_id                                :: event_id(),
>              severity = indeterminate                :: severity(),
>              probable_cause = <<"">>                 :: probable_cause(),
>              proposed_repair_action = <<"">>         :: proposed_repair_action(),
>              description = <<"">>                    :: description(),
>              additional_information                  :: additional_information(), % e.g. [{level,90}]
>              correlated_events = []                  :: [event_id()], % not used yet
>              comments = []                           :: comments(),
>              trend                                   :: trend(), % not used yet
>              threshold                               :: undefined | threshold(), % not used yet
>              state = new                             :: alarm_state(),
>              ack_info                                :: ack_info()
>             }).
> 
> The alarm_type, severity, probable_cause, proposed_repair_action and description fields can be filled in by the alarm configuration. (I.e.
> the developer or operator can say in advance that the partition_full+"/dev/hda2" alarm should have 'environment' alarm type, 'major' severity, etc.)
> 
> The code is available on GitHub, together with the README that describes the further features (including acknowledging and commenting alarms, and subscribing to them): https://github.com/esl/elarm
> 
> We hope that Elarm becomes the de facto alarming application in the Erlang world and we will certainly do all we can to make it as good as possible.
> 
> Elarm is in part funded by the RELEASE project (http://release-project.eu/), which is an EU FP7 STREP (287510) project that aims to scale the radical concurrency-oriented programming paradigm to build reliable general-purpose software, such as server-based systems, on massively parallel machines.
> 
> Regards,
> Csaba
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions