Example implementation
This guide will walk you through the process of instrumenting your application to send API latency metrics to slaOS using the direct ingestion API. We'll provide code examples in JSON-compatible formats and cover best practices to ensure efficient and reliable data submission.
Building an SLA tracking API Uptime and Latency
To make things more concrete we will use the examples of sending relevant data to slaOS, in order to build an Uptime and a Latency SLA, drawing from logs that are emitted by your application directly to slaOS (without the use of any integrations).
Uptime SLA
The SLI that we would like to extract here would be the
status_code
returned for each log event produced from therequest_finished
event type.The SLO we generate here would count each none 5xx
status_code
as a good outcome for uptime, which will be divided over the total number of events to produce the measured objective.The SLA we can create here for each customer would require a threshold set on the SLO, i.e >= 99.5% uptime.
The configuration of SLIs, SLOs and SLAs happens within the slaOS UI. This step is solely focused on getting the right data, in the right format, in slaOS
Latency SLA
The SLI that we would like to extract here would be the
took
returned for each log event produced from therequest_finished
event type.The SLO we generate would count each request with a
request_duration
of under 200ms as a good outcome for latency, which will be divided over the total number of events.The SLA we can create here for each customer would require a threshold set on the SLO, i.e > 95% of requests return with a latency of <0.2 seconds.
The configuration of SLIs, SLOs and SLAs happens within the slaOS UI. This step is solely focused on getting the right data, in the right format, in slaOS
Define a payload structure
We can see that for each log event, we can extract both the status_code
, took
, organization_id
and timestamp
. We can structure our event payload like this:
Pushing events with a worker
Now that an event payload structure has been chosen, we can use a worker to deliver these events from your application to slaOS using the direct ingestion API.
SlaOSWorker Implementation
Here's a sample implementation of a worker that can batch and send events to slaOS:
The idempotency_key
can be added to each event to prevent duplicate processing of the same event. You can either pass a key generated on our end. If we don't receive a idempotency_key
, we generate a unique string based on the organization_id
, timestamp
, and the hashed contents of the values
. This identifier is crucial in avoiding the reprocessing of identical events.
Usage in Your Application
To integrate this worker into your application:
Initialize the Worker: Begin by creating an instance of
SlaOSWorker
with your specificslaOS
host,ingestion ID
, andingestion key
.Send Events: Whenever an event occurs in your application that you want to send to
slaOS
, simply callworker.add_event(event_data)
with the relevant event data.
Last updated