Get desktop application:
View/edit binary Protocol Buffers messages
Used in:
The IP address of the client
Whether the IP address is from a proxy service
Geographic location information for this IP address
Client platform info that every vortex client will set via X-Vortex-Client-Platform Expected format is "dbt-core/1.7.0 dbt-vortex-python/1.0.0 dbtlabs-proto/4.25.1" See https://github.com/dbt-labs/vortex/pull/101 for more context
Used in:
Full header value as received
Source service of the vortex client (i.e. dbt-core)
Version of the source service
Vortex client used (i.e. vortex-client-rust)
Version of the vortex client
Name of the dbt proto library used
Version of the dbt proto library
a message that is sent to the dead letter queue when a message is rejected by vortex.
type url of failed message
a best effort attempt at serializing the rejected message.
original bytes of failed message (for reconstructing or replaying events).
the reason that the message was rejected.
Used in:
Two-letter country code (ISO 3166-1 alpha-2)
Name of the city
Latitude coordinate
Longitude coordinate
Timezone identifier (e.g., "America/New_York")
Name of the continent
Used in:
this can encapsulate any known protobuf message type. https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/any.proto
the time that the event was created by the client. this could be different than the time that the event was sent to vortex, since the client may buffer events before sending them.
the time that the client sent the message to vortex (recorded by the vortex client library automatically).
the time that the vortex api received the message.
the time that the vortex backend fully processed the message.
internal canonical message for vortex events. this is what you receive when you integrate a streaming consumer with vortex. it is also what vortex uses internally on its queue.
a UUID which is a unique identifier for the event, it can be provided by the client or autogenerated by the vortex client library.
the data that was sent to vortex originally. it is retained here so that consumers can re-construct the original message exactly as they sent it. clients will construct this from a valid protobuf message. each batch can contain many different message types. this will be hidden away from streaming consumers, who will instead see the exact protobufs requested come through in their subscription.
Base enriched event data that all telemetry events inherit from Should be explicitly defined as a field "enrichment"
Used in: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
IP address and proxy information of the client
Information about the client platform, including service, client, and library versions
User agent information for web-based events
For web based events that send the User-Agent header
Used in:
Raw User-Agent string as received from the client
Name of the browser (e.g., "Chrome", "Firefox")
Version of the browser
Operating system name (e.g., "Windows", "macOS")
Operating system version
Device model or identifier
Type of device (e.g., "mobile", "desktop", "tablet")