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

[Edmond Begumisa]

Ah, ok, this changes things. I think I've got another idea... but first  
some clarifications...

When you say "real-time", what do you mean? Soft real-time? If so, how  
soft? How late is too late to respond to events? Or do you actually mean  
you want to respond synchronously (blocking) rather than asynchronously  
(non-blocking)?

And when you say "take some action" after identifying a pattern of events,  
is this automatic programmatic action or human action? I first thought you  
meant human action after-the-fact but now I'm inclined to believe that you  
mean the former.

- Edmond -


On Tue, 14 Jun 2011 00:01:12 +1000, Banibrata Dutta  
<banibrata.dutta@REDACTED> wrote:

> 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/
>>
>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/