[erlang-questions] How to do this in Erlang -- any suggestions ?

Mon Jun 13 16:01:12 CEST 2011

On Sun, Jun 12, 2011 at 11:24 PM, Edmond Begumisa <
ebegumisa@REDACTED> wrote:

> My interpretation of your question is that you want to do one-off message
> tracing.
>

Um, not too sure. What I want to do is to identify event-patterns in real
time, and take some action. For example, I am processing event-A from source
S1. At this time I have no context so I will probably do some minimal work
and "remember" occurrence of event-A (i.e. update context). Then event-B
might arrive (also from S1), and in this case .

>
> 1. You want to trace particular massages passed in your system over a
> period Y, you are particularly interested in 'EXIT' messages, but not
> necessarily:
>
> You could use the trace BIFs/dbg tool for this. Start an appropriate tracer
> with dbg:tracer, specify which processes you want to trace with dbg:p with
> one of the m|s|r flags to log the events, watch your system for a while,
> turn the tracer off (keep in mind the negative impact such tracing might
> have on a live system.) Analyse the trace output. You could also use your
> own tracer handler fun to filter/process the messages.
>

My usage is not naturally process-tracing, but if I am able to draw a
parallel or use the concept, happy to explore. So far, I am not able to
imagine the mapping of what I'd like to do with this approach. If there is
some example to illustrate, it'd help.

> 2. You want to trace massages over a number of nodes:
>
> Though I haven't used it, I believe this is what the Inviso OTP tool is
> for. You could also have a look at the ttb OTP tool.
>
> 3. You want to trace "cascading" messages in your system:
>
> Have a look at erlang:seq_trace. I believe dbg and ttb both have support
> for sequential tracing (I don't think Inviso does.)
>
> 4. You want a convenient way of walking through traces:
>
> The OTP et_viewer is a really nice tool I use a lot. Though the OTP Event
> Tracer can output ordinary trace data produced by dbg, where it really gets
> fun is when you feed it trace data by calling et:trace_me in your code (I
> normally wrap this in a ?TRACE macro). I like to think of it as a
> replacement for using io:format to print debug messages. The "detail"
> argument is really nice for "zooming" in/out as you page through trace data.
> You might find that useful for analysing a large number of messages.
>
> In short, I'm not sure you need any special "architectural design
> patterns". Just design your system as you normally would, using processes to
> model what you observe in the world, then trace it when it misbehaves or
> when you want to observe it. The traces *are* your sliding windows... unless
> I've completely mis-understood your question!
>
> - Edmond -
>
>
> On Mon, 13 Jun 2011 01:38:20 +1000, Banibrata Dutta <
> banibrata.dutta@REDACTED> wrote:
>
>  gr8 questions, and they certainly need clarification.
>> cc'ing the group s.t. others could contribute too.
>>
>> On Sun, Jun 12, 2011 at 8:48 PM, Mihai Balea <mihai@REDACTED> wrote:
>>
>>
>>> On Jun 12, 2011, at 10:51 AM, Banibrata Dutta wrote:
>>>
>>> Prematurely sent.
>>>
>>> On Sun, Jun 12, 2011 at 7:59 PM, Banibrata Dutta <
>>> banibrata.dutta@REDACTED> wrote:
>>>
>>>
>>>> What would be a good way to correlate asynchronous events, spot patterns
>>>> over a sliding window (s.a. of no. of events elapsed or time elapsed),
>>>> with
>>>> millions of events occurring simultaneously, using Erlang ?
>>>>
>>>> The set of possible events is known, and any unknown event is just
>>>> flagged
>>>> as 'unknown' (so all unknowns are similar). The set of possible event
>>>> patterns can be enumerated, but is possibly quite a large set of
>>>> patterns.
>>>>
>>>>
>>> Was wondering as to what could be the approach taken to implement such a
>>> thing in pure Erlang. My initial thoughts were along the line of
>>> maintaining
>>> FSMs per event source, but with so many events and so many possible/valid
>>> patterns, the thing seems kind of unwieldy. Also, I'd like a
>>> non-programmer
>>> to be able to define new events and valid event patterns.
>>>
>>> I believe 'Complex Event Processing' is quite likely to be the standard
>>> approach for such things, as I've found from some posts, and solutions
>>> exist
>>> in Java world for same, but both as an academic exercise (for the fun of
>>> learning) and for a potentially simpler + better solution, would like to
>>> try
>>> doing this is Erlang.
>>>
>>>
>>> I think you need to define your problem better.
>>>
>>>
>> Sure, let me try.
>>
>>
>>  What exactly do you mean by "millions of events occurring
>>> simultaneously"?
>>>
>>>
>> Okay, so I can say something like 500 events/second handled for
>> correlation
>> would be a more realistic number.
>>
>>
>>  At exactly the same time?
>>>
>>>
>> Yes... some of the events might be from same source, but spaced by as
>> little
>> as 50ms, but mostly from different sources. There could be some
>> heirarchical
>> relationship between sources. Very typical case of network management
>> scenario. E.g. a fault port on a switch, could probably cause hundreds of
>> destination unreachable events, application response timeouts, heartbeat
>> losses etc..
>>
>>
>>  Millions of events per second? Minute? Is that peak rate, average rate or
>>> minimum rate?
>>>
>>>
>> Okay, I got over-enthusiastic :-) . Say 100 events/second typical, 500
>> events/second peak, no real minimum.
>>
>> What exactly is a pattern?
>>
>>>
>>>
>> Node-A failed, Power in room-X where Node-A is kept failed, Nodes B,C,D
>> which are served thru Node-A became unreachable, due to which Services L &
>> M
>> became unavailable, and due to which another dependent service N started
>> giving inconsistent answers. So this is a pattern. However in this case,
>> there's a possibility that Power-failure had nothing to do with Noda-A's
>> failure, as backup power was available.
>>
>> Another pattern is, Power in room X failed, then Noda A failed, leading to
>> failure of only Node D, because somehow Nodes B & C were dynamically
>> configured to reroute. This is another pattern.
>>
>> What do you mean by "quite a large set of patterns"? Hundreds, thousands,
>>
>>> millions?
>>>
>>>
>> Several hundreds is a distinct possibility, and thousands are not
>> impossible, but millions -- probably not.
>>
>>
>>  How long is that sliding window?
>>>
>>>
>> From few minutes (for certain type of events), to few days (for another
>> type
>> of events).
>>
>>
>>  Can patterns encompass events coming from multiple sources or just one
>>> source?
>>>
>>>
>> Yes, indeed. However in this case, there needs to a "relationship" between
>> the event sources, that is pre-defined. E.g. some sense of "topology"
>> exists. However it is likely that only 2% of the event sources are
>> interrelated.
>>
>>
>>  Are patterns concerned only with event ordering and occurrence or there
>>> are
>>> timing issues involved as well?
>>>
>>>
>> Ordering, Timing, or any kind of causal relationship.
>>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

-- 
regards,
Banibrata
http://www.linkedin.com/in/bdutta
http://twitter.com/edgeliving
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110613/98ede147/attachment.htm>