InfluxData Blog - David Flanagan

Slack Tips for Remote Communication

David Flanagan (InfluxData) — Wed, 25 Mar 2020 07:00:26 -0700

As the world is now forced into remote working due to COVID-19, I believe it’s important to make some things explicit that have been implicit for many a remote worker over the past few years with the rise of Slack in the distributed office. These tips are designed to be simple and actionable, with the goal of improving your remote working experience.

Please keep in mind: remote is hard. At times, you’ll feel disconnected from your peers and frustrated at the simple synchronous tasks that need to become asynchronous. However, there are many benefits you’ll hopefully come to appreciate, but with the lock-down becoming more and more prevalent in your daily lives, these may not become apparent until a sense of normality encroaches the world.

Emojis, empathy, and engagement

Be empathetic.

Please remember that text messages have no tone, context, or visual cues. Emojis are great at revealing the tone of your message. Assume the best in your colleagues’ messages, even if they’re terse and direct. Assume they’ve got a child on their knee and they can’t use more words for fear of dropping said child on their head (this has never happened). Use emojis to reveal context when you think you’re being funny or sarcastic.

Liberal muting

When you’re remote, Slack IS your job — in a terrible and weird sense. Remote teams are only as successful as their ability to communicate with their peers. Collaboration across teams becomes rather difficult, as it’s no longer about wheeling over to another cluster of tables.

As your company’s wealth of knowledge is primarily communicated over Slack, you’ll find yourself joining more and more channels; trying to keep abreast of the company’s objectives, projects, and progress. To do this, you will end up in more and more channels. The best advice I have for this is extremely liberal use of “/mute”. This allows you to come and go with these channels without them cluttering your notifications and sidebar. You can also mute a channel from the Slack app by right-clicking on it and choosing mute.

Liberal tagging

You should always tag someone if you want them to see a message. It doesn’t matter if it’s the message right after another message, assuming that they’re not actively following your channel (unless it’s your team channel) and tag them in the messages you want them to see.

This is increasingly important as we mute more and more channels, as it’s the only way Slack will notify us of such messages. Don’t worry about tagging team mates out of hours, we’ll cover that in “Silence Notifications”.

Silence notifications

With muted channels and liberal tagging (see, there’s a reason for the order of these tips), you’ll need to take control of your own notifications. It is not your peers’ responsibility to check what hours you prefer to work. When you’re remote, the 9-5 doesn’t exist. Regardless, which 9-5? CET? BST? PST? Believe it, or not, the world doesn’t run on SFO time! ?

Set up your Slack to silence notifications outside of your working hours.
Install and use the "/gone" command (/gone 15m shopping) to set yourself "AFK" and set a status at the same time.
Make sure your notifications are set to "Only Mentions" (see screenshot).

<figcaption> Limit Slack notifications</figcaption>

Value asynchronous workflows

When sending a direct message to your colleague, it may feel natural to say “Hi”. However, this moves the conversation to synchronous rather than asynchronous. This forces your colleague to acknowledge you, taking them away from their work. Instead, we should put enough context into the message to allow our colleagues to understand what we need and when we need it.

Use messages like:

"Hey, when you have a moment; I'd like to pair with you on the multi user login problem"

This message articulates what and when. What do I need? I need to pair with you on something, When do I need it? It’s not urgent, whenever you have a moment.

Sorted.

Remind me

Inevitably, you will check your Slack outside of your “working” hours. Using “/remind” will allow you to have Slack ping you the following hour, day, or week.

Avoid shouting

Avoid using @everyone, @channel, @here tags. If you really need to post an announcement, which is the only valid use-case, then you should probably use a dedicated channel or drop to email.

As our VP of Engineering, Ryan Betts, said “@here is the equivalent of standing up in the office and yelling something to everyone”.

That must mean that @everyone is the equivalent of hiring a barber shop quartet to show-up at every employee’s home, wake them up, and sing your message.

That’s not a suggestion — it’s probably best you don’t do that.

Oversharing & communication is key

Keep conversations to public channels. There’s no such thing as “over communication” (I hope).

What seems trivial to you may be interesting and important to others. Use public channels to update on your backlog, projects, WIP, etc.

Others can decide what they wish to filter.

Be accountable & dependable

Your colleagues can’t tap you on the shoulder and ask you a question.

When you worked in an office and they did, you didn’t have the option to avoid answering their question. Being remote doesn’t give you that option either, even if it is super easy to do.

If your colleague takes time to ask you a question, be courteous and answer them. This can still be asynchronous, and you don’t need to reply right away: but you do need to reply.

If you don’t know, say you don’t know.

If you don’t have time, say you don’t have time.

Don’t leave them hanging.

We hope these tips help you in what is a rather turbulent and chaotic time.

Best of luck! David

Meetup Notifications with InfluxDB Cloud

David Flanagan (InfluxData) — Thu, 19 Sep 2019 09:48:57 -0700

It was a warm Thursday afternoon, in Scotland, when the familiar chime of Slack woke me from my daydream. It was Thom. Hmm, what does he want?

<figcaption> Thom asks a simple question.</figcaption>

The mission

It was simple. Thom wanted to publish updates for every user group to our Community Slack. He wants these notifications posted at 1 week before each event, and 24 hours before each event. Now, of course, I could have used one of the many Slack libraries out there and some Python to parse the Meetup API and run it on a cron … but these are events, right? InfluxDB stores events. So I got to thinking … can we parse the Meetup API with Telegraf, store the events in InfluxDB, and then use Flux tasks to send the Slack alerts?

Yes. The answer is yes.

Collecting the events

First, we need to get the events from Meetup.com into InfluxDB Cloud. We got very lucky here, as Meetup.com actually allows reasonable access to their API without authentication. Telegraf can handle authentication for HTTP requests, but it was nice to not have to worry about it.

Using the Telegraf HTTP input plugin, we were able to fetch all meetup information from the Meetup.com API with a simple configuration of the HTTP plugin.

[[inputs.http]]
  name_override = "meetup-events"
  interval = "1h"

  urls = [
    "https://api.meetup.com/pro/influxdb/events"
  ]

  data_format = "json"

  tag_keys = [
    "event_id",
    "event_venue_city",
    "event_venue_localized_country_name",
    "chapter_name"
  ]

  json_string_fields = ["event_name", "event_link"]

  fieldpass = ["event_duration", "waitlist_count", "yes_rsvp_count"]

  json_time_key = "event_time"
  json_time_format = "unix_ms"

With the configuration above, Telegraf will parse Meetup.com every hour and store the events to InfluxDB Cloud (Output configuration omitted). Yes, we’ll be writing the same points every hour; but we’re using the timestamp the event starts and the series key for each event (combination of tags) won’t change — so we’re golden.

Confirming the data

By default, when you use “Explore Metrics” to dig around your data … it assumes your data is in the past. Go figure! In order to confirm your data is there, you need to update the GUI time selector — or switch to the script editor. I’ll show you how to do both.

GUI

Select the date drop-down and select “Custom Time Range”. You can either modify the raw date string, or click fast-forward on the month selector a bunch of times.

Script editor

Flux has built-in support for dates, times and duration. This allows us to write the query below, looking for data between now() and 4 weeks (4w) time.

Nice.

from(bucket: "metrics")
|> range(start: now(), stop: 4w)

Sending the alerts

Now that we’ve collected the data and confirmed it’s available. Let’s look at setting up the first notification: 1 week in advance.

First, go to the Tasks page. If you’ve never been there before, you’ll see an empty page like this. Click “Create Task”.

Task configuration

We’re going to run this task every hour, so we’ll need to keep that in mind during our range filter below. We don’t want to send a notification for an event twice, so we need to make sure each query every hour is time scoped correctly.

Range filter

We need a very specific range for this query. We want only the events that are scheduled to start between 1 week and 1 week plus 1 hour. This “plus 1 hour” is important. As we run our task once per hour, we ensure we only fetch events from a 1 hour window; avoiding duplicate notifications.

from(bucket: "metrics")
|> range(start: 1w, stop: 1w1h)

Measurement filter

Now, we don’t want to query every measurement in our bucket. We only want the meetup-events measurements (name configured in Telegraf).

|> filter(fn: (r) => r._measurement == "meetup-events")

Group and pivot

Due to the way data is stored in InfluxDB 2, we need a couple of extra steps to get the data in the format you’d expect. With our current query, we’re not going to have “row” based data; where each row is a single event. Instead, we’re going to get back columnar data that needs to be assembled. It looks like this:

Yikes. Scary! In order to get this into shape, my first thought was to group() by the event_id.

from(bucket: "metrics")
|> range(start: 1w, stop: 1w1h)
|> filter(fn: (r) => r._measurement == "meetup-events")
|> group(columns: ["event_id"], mode:"by")

Hmm. But unfortunately, that isn’t quite right. Now we have a table per event, with a row per column.

OK. Let’s scratch group and use pivot.

from(bucket: "metrics")
|> range(start: 1w, stop: 1w1h)
|> filter(fn: (r) => r._measurement == "meetup-events")
|> pivot(rowKey:["event_id"], columnKey: ["_field"], valueColumn: "_value")

Pivot will return a table for each event; with each table having a single row with all the event fields. Perfect.

Sending to Slack

Flux has 2 methods for interacting with Slack.

The HTTP package
The Slack package

The HTTP package allows us to send arbitrary HTTP requests to any endpoint. This allows us to create an incoming webhook with Slack and send the HTTP request to the endpoint.

The Slack package allows us to provision a legacy token and send notifications directly to the Slack API.

The latter allows you to specify the sender/channel and some other details at “send time”, whereas the incoming webhook configures all those details upfront.

As Slack “legacy tokens” could be deprecated at their will, we’ll use the incoming webhook and the HTTP package for this tutorial.

In order to use the HTTP package, we first need to import it. This is nice and simple: import "http".

The API for the HTTP package is pretty simple at the moment:

import "http"

http.post(
  url: "http://localhost:9999/",
  headers: {x:"a", y:"b", z:"c"},
  data: bytes(v: "body")
)

So with this in mind, we can take our Flux code that we’ve been building up and start to put it all together into something useful.

NB: We’re also using the json package to encode the HTTP payload.

import "http"
import "json"

from(bucket: "metrics")
	|> range(start: 1w, stop: 1w1h)
	|> filter(fn: (r) =>
		(r._measurement == "meetup-events"))
	|> pivot(rowKey: ["event_id"], columnKey: ["_field"], valueColumn: "_value")
	|> map(fn: (r) => {
		message = {text: "1 Week Warning! ${r.event_group_name} is meeting this time next week in ${r.event_venue_city}, ${r.event_venue_localized_country_name}, and there's ${string(v: r.event_yes_rsvp_count)} amazing people for you to join and learn with. ${r.event_link}"}
		_ = http.post(url: "https://hooks.slack.com/services/SECRET/SECRET/SECRET", data: json.encode(v: message))

		return r
	})

Oh, shi ... oot!

Yeah, did you spot that too? We’re storing a hard-coded secret inside of our Flux task. Shoot!

Fortunately, InfluxDB 2 provides a secrets API. Sadly, for the moment, there’s no shiny GUI; but we can use the raw API with curl for now.

Let’s add our Slack webhook endpoint to our organization with curl:

curl -XPATCH \
  https://us-west-2-1.aws.cloud2.influxdata.com/api/v2/orgs/${ORG_ID}/secrets \
  -H 'authorization: Token ${TOKEN}' \
  -H 'Content-type: application/json' \
  --data '{"slackWebhook": "${SLACK_WEBHOOK_ENDPOINT}"}'

You’ll need:

Organization ID (Grab this from your URI when logged into InfluxDB Cloud)
InfluxDB Cloud token (Grab this from the token page)
Slack Webhook Endpoint

Things to note

You can use the curl with -XPATCH as many times as you like to add new secrets. You can see the keys, but not the values, of your secrets with a GET request.

curl -XGET \ https://us-west-2-1.aws.cloud2.influxdata.com/api/v2/orgs/${ORG_ID}/secrets \ -H 'authorization: Token ${TOKEN}' \ -H 'Content-type: application/json'

Cleaning up

Now that we’ve created a secret via the API, let’s bring this into our Flux task to clean up the code. Here’s the cleaned up code in full.

import "http"
import "json"
import "influxdata/influxdb/secrets"

webhookUri = secrets.get(key: "slackWebhook")

from(bucket: "metrics")
	|> range(start: 1w, stop: 1w1h)
	|> filter(fn: (r) =>
		(r._measurement == "meetup-events"))
	|> pivot(rowKey: ["event_id"], columnKey: ["_field"], valueColumn: "_value")
	|> map(fn: (r) => {
		message = {text: "1 Week Warning! ${r.event_group_name} is meeting this time next week in ${r.event_venue_city}, ${r.event_venue_localized_country_name}, and there's ${string(v: r.event_yes_rsvp_count)} amazing people for you to join and learn with. ${r.event_link}"}
		_ = http.post(url: webhookUri, data: json.encode(v: message))

		return r
	})

Here’s the output on Slack. A job well done, even if I do say so myself ????

Final thoughts

InfluxDB Cloud with Flux, tasks and secrets is a powerhouse of functionality. We hope you enjoyed this tutorial and we can’t wait to see what you build.

Have a rockin’ day.

InfluxDB 2 Migration Path: Instrumentation

David Flanagan (InfluxData) — Thu, 15 Aug 2019 07:00:47 -0700

InfluxDB 2 and our SaaS offering, InfluxDB Cloud 2, are right around the corner. While we’re finalizing the last of our wonderful updates to give you the InfluxDB 2 experience you deserve, we’re going to talk to you about migration paths.

This article is part of a series. This installment will cover migrating existing instrumentation in your applications with the InfluxDB 1 client libraries to InfluxDB 2 with NO code changes.

The official migration path

InfluxDB 2 will ship with a compatibility mode for InfluxDB 1, but this will come later in the year — closer to our first GA release of InfluxDB 2. This means that you’ll still be able to utilize the client libraries for v1 when using v2, at least in a limited capacity. As that isn’t available right now, we can do something pretty similar, using Telegraf; and that’s what I want to talk about today.

But before we get to that, let’s talk about client libraries.

Client libraries

Our CTO Paul Dix has previously mentioned that we’ll be creating, maintaining, and supporting our own official client libraries for InfluxDB 2! While there are some client libraries for InfluxDB 1 under the InfluxData banner on GitHub, these are often maintained by external contributors and the APIs can vary greatly. With InfluxDB 2, we’re going to take a much more active role in the progression and maintenance of the client libraries.

Of course, these aren’t available at this moment in time either; but on (or near) the launch of 2.0, we plan to support dotNet, Go, Java, JS, PHP, Python and Ruby.

So how can you start instrumenting your applications for InfluxDB 2 in the meantime?

Introducing Telegraf

Well … obviously Telegraf needs no introduction … but, more often than not, people don’t quite understand the width and breadth of the plugins available. Case in point: did you know Telegraf has an input plugin called influxdb_listener? This plugin allows Telegraf to provide an InfluxDB 1 /write compatible proxy.

???? Woah ????

Caveats

There are a few things worth noting before you get too excited. Firstly, it really is just the /write path. This will not allow you to read from InfluxDB, should you be using any of the client libraries for that purpose. CREATE DATABASE requests will respond with a 200 OK but nothing is actually executed on the remote InfluxDB server; only the Telegraf plugin can determine which database you can write to. More about this shortly.

The migration path

Let’s get down to details and look at your current, assumed and estimated, architecture.

<figcaption> Writing to InfluxDB 1</figcaption>

Nice and simple. You’ve got one of our client libraries in your application and you’re using it to write directly to InfluxDB 1.

Now, we want to change as few pieces as possible. So instead of writing to InfluxDB 1, we’re going to bring in Telegraf to sit in the middle and proxy our requests. Depending on the volume you’re sending through to InfluxDB, it’s up to you on how to deploy this Telegraf.

Common scenarios are:

Telegraf on every host (or DaemonSet)
Telegraf sidecar (Kubernetes)
Centralized Telegraf service

<figcaption> Writing to InfluxDB 2 with InfluxDB 1 client libraries through Telegraf</figcaption>

If you’re running Telegraf in a container, be sure to check out my Bring Your Own Telegraf work.

Configuring Telegraf

The first step is to enable the influxdb_listener plugin and get it configured. You can do that with the following:

[[inputs.influxdb_listener]]
  ## Address and port to host HTTP listener on
  service_address = ":8086"

This is the simplest setup with no authentication, but we don’t recommend running InfluxDB this way. So in order to configure authentication, you can provide TLS and basic authentication details within your Telegraf configuration:

[[inputs.influxdb_listener]]
  ## Set one or more allowed client CA certificate file names to enable mutually authenticated TLS connections
  tls_allowed_cacerts = ["/etc/telegraf/clientca.pem"]
  ## Add service certificate and key
  tls_cert = "/etc/telegraf/cert.pem"
  tls_key = "/etc/telegraf/key.pem"
  ## Optional username and password to accept for HTTP basic authentication.
  ## You probably want to make sure you have TLS configured above for this.
  basic_username = "foobar"
  basic_password = "barfoo"

Now when you run Telegraf, it will accept InfluxDB 1 write requests on the configured port.

???? Sweet! ????

Now to configure our InfluxDB 2 output. Again, Telegraf makes this trivial:

[[outputs.influxdb_v2]]
    ## The URLs of the InfluxDB cluster nodes.
    ## Multiple URLs can be specified for a single cluster, only ONE of the
    ## urls will be written to each interval.
    urls = ["http://127.0.0.1:9999"]

    ## Token for authentication.
    token = ""

    ## Organization is the name of the organization you wish to write to.
    organization = ""

    ## Destination bucket to write into.
    bucket = ""

Simple!

But wait, there's more!

Why stop there? Did you know you can use Telegraf to combi-write? There’s no need to migrate entirely to InfluxDB 2, because who would do that while we’re still in alpha, amirite?

Why not write to InfluxDB 1, InfluxDB 2, and InfluxDB Cloud 2 … with no code changes whatsoever?

To do so, just configure multiple output plugins.

[[outputs.influxdb_v2]]
    # As above
[[outputs.influxdb_v2]]
    # Configure for Cloud 2 (See your settings page)
[[outputs.influxdb]
    # As you currently have right now

????????????

There you have it, a pain-free way to give InfluxDB 2 a try without changing a single line of code.

Until next time ????????????

?? Did you know our SaaS offering, Cloud 2, has a fantastic free tier? ??

Bring Your Own Telegraf

David Flanagan (InfluxData) — Thu, 06 Jun 2019 08:00:41 -0700

I have the privilege of telling people I work for a truly open source company. What do I mean by that?

90% of the InfluxData code is open source, with that other 10% being our enterprise additions to our database, InfluxDB. That 10% fuels the company and it’s open source commitment.

Our commitment to open source doesn’t stop there. We also actively encourage, maintain, and support contributions that integrate our products with other products, OSS or otherwise; even those which some may consider our “competitors”. Alas, we don’t see it this way. We welcome and encourage an open and supporting ecosystem around time series, monitoring, and alerting.

Of course, this comes at a cost. While Telegraf supports reading and writing to over 200 software components; such as DataDog, Elasticsearch, Kafka, MongoDB, OpenTSDB, Prometheus, Wavefront, and much much more…this comes at a cost…a cost of bytes.

<figcaption> Plugins everywhere</figcaption>

Presently, the Telegraf binary weighs in at 60MiB (amd64 binary), 244MiB (Docker Image), and 80MiB (Docker Image Alpine).

While not massive, depending on your usage of our plugins, this might be too much for you to chew. As more and more of our community adopts Kubernetes, embracing patterns like sidecars, the size of utilising multiple Telegraf instances can become problematic.

Introducing Bring Your Own Telegraf (BYOT)

BYOT is a Docker-based framework for building Docker Images with a custom, slim-line, Telegraf binary; that only includes the plugins you need. This does not require any special configuration. You just need to provide your Telegraf configuration, as you normally would.

This will result in substantially smaller image sizes. Let’s take a look at a comparison. Below are the image sizes for the normal Telegraf image, and the Alpine variant. Next to it is a custom Kubernetes image I built with only the following plugins:

Inputs
- Prometheus
Outputs
- InfluxDB

$ docker image ls
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
telegraf            1.10                c14f9454c5aa        13 days ago         244MB
telegraf            1.10-alpine         f6d6ea3f4972        4 days ago          80MB
rawkode/telegraf    kubernetes          3437fe686f23        4 days ago          25.4MB

Getting started

My recommended approach is to provide a Git repository for each Telegraf configuration within your infrastructure. Let’s assume we want to build a Telegraf with the following plugins:

Inputs
- Docker
Outputs
- InfluxDB 2

Configuring Telegraf

First, we’d create our Telegraf configuration. The build process expects there to be a telegraf directory in the root of your build context. This directory is no different from your /etc/telegraf directory on any other system. You can use a single file, telegraf.conf, or a directory-based approach, telegraf.d. For simplicity, this example uses a single file.

[agent]
  interval = "5s"
  omit_hostname = true

[[inputs.docker]]
  endpoint = "unix:///var/run/docker.sock"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb2:9999"]
  token = "$INFLUXDB_2_TOKEN"
  organization = "InfluxData"
  bucket = "default"

Next you need to add a Dockerfile to your repository:

FROM rawkode/telegraf:byo AS build
FROM alpine:3.7 AS telegraf
COPY --from=build /etc/telegraf /etc/telegraf
COPY --from=build /go/src/github.com/influxdata/telegraf/telegraf /bin/telegraf
ENTRYPOINT [ "/bin/telegraf" ]

Build

That’s it! Have your CI system automagically build this image on every commit and push it to your registry and you’re good to go. You can specify the version of Telegraf to build with a build-arg.

docker image build --build-arg VERSION=1.10 -t my_telegraf

A custom Telegraf with only the plugins you require, within a few minutes!

How does it work?

BYOT utilizes the often forgotten ONBUILD instruction available within a Dockerfile. This allows us to define instructions that are deferred until a subsequent calling, such as your docker image build command. Feel free to peruse my code, or checkout my example repository, to understand it a little better.

Any other improvements?

During my initial tests, which are not extensive, I’ve noticed that the memory usage of Telegraf is about a 1/3 (6MiB vs. 12MiB) of running the normal Telegraf binary with only 4 plugins (system, cpu, mem, disk) enabled. This could be circumstantial and I will publish more results on this in due course.

What's next

Currently, BYOT supports custom building with input and output plugins based on your configuration. I plan to add support for aggregators and processors shortly also, which will bring our image size down even further.

Thanks for listening. I’d love to know what you think, so please reach out in the comments section or via Twitter.

Monitoring TLS Certificates with Telegraf

David Flanagan (InfluxData) — Thu, 25 Apr 2019 14:20:00 -0700

We’ve all been there. You’re sitting eating your lunch in the office canteen and you notice a flurry of people walking briskly and asking each other to check the website on their phone. Is it just one phone? Oh, it’s your phone too. Maybe it’s the WiFi … they check on 4G …

The faces slowly turn in your direction, eyes catching awkwardly. You feel your phone vibrate in your pocket … not just once. Production can’t be down, you think. My pager hasn’t gone off … everything must be fine, they’re confused; right?

Oh dear. The x509 / TLS certificate expired and nobody in the world can browse our high-profile, 24x7, worldwide, super amazing website.

While it’s common for operators and developers to monitor their systems, using the metrics we treasure so dearly: RED/USE/4 Golden Signals, something so simple is often overlooked - the x509 certificates with which we deliver our website, used to authenticate microservices, or to authenticate against the Kubernetes API.

Fortunately, we’ve got you covered! Telegraf has had an x509_cert plugin for many years now, and it couldn’t be easier to setup.

Configuring the plugin

The x509_cert input plugin supports local and remote x509 endpoints. So whether you’re running Telegraf as a daemonset on your Kubernetes cluster, monitoring your local cert directory, or running a single instance to monitor your certificates from a users perspective; we’ve got you covered.

[[inputs.x509_cert]]
    sources= ["https://www.example.org:443", "/etc/tls/certs/www.example.org"]

Available metrics

Now that we’ve got Telegraf collecting and sending our x509 metrics to InfluxDB, we can begin to build a query to alert on its expiration. Fortunately, this is almost as simple as configuring the plugin.

SELECT (expiry / 60 / 60 / 24) as "expiry" FROM "telegraf"."autogen"."x509_cert"

This will return the number of days until each certificate expires.

Telegraf provides the following tags to filter or add to your alerts:

common_name
country
locality
organization
organizational_unit
province
source

If you’ve got Telegraf configured to add the hostname to each measurement, that will also be available. Be sure to only use this when running Telegraf as a daemonset or on bare metal.

Telegraf makes it incredibly simple to monitor these certificates that nobody should ever have to get caught off guard again.

One Click to Awesome: Deploying with the DigitalOcean Marketplace

David Flanagan (InfluxData) — Wed, 06 Mar 2019 13:40:32 -0700

We’re thrilled to announce that we’ve worked with DigitalOcean to bring the TICK Stack to their new Marketplace, providing all DigitalOcean users with a one-click TICK Stack.

Getting started

We’re going to assume you already have a DigitalOcean account. If you don’t, stop here and go sign-up.

Creating the droplet

From the DigitalOcean dashboard, we’re going to click “Marketplace” on the left-hand side menu. From there, you can then select “Monitoring” and you’ll see “InfluxDB TICK Stack”. Hover over the TICK Stack and click “Create Droplet”.

The TICK Stack runs great on DigitalOcean’s $5 droplet, so let’s start with that; you can increase capacity as you need later.

<figcaption> Select $5 droplet</figcaption>

Create the droplet! Once it’s ready, you’ll have a new item in your droplet list. It’ll show a blue loading bar until it’s ready, then you’ll see the IP address. ???? Boom! We’re almost there.

<figcaption> Wait for the IP address to be shown</figcaption>

Configuring Chronograf

After a minute, or two, Chronograf will be ready and listening on your droplet’s IP address. You can use your browser of choice and navigate to that IP. You’ll be presented with the Chronograf welcome page.

<figcaption> Chronograf Welcome Page</figcaption>

Click “Get Started” and it’ll ask for your InfluxDB configuration. You can get the credentials with the following command:

ssh -l root ip_address_of_droplet -C "cat ~/.digitalocean_password"

This should return something akin to:

influxdb_admin_username="admin"
influxdb_admin_password="01c59692c3409696bee7fb2d1b82a4a5c46da6b67e58b832"

Enter the username and password into the text fields and click “Add Connection”.

<figcaption> Chronograf Add Connection</figcaption>

We’ve already configured Telegraf on your droplet to ship metrics to InfluxDB, so you will be presented with the option to add a System dashboard.

<figcaption> Chronograf Add System Dashboard</figcaption>

Click “Create 1 Dashboard”, followed by “Continue” on the Kapacitor page and you’re all set!

Using Chronograf

After Telegraf has been collecting metrics for a few moments, you’ll be able to see data on your system dashboard and via the metric explorer.

<figcaption> Chronograf System Dashboard</figcaption>

Next steps

We cannot wait for you to get started with your own TICK Stack on top of DigitalOcean, but before you do, we have some final thoughts.

Securing Chronograf

Out of the box, Chronograf is not secured. We recommend that this is the first thing you configure. Chronograf can be configured with OAuth 2.0 authentication with many providers, including Google, GitHub, and GitLab. We also recommend enabling TLS with a LetsEncrypt certificate, as soon as you’ve added a CNAME record to your droplet.

Adding more metrics

You’re now free to configure Telegraf on other droplets or instrument your application to ship metrics to InfluxDB. You can create new users for this, rather than using admin via the Chronograf admin pages, or using the CLI.

Curious what Telegraf can ship to InfluxDB for you? Checkout our input plugin documentation.

We hope you enjoy our new one-click setup with DigitalOcean. Let us know what you think by tweeting us at @InfluxDB.