This website uses cookies and similar technologies to collect information you provide and information about your interactions with our sites to improve your experience, analyze performance and traffic on our website and assist our marketing efforts and customer service. We may share this information with our third-party partners. You can change your cookie preferences here. By continuing to browse, you agree to our use of these tools in accordance with our Privacy Notice and you agree to the terms of our Terms of Service.
Establish observability with the Segment Public API
This recipe provides an advanced Public API use case to integrate Event Delivery metrics to an observability tool, with a few cool tricks along the way!
Made by Kurt Lu
What do you need?
A Segment Workspace
An observability tool like DataDog, Grafana, or New Relic
Easily personalize customer experiences with first-party data
With a huge integration catalog and plenty of no-code features, Segment provides easy-to-maintain capability to your teams with minimal engineering effort. Great data doesn't have to be hard work!
In this recipe, you’ll learn how to monitor your Segment workspace using Public API.
The goal of observability involves:
Proactively understand event volume and % of events successfully sent to destinations.
Reactively identify issues, report on common errors, and average latency.
Segment’s user interface provides an Event Delivery feature to help you understand how your data is reaching your destinations, including events that are not being delivered. Our Event Delivery feature is always a valuable tool to drill down into specific Workspace issues!
However, engineering teams often have centralized observability such as DataDog, Grafana, or their data warehouse. While Event Delivery in the Segment app is useful for specific destinations and drill downs, centralizing observability becomes especially important as you grow with various business units, regions, and test environments that require scaling to a large number of connections and multiple Workspaces. In addition, Segment Public API provides an Events Volume endpoint that summarizes the number of events being sent to your Sources, regardless of their delivery status to Destinations. You can achieve this centralization by using our Public API. Our Delivery Metrics Summary and Events Volume endpoint is one of our most commonly-used endpoints.
Select Roles associated with the Token in order to limit access. In many cases, a Workspace Owner that has full access is sufficient, but you can also limit access to specific Roles:
The first 2 required parameters are your desired Destination and associated Source to track delivery metrics for. You can always check a specific Destination and its Event Delivery metrics directly from the Segment UI:
TIP: Using the List Connected Destinations from Source API, you can export in JSON all of your Destinations connected to a specific Source, and the associated Ids required when requesting Delivery Metrics.
This is a simpler approach than listing all Sources and Destinations independently.
Delivery metrics provided by Public API will be aggregated based on a time increment of your preference. The granularity to filter metrics to. This is an optional parameter that defaults to minute if not set.
For example, this request defines the granularity as HOUR.
Filtering by Hour generally provides enough granularity to catch abnormalities within 24 hours without managing a high number of APIs involved in summarizing by Minute. We support minutes to help you catch abnormal spikes in usage in order to mitigate issues closer to real time.
Based on the granularity chosen, there are restrictions on the time range you can query. Notice that the max time range varies based on the granularity. If the time range is not supported, you will receive an error message, such as:
Copy Code
{"errors":[{"type":"bad-request","message":"Invalid date/time range '2023-07-29T00:00:00.000Z'-'2023-07-31T00:00:00.000Z'. Granularity 'MINUTE' does not accept range over 4 hours."}]}
Now you’re ready to submit your API request to list Delivery Metrics Summary from a Destination. Example request with both your desired Destination and Source Id:
In addition to the Source Id, you can specify the following optional parameters:
QUERY PARAMETERS
sourceId (required): string (endTime)
Filter events that happened before this time. Defaults to now if not set. This parameter exists in beta.
startTime: string (startTime)
Filter events that happened after this time. Defaults to:
1 hour ago if granularity is MINUTE. 7 days ago if granularity is HOUR. 30 days ago if granularity is DAY. This parameter exists in beta.
endTime: string (endTime)
Filter events that happened before this time. Defaults to now if not set. This parameter exists in beta.
granularity: string (granularity)
The granularity to filter metrics to. Either MINUTE, HOUR or DAY. Defaults to MINUTE if not set. This parameter exists in beta. Enum: "DAY" "HOUR" "MINUTE"
While most definitions are provided within the Segment Event Deliver user interface and documentation, here are some notable definitions of metricName types that are returned:
Success_on_first_attempt: Count of successful deliveries to destination.
Usage API tracks metrics specific to your billable usage, notably your Monthly Tracked Usage and your APIs (which is the same metric as Events being tracked by Source):
This API is useful to complement the Usage and Billing page. By adding this data to observability or a data warehouse, you can set up custom alerts or reporting to reduce surprise overages.
This is especially useful if you have billable metrics allocated across multiple workspaces.
Currently, the usage API aggregates MTU and API metrics on a daily basis by default.
TIP: We also provide the number of anonymous and identified users on a daily basis by Source in this example. This could be useful beyond billing purposes, to help you understand your anonymous to identified conversations by specific source, over time.
Observability solutions commonly accept generic time series data to include in monitoring. As one example, we could map our Event Delivery metric response to:
Each metric name returned from Public API is commonly mapped to a metric record, and subsequently a dashboard where you can view time series data and set alerts for. There are typically a few key concepts for metrics:
Count: Total count of the metric.
Start and end time: Mapped to the start and end time from the request made to Segment Public API.
Distribution type: Mapped to the way the metric is distributing the count. In this case, Segment counts the grand total of successes and failures, and distributes time to success as a P95.
For example, each of the following could be a distinct metric:
Successes: general tracking of successful delivery for a destination, as a distribution type, count.
Discarded: number of total failures, as a distribution type, count.
Time to success p95: can typically be mapped to a metric defined as a distribution type, percentile.