gojue
Add the common info of the original event to the event_processor for easy direct printing
Add the common part of the original event to the event_processor for easy direct printing
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
}
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())
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?
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.
What about adding a LogFields method to IEventStruct interface, the fields of each struct which implements IEventStruct differs
The frequency of event output may be high.I am considering adding a buffer in front of Logger(io writter)
Why is the frequency of log output very high? It should be equivalent to the frequency of ew.payload.Write(e.Payload()).
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
In my local environment, which has 100MB bandwidth, a atomic counter triggerd 12442 within 18 seconds
A regular visit to google.com index page using http2 triggerd 26 within 300ms
The entire program's mechanism is based on Hook, and no matter how the Event is handled, it cannot be avoided. Right?
Yes. So, what we need is an asynchronous, buffered approach to prevent ew.payload.Write from being blocked by excessive write operations to stdout.
I think set a rate limit can be a solution, can we accept drop some logs when the frequency is too high? I have an idea to implement that. @cfc4n