Zedge Event Taxonomy Framework
An Event Taxonomy describes a schema for events in an application. This repository contains tools
and services to implement event taxonomies and event pipelines.
Events
Events are structured log messages used to describe user actions in an application, for
product analytics and business reporting.
This is a simple example event:
{
"event": "browse",
"zid": "c3f7e8fba1ebb506ce646b4bf07e8bd566fa456b",
"client_version": "5.56.0",
"serverTimestamp": 1547581321926,
"properties": {
"event_type": "BROWSE",
"content_type": "CONTENT_EDITORIAL",
"offset": 1,
"section": "stories",
"from_content_type": "NOTIFICATION_SOUND"
}
}
Events consist of a bunch of properties, most of which are optional. Each key in the JSON object above is
an event property, even those outside of the "properties"
object.
Each property has a scope
that (among other things) determines which codebase owns it, a type
, and a lifecycle
that says whether it's in production or is being phased out - read more about lifecycles here
The possible event scopes are:
"Event"
properties: these contain specific information to the action the event is describing, and typically comprise the bulk
of properties. In the example above, "section"
is an event property.
"User"
properties: these contain information about the user or device. In the example above, "client_version"
is a user property.
"Envelope"
properties: these are used for routing or filtering events, and are always required, and are always in the
outermost JSON object, to allow looking them up as efficiently as possible (using fast JSON scanners such as the
Jsoniter family). "zid"
is an envelope property in the example above.
"Internal"
properties: these are handled by the client library or server-side pipeline. Examples are geoip-based
country and server-side timestamp (added by the server-side API).
Application developers only have to worry about User and Event properties, but it's good
to know about the others, because they share the same namespace, and naming conflicts may occur.
Event Taxonomies
The example above is a payload format, and doesn't tell you which fields have which types, scopes or lifecycles. This is where
the Event Taxonomy comes in.
The taxonomy descibes, per appid
, which properties exist, and which enums are supported. (It also defines internal data bindings for the
event pipelines such as Kafka topics and ClickHouse tables, but these details are not exposed to clients.)
Read more about event taxonomies in docs/event-taxonomies.md
.
evtail
The evtail
tool lets you "tail" the Kafka event stream in real time. Full docs are here.
Services
Event Taxonomy Controller
This service implements event taxonomies as a Kubernetes Custom Resource, which allows us to treat them as deployable
objects in Kubernetes, and leverage the Kubernetes controller pattern to manage resources on behalf of the taxonomy.
This service is deployed to the test
and analytics
(prod) environments under the release name event-taxonomy-controller
.
See full docs on the EventTaxonomy custom resource.
Event Taxonomy API
...also known as taxman
.
Exposes the following endpoints:
GET /taxonomy/{appid}
- fetch the current event taxonomy for appid
PUT /taxonomy/{appid}
- post an updated event taxonomy for appid (subject to all kinds of validation)
POST /taxonomy?validate=true
- validate a taxonomy (does not validate wrt update rules)
GET /topics/{appid}
- fetch the Kafka topics used for appid
This service is deployed to the test
and analytics
(prod) environments under the release name event-taxonomy-api
.
Evtail Server
This service is deployed to the test
and analytics
(prod) environments under the release name evtail-server
.