Capturing Logs

Use app events for logs that should become part of the Ansight session timeline. Use sendClientLog(...) for ad hoc live-session log lines. Use AnsightLogger only for Ansight SDK diagnostics.

App Events

try AnsightRuntime.shared.event(
    "Checkout loaded",
    type: .info,
    details: "route=/checkout"
)

try AnsightRuntime.shared.event(
    "Payment failed",
    type: .error,
    details: "httpStatus=500"
)

Attach a custom channel when the event belongs to a specific metric or subsystem:

try AnsightRuntime.shared.event(
    "Queue retry",
    type: .warning,
    details: "attempt=2",
    channel: 42
)

Live Client Logs

await AnsightRuntime.shared.sendClientLog("Checkout loaded cartId=debug-42")

sendClientLog(...) sends the line over the active live session. It does not automatically mirror print, OSLog, or third-party logging frameworks.

SDK Diagnostics

Observe Ansight SDK-internal logs with AnsightLogger:

let callback = AnsightClosureLogCallback { level, message, error in
    print("[Ansight] \(level.rawValue): \(message)")
}

AnsightLogger.registerCallback(callback)
AnsightLogger.removeCallback(callback)

SDK diagnostics are useful while debugging the integration. They are not the primary app-log capture path.

Session Properties

Grouped session properties are included in session.open. When a live session is connected, updates are also sent immediately.

await AnsightRuntime.shared.updateSessionProperties([
    "app": [
        "region": "au",
        "tenant": "debug"
    ]
])

await AnsightRuntime.shared.clearSessionProperties()

Logging Quality

Prefer stable labels and compact structured details. Sparse or inconsistent logs make session analysis weaker.