esl / elarm Goto Github PK

Probably send the alarm record in the messages, too.

e.g: https://github.com/esl/elarm/blob/master/src/elarm_app.erl#L42-L47

Make sure the repo is rebar3-compatible and its deps are also hex.pm packages, then publish it on hex.pm.

Is this the pattern to use? Always call clear if things went well regardless if there is a raise before?

try
    : code towards /dev/hda2
    ok = elarm:clear(partition_full, "/dev/hda2")
 catch
      ok = elarm:raise(partition_full, "/dev/hda2", [{level,90}])
 end

When raising an alarm twice, the additional info is not updated.

% There is not much space left on hda2
> ok = elarm:raise(partition_full, "/dev/hda2", [{level,90}])

% There is even less space left on hda2
> ok = elarm:raise(partition_full, "/dev/hda2", [{level,92}])

Afterwards, I would expect level to be 92, but it is 90:

> elarm:get_alarms().
{ok,[{alarm,partition_full,undefined,"/dev/hda2",
            {{2014,6,20},{9,53,59}},
            {1403,258039,196826},
            indeterminate,<<>>,<<>>,<<>>,
            [{level,90}],
            [],[],undefined,undefined,new,undefined}]}

I suggest changing elarm so that it will update the additional info with each raise.

The question arises whether we need to send notifications about the additional info being changed. In the longer term, probably yes, but I suggest not implementing that yet, because another missing Elarm feature is changing the severity of an existing alarm, and these may affect each other.

Unable to get alarm log using elarm:read_log/1 with filter 'all'.

Can anyone help me with an example for retrieving Alarm Log ?

See also #7.

How the threshold field in the alarm configuration is being used. Can you provide any one Use case ?

thanks in advance.

We had an idea with Richard that elarm:raise and elarm:clear could return whether they raised/cleared an alarm or did nothing because the alarm was already existing/non-existing.

This way we could write code like this, which logs the problems only once:

case elarm:raise(...) of
    ok ->
        lager:error(...);
    existing ->
        ok
end.

@nygge, what do you think?

Unable to receive clear event while using filters {type, Type} or {src, Src}. Only receiving alarm raise info.
while using filters {type, Type} or {src, Src}, elarm is acknowledging raise info to the subscribed process. but it is not acknowledging for clear info to subscribed process.
when i use filter as "all", both raise and clear acknowledgement is given by elarm.

I have attached source code below.
subscribed_process.txt
monitor_process.txt

Can anyone suggest me how to receive both alarm and clear events by using filter "type" or "src"?

Why does this application need gproc? Why not let users choose how they want to register stuff? Couldn't a simple local name be given to the elarm_summary_sup process?

esl/TODO#60