Add the common info of the original event to the event_processor for easy direct printing

[cfc4n]

Add the common part of the original event to the event_processor for easy direct printing

[zenyanle]

Are you referring to the various fields defined in IEventStruct, such as:

type BaseEvent struct {
    eventType event.EventType
    DataType  int64
    Timestamp uint64
    Pid       uint32
    Tid       uint32
    Data      [MaxDataSize]byte
    DataLen   int32
    Comm      [16]byte
    Fd        uint32
    Version   int32
}

[cfc4n]

Yes, it is expected that when processing IEventStruct in the Processor, it can also print this information, rather than just processing Payload().

// imodule.go
m.processor.Write(e)

// iworker.go
ew.payload.Write(e.Payload())

[zenyanle]

Got it, thanks for clarifying.
Is the intention here to print this information primarily for debugging purposes? If that's the case, would you prefer this output to go through a unified logger interface, or is a direct print to standard output (e.g., fmt.Println) acceptable?

[cfc4n]

The main purpose is to expect that when the received event is processed by the Processor, it can still print the basic information within BaseEvent.

[zenyanle]

What about adding a LogFields method to IEventStruct interface, the fields of each struct which implements IEventStruct differs

[zenyanle]

The frequency of event output may be high.I am considering adding a buffer in front of Logger(io writter)

[cfc4n]

Why is the frequency of log output very high? It should be equivalent to the frequency of ew.payload.Write(e.Payload()).

[zenyanle]

For ew.payload.Write,This is an in-memory operation.

[zenyanle]

As we design the eBPF instrumentation for OpenSSL, we should plan for the high frequency of uprobe triggers on functions like SSL_read.

At high network speeds, the call rate can be substantial. This is expected, as it reflects how applications use buffered reads to process data streams. For context, a 100 Mbps transfer can lead to over 3,000 SSL_read calls per second (using a 4 KB buffer). We'll need to factor this call volume into our design to manage the potential performance overhead

[zenyanle]

In my local environment, which has 100MB bandwidth, a atomic counter triggerd 12442 within 18 seconds

[zenyanle]

A regular visit to google.com index page using http2 triggerd 26 within 300ms