[erlang-questions] Elarm (Erlang alarm library)

[Ola Bäckström]

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