Amazon Timestream is serverless time series database service that can scale to handle
trillions of events per day for as low as 1/10th the cost of relational databases and up to 1000X faster!
In this demo, we’re going to see how easy it is to get started with Amazon Timestream and interact with
it using the AWS SDK. Let’s begin by going to the Timestream service page in the
AWS Console and clicking “Create database”. We’ll call our database: “getting_started_demo”.
To ensure the security of our time series data (both in transit and at rest), Timestream supports encryption
using the Amazon Key Management Service (or KMS) key of your choice
or an automatically created default account key.
Encryption is enabled by default and cannot be turned off.
We’ll use the default key for this demo.
Finally, we’ll choose the “Sample database” option
and ask Timestream to pre-populate our database with some sample
EC2 instance metrics data to explore.
When we open the DevOps table in our demo database,
we can see it was automatically created with a “Memory store retention” period of 1 day,
and a “Magnetic store retention” period of 5 years.
All data written to Timestream initially resides in its write-optimized memory store and is then automatically
migrated to its read-optimized magnetic store after aging past the “Memory store retention” period.
Depending on your needs, you can also have Timestream delete your older data automatically
or retain it indefinitely.
These retention settings can be configured when creating a table or edited from this screen.
Let’s head over to the query editor and take a closer look at our sample table.
All rows in a Timestream table consist of one or more dimensions, which identify the time series,
a measure, which is the value that was recorded at a particular timestamp, and the timestamp itself.
Our sample DevOps table has recordings of the CPU utilization and memory utilization for
individual EC2 instances in a given availability zone and region.
Timestream’s query language is based on SQL to help users get started quickly and easily,
but its real power lies in the added support for first-class handling of time series data.
We’re going to run a couple of the built-in sample queries to see this in action.
But first, I’m going to load some additional sample data into the DevOps table, which will help demonstrate those
additional capabilities like interpolation, integration, derivation,
and smoothing operations directly on our time series data.
If you’d like to try this yourself, you can visit the link in the video description to download the sample code
provided by the Amazon Timestream team, which is available in Python, Node.js, Java, Go, and .NET.
While we wait for it to finish loading the sample data, let’s take a look at the monitoring dashboard.
Metrics for all Timestream databases and tables we create are automatically included in the built-in
Account Metrics dashboard for a convenient overall view of their health, and we can navigate
over to CloudWatch to drill down further into a specific database or table for more details.
Now that the sample data is done loading, let’s go back to the query editor.
There are several different example queries to choose from, but let’s walk through this one first.
This query is going to figure out what the average CPU utilization across our entire sample EC2 fleet was over
the past two hours, calculate the average CPU utilization for each individual instance in our
fleet across that same time period, and then tell us which ones were consuming more than 10%
of whatever the average was. We can see this first one at the top has the highest average compared
to the rest of the fleet, so let’s make note of its hostname and run another query to investigate further.
This next query is going to show us the average CPU utilization for a specific EC2 instance over the past
two hours, but with two helpful additions. First, it’s going to aggregate the running CPU utilization
across 30-second intervals (or “bins”) so that we can more easily interpret these values at a glance, rather
than having to make sense of potentially hundreds of data points per minute.
It’s also going to use a technique called “cubic spline interpolation” to fill in any gaps in the data where
the monitoring agent on the EC2 instance may have failed to record the CPU utilization measurement.
Now that we have the interpolated CPU values available, we can see that even though this
instance was consuming more CPU than average across the fleet, its peak was only slightly above 80%.
Depending on your application, an occurrence like this might be a fluke that's no cause for concern, or,
it might call for further investigation and corrective action.
Sending data to Timestream from your applications is easy as well. In this example, we’ll use the Timestream
client from the Python AWS SDK to add some additional data to our DevOps table.
Let’s insert some example random disk space metrics for our sample EC2 instances.
After running this script, we can see back in the AWS Console that Timestream not only saved our data,
but it also automatically detected the new measure name and datatype for the disk space metrics.
Having the convenience of a flexible schema means that we can start recording new metric
data at any time without needing to run any potentially expensive schema changes first.
Amazon Timestream is available now in select AWS regions.
Visit aws.amazon.com/timestream to learn more about how you can get started today!