You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Broker is mostly a black box to Zeek. Broker can generate valuable log output that helps understanding the system behavior, but Broker writes logs into its own file (or console) if configured. In Zeek, we do have a broker.log which would be the natural place to look at in case of something is off in Broker land, but this log only contains a few high-level events at the moment.
We could follow the example of other message broker APIs for allowing users to tap into the log stream. For example, librdkafka offers an event API that users can tap into by passing a callback object to the library. This is a quite common technique, so it seems natural to do something similar in Broker.
Here's a draft for a logging interface in Broker:
/// Carries information about internal events to the user that are crucial for/// understanding the system behavior.classevent {
public:/// Encodes the severity of the emitted event.enumclassseverity_level {
/// The reported event is most likely fatal. After a critical event, normal/// operation has most likely broken down.
critical,
/// The event signals an unrecoverable error in Broker. For example, this/// might signal a broken network connection or a data store that is no/// longer functional after losing connection to the master node.
error,
/// The event signals an unexpected or conspicuous system state that may/// still be recoverable.
warning,
/// Signals a noteworthy event during normal system operation such as a new/// peering connection.
info,
/// The event carries information relevant only for troubleshooting and/// debugging purposes.
debug,
};
/// Encodes the component that has emitted the event.enumclasscomponent_type {
/// The Broker core has emitted the event.
core,
/// A Broker data store running in master mode has emitted the event.
master_store,
/// A Broker data store running in clone mode has emitted the event.
clone_store,
/// The Broker network layer has emitted the event.
network,
/// A Broker backend has emitted the event. This could be a SQLite database/// or an in-memory store.
store_backend,
};
/// The time when the event has been emitted.
broker::timestamp timestamp;
/// Stores the severity for this event.
severity_level severity;
/// Stores which Broker component has emitted this event.
component_type component;
/// A unique identifier for the event.
std::string_view identifier;
/// A human-readable description of the logged event.
std::string description;
};
/// A smart pointer holding an immutable ::event.using event_ptr = std::shared_ptr<const event>;
/// An interface for observing internal events in Broker.classevent_observer {
public:/// Called by Broker to notify the observer about a new event./// @param what The event that Broker has emitted./// @note This member function is called from multiple threads and thus must/// be thread-safe.virtualvoidobserve(event_ptr what) = 0;
/// Returns true if the observer is interested in events of the given severity/// and component type. Returning false will cause Broker to not generate/// filtered events.virtualboolaccepts(event::severity_level severity,
event::component_type) const = 0;
};
/// A smart pointer holding an ::event_observer.using event_observer_ptr = std::shared_ptr<event_observer>;
The implementation itself would be quite straightforward.
Most of the work in Broker would be replacing our current logging calls with a new API that would dispatch the events to the installed observer.
In Zeek, we would implement a subclass of broker::event_observer and would forward the events to Zeek's logging system.
The text was updated successfully, but these errors were encountered:
Currently, Broker is mostly a black box to Zeek. Broker can generate valuable log output that helps understanding the system behavior, but Broker writes logs into its own file (or console) if configured. In Zeek, we do have a
broker.log
which would be the natural place to look at in case of something is off in Broker land, but this log only contains a few high-level events at the moment.We could follow the example of other message broker APIs for allowing users to tap into the log stream. For example,
librdkafka
offers an event API that users can tap into by passing a callback object to the library. This is a quite common technique, so it seems natural to do something similar in Broker.Here's a draft for a logging interface in Broker:
The implementation itself would be quite straightforward.
Most of the work in Broker would be replacing our current logging calls with a new API that would dispatch the events to the installed observer.
In Zeek, we would implement a subclass of
broker::event_observer
and would forward the events to Zeek's logging system.The text was updated successfully, but these errors were encountered: