holoscan::DataLogger

Pure virtual interface for data loggers.

This interface defines the contract that all data loggers must implement for logging various types of data including generic std::any data, Tensors, and TensorMaps.

#include <holoscan/data_logger.hpp>

Constructors

DataLogger

holoscan::DataLogger::DataLogger() = defaultholoscan::DataLogger::DataLogger() = default

Destructor

~DataLogger

virtual holoscan::DataLogger::~DataLogger() = defaultvirtual holoscan::DataLogger::~DataLogger() = default

Methods

log_data

virtual bool holoscan::DataLogger::log_data(
    const std::any &data,
    const std::string &unique_id,
    int64_t acquisition_timestamp = -1,
    const std::shared_ptr<MetadataDictionary> &metadata = nullptr,
    IOSpec::IOType io_type = IOSpec::IOType::kOutput,
    std::optional<cudaStream_t> stream = std::nullopt
)

Logs a message.

The unique_id for the message will have the form:

• operator_name.port_name
• operator_name.port_name:index (for multi-receivers with N:1 connection)

For distributed applications, the fragment name will also appear in the unique id:

• fragment_name.operator_name.port_name
• fragment_name.operator_name.port_name:index

Returns: true if logging (including serialization and sending) was successful, false otherwise.

Parameters

log_tensor_data

virtual bool holoscan::DataLogger::log_tensor_data(
    const std::shared_ptr<Tensor> &tensor,
    const std::string &unique_id,
    int64_t acquisition_timestamp = -1,
    const std::shared_ptr<MetadataDictionary> &metadata = nullptr,
    IOSpec::IOType io_type = IOSpec::IOType::kOutput,
    std::optional<cudaStream_t> stream = std::nullopt
)

Logs a Tensor with optional data content logging.

This specialized method allows efficient logging of tensor metadata without the overhead of logging large tensor data arrays when only header information is needed.

The unique_id for the message will have the form:

• operator_name.port_name
• operator_name.port_name:index (for multi-receivers with N:1 connection)

For distributed applications, the fragment name will also appear in the unique id:

• fragment_name.operator_name.port_name
• fragment_name.operator_name.port_name:index

Returns: true if logging was successful, false otherwise.

Parameters

log_tensormap_data

virtual bool holoscan::DataLogger::log_tensormap_data(
    const TensorMap &tensor_map,
    const std::string &unique_id,
    int64_t acquisition_timestamp = -1,
    const std::shared_ptr<MetadataDictionary> &metadata = nullptr,
    IOSpec::IOType io_type = IOSpec::IOType::kOutput,
    std::optional<cudaStream_t> stream = std::nullopt
)

Logs a TensorMap with optional data content logging.

This specialized method allows efficient logging of tensor map metadata without the overhead of logging large tensor data arrays when only header information is needed.

The unique_id for the message will have the form:

• operator_name.port_name
• operator_name.port_name:index (for multi-receivers with N:1 connection)

For distributed applications, the fragment name will also appear in the unique id:

• fragment_name.operator_name.port_name
• fragment_name.operator_name.port_name:index

Returns: true if logging was successful, false otherwise.

Parameters

log_backend_specific

virtual bool holoscan::DataLogger::log_backend_specific(
    const std::any &data,
    const std::string &unique_id,
    int64_t acquisition_timestamp = -1,
    const std::shared_ptr<MetadataDictionary> &metadata = nullptr,
    IOSpec::IOType io_type = IOSpec::IOType::kOutput,
    std::optional<cudaStream_t> stream = std::nullopt
)

Logs backend-specific data types.

This method is called for logging backend-specific data types (intended for use with backends that have separate emit/receive codepaths for backend-specific types). The data parameter is kept as std::any here to avoid making the base interface specific to a particular backend, but a backend-specific concrete implementation should be provided as needed via run-time type checking.

A concrete example of a backend-specific type is the GXF Entity type which is a heterogeneous collection of components. An implementation of this method for GXF entities is provided in the concrete implementation of the GXFConsoleLogger.

The unique_id for the message will have the form:

• operator_name.port_name
• operator_name.port_name:index (for multi-receivers with N:1 connection)

For distributed applications, the fragment name will also appear in the unique id:

• fragment_name.operator_name.port_name
• fragment_name.operator_name.port_name:index

Returns: true if logging was successful, false if backend-specific logging is not supported.

Parameters

should_log_output

virtual bool holoscan::DataLogger::should_log_output() const

Checks if the logger should log output ports.

If False, the data logger will not be applied during op_output.emit() calls from Operator::compute.

Returns: true if the logger should log output ports, false otherwise.

should_log_input

virtual bool holoscan::DataLogger::should_log_input() const

Checks if the logger should log input ports.

If False, the data logger will not be applied during op_input.receive() calls from Operator::compute.

Returns: true if the logger should log input ports, false otherwise.

shutdown

virtual void holoscan::DataLogger::shutdown()

Shutdown the data logger.

This method should be called to properly shutdown the data logger, including stopping any background threads and releasing resources. The default implementation does nothing. Data loggers that use background threads or other resources should override this method to perform proper cleanup.