Telemetry
Last updated
Last updated
After modeling the system and its components, the following step is to set up the telemetry. Telemetry is essential to provide Akamas with enough data to evaluate a configuration both in terms of goal (e.g. reducing the cost) and constraints (e.g. meeting SLOs).
Akamas can gather metrics from many data sources, from industry-standard observability platforms (e.g. Prometheus or Dynatrace) to simple CSV files. This is done via telemetry providers that contain all the logic and information required to correctly extract the metrics and map them to the components of your system. You can take a look at available telemetry providers in the documentation reference.
To instruct Akamas about the location of the data sources and how to access them, you can create a telemetry instance for your system. A telemetry instance comprises the following properties:
Name: An optional unique name within the system to quickly identify it.
Provider: The name of the telemetry provider that will be used to gather metrics.
Config: Additional configuration options that depend on the provider (e.g. a URL to reach the observability tool or the location of a CSV file to import) refer to each provider reference for more information.
A system can include multiple telemetry instances from different providers (e.g. in case you need to extract some information from Dynatrace and others from a CSV file).
Telemetry instances alone do not provide information on which metrics should be extracted from the data source and to which component they map. As briefly introduced in the system section this is the job of the component properties.
Each telemetry provider supports a unique set of properties that depends on the specific data source which allows Akamas to map each component to one or more entities in the observability tool and extract the right metrics for that particular technology.
As we introduced at the beginning of this section, we choose to use Dynatrace to monitor our application. To instruct Akamas to gather metrics from this data source you just need to create the following file.
In this file, we specified the URL and the token required to authenticate to our Dynatrace instance.
Save it to a file named, as an example, instance.yaml and then issue the command.
As described in the section above, telemetry instances are coupled to a specific system. For this reason, we had to provide the name of the system Online Boutique as an argument to the create command.
Here is how the telemetry instance looks in the UI.
Akamas needs to be informed that the component named Adservice used in the system maps to a specific entity in Dynatrace that represents the container running in the Kubernetes cluster.
Recalling the definition of the Adservice component in the system we see that it contains a set of properties starting with the dynatrace keyword. These properties are used by the Dynatrace telemetry provider to map the component to the correct entity and import metrics such as CPU usage and throttling that can be used to gather information about the performance of such components.
For a complete definition of the properties available for the Dynatrace provider, as well as other providers, you can take a look at the telemetry reference documentation section.
If Dynatrace is not your observability platform of choice, take a look at the telemetry provider section where you can find many other telemetry providers for different observability tools and common integration strategies like CSV files.
