commit
eeeec78dab
|
@ -109,6 +109,11 @@ location = portland, scientist = mullen
|
|||
Because tags are indexed, queries on tags are faster than queries on fields. This makes tags ideal for storing commonly-queried metadata.
|
||||
{{% /note %}}
|
||||
|
||||
{{% note %}}
|
||||
Tags containing highly variable information like UUIDs, hashes, and random strings will lead to a large number of unique series in the database, known as **high series cardinality**. High series cardinality is a primary driver of high memory usage for many database workloads. See [series cardinality](v2.0/reference/glossary/#series-cardinality) for more information.
|
||||
{{% /note %}}
|
||||
|
||||
|
||||
#### Why your schema matters
|
||||
|
||||
If most of your queries focus on values in the fields, for example, a query to find when 23 bees were counted:
|
||||
|
|
|
@ -14,3 +14,26 @@ aliases:
|
|||
Create, edit, and manage dashboards from the **Dashboards** tab in the left navigation.
|
||||
|
||||
{{< children >}}
|
||||
|
||||
|
||||
## View your dashboard ID
|
||||
|
||||
Use the InfluxDB UI or `influx` CLI to view your dashboard ID.
|
||||
|
||||
### Dashboard ID in the UI
|
||||
|
||||
When viewing a dashboard in the InfluxDB UI, your dashboard ID appears in the URL.
|
||||
|
||||
<pre class="highlight">
|
||||
http://localhost:9999/orgs/03a2bbf46249a000/dashboards/<span class="bp" style="font-weight:bold;margin:0 .15rem">04b6b15034cc000</span>/...
|
||||
</pre>
|
||||
|
||||
### Dashboard ID in the CLI
|
||||
Use [`influx dashboards`](/v2.0/reference/cli/influx/dashboards/) to view a list of dashboards and IDs.
|
||||
|
||||
```sh
|
||||
> influx dashboards
|
||||
ID Name
|
||||
03a2bbf46249a000 dashboard-1
|
||||
03ace3a859669000 dashboard-2
|
||||
```
|
||||
|
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
title: Third-party technologies
|
||||
seotitle: Write data with third-party technologies
|
||||
list_title: Write data with third-party technologies
|
||||
weight: 103
|
||||
description: >
|
||||
Write data to InfluxDB using third-party developer tools.
|
||||
aliases:
|
||||
menu:
|
||||
v2_0:
|
||||
name: Third-party developer tools
|
||||
parent: Developer tools
|
||||
---
|
||||
|
||||
Configure third-party technologies to send line protocol directly to InfluxDB.
|
||||
|
||||
## AWS Lambda via CloudFormation template
|
||||
|
||||
Write to InfluxDB with AWS Lambda, Amazon Web Services' serverless offering. This example provides a CloudFormation template that collects earthquake from the [United States Geological Survey (USGS)](https://www.usgs.gov/) every hour and outputs it as line protocol into an InfluxDB bucket.
|
||||
|
||||
The [template](https://influxdata-lambda.s3.amazonaws.com/GeoLambda.yml) contains the following sections:
|
||||
|
||||
- Lines 1-20: Define variables that the template asks for when it's installed.
|
||||
- Lines 21-120: Handle a quirk of Lambda deployments that requires the Lambda assets to be in your region before deployment. As there is no elegant workaround, these 100 lines create an S3 bucket in your account in the region you're creating the stack and copies in these resources.
|
||||
- Lines 121-132: Define a role with basic permission to run the Lambda.
|
||||
- Lines 133-144: Define a Python library layer. This layer packages the Python HTTP library, a Python S2 Geometry library, and the InfluxDB Python client library.
|
||||
- Lines 145-165: Define the Lambda function, a short Python script zipped up in a file called `geo_lambda.zip`.
|
||||
- Lines 166-188: Define an event rule with permission to run the Lambda every hour.
|
||||
|
||||
### Deploy the template
|
||||
|
||||
1. Log into your free AWS account and search for the CloudFormation service. Make sure you’re in the AWS region you want to deploy the Lambda to.
|
||||
2. Click **Create Stack**.
|
||||
3. In the **Prerequisite - Prepare Template** section, select **Template is ready**.
|
||||
4. In the **Specify template** section:
|
||||
- Under **Template source**, select **Amazon S3 URL**.
|
||||
- In the **Amazon S3 URL** field, enter the CloudFormation template URL: `https://influxdata-lambda.s3.amazonaws.com/GeoLambda.yml`
|
||||
5. Click **Next**.
|
||||
6. Enter a name in the **Stack name** field.
|
||||
7. Enter the following InfluxDB details:
|
||||
- Organization ID
|
||||
- Bucket ID of the bucket the Lambda writes to
|
||||
- Token with permission to write to the bucket
|
||||
- InfluxDB URL
|
||||
8. Do not alter or add to any other fields. Click **Next**.
|
||||
9. Select the **I acknowledge that AWS CloudFormation might create IAM resources** check box.
|
||||
10. Click **Create Stack**.
|
||||
|
||||
After a few minutes, the stack deploys to your region. To view the new Lambda, select **Services > AWS Lambda**. On the Lambda functions page, you should see your new Lambda. The `CopyZipsFunction` is the helper copy function, and the `GeoPythonLambda` does the data collection and writing work:
|
||||
|
||||
{{< img-hd src="static/img/influxdb/cloudformation1.png" alt="GeoPythonLambda data in InfluxDB" />}}
|
||||
|
||||
### Verify your setup
|
||||
|
||||
`GeoPythonLambda` should run every hour based on the AWS Rule we set up, but you should test and confirm it works.
|
||||
|
||||
1. Click `GeoPythonLambda`, and then click **Test**.
|
||||
2. The test requires an input definition, but this Lambda has no input requirements, so click through and save the default dataset.
|
||||
3. If the test is successful, a green **Execution result: succeeded** message appears.
|
||||
|
||||
With the data points written, when you log into your InfluxDB UI, you’ll be able to explore the geolocation earthquake data:
|
||||
|
||||
{{< img-hd src="static/img/influxdb/cloudformation2.png" alt="GeoPythonLambda data in InfluxDB" />}}
|
|
@ -18,7 +18,7 @@ A number of third-party technologies can be configured to send line protocol dir
|
|||
|
||||
If you're using any of the following technologies, check out the handy links below to configure these technologies to write data to InfluxDB (**no additional software to download or install**):
|
||||
|
||||
- (Write metrics only) [Vector 0.9 or later](#configure-vector)
|
||||
- (Write metrics and log events only) [Vector 0.9 or later](#configure-vector)
|
||||
|
||||
- [Apache NiFi 1.8 or later](#configure-apache-nifi)
|
||||
|
||||
|
@ -30,9 +30,13 @@ If you're using any of the following technologies, check out the handy links bel
|
|||
|
||||
#### Configure Vector
|
||||
|
||||
1. On the Vector.dev docs site, see the [InfluxDB Metrics Sink](https://vector.dev/docs/reference/sinks/influxdb_metrics/) page.
|
||||
1. View the **Vector documentation**:
|
||||
- For write metrics, [InfluxDB Metrics Sink](https://vector.dev/docs/reference/sinks/influxdb_metrics/)
|
||||
- For log events, [InfluxDB Logs Sink](https://vector.dev/docs/reference/sinks/influxdb_logs/)
|
||||
2. Under **Configuration**, click **v2** to view configuration settings.
|
||||
3. Scroll down to [How It Works](https://vector.dev/docs/reference/sinks/influxdb_metrics/#how-it-works) for more detail.
|
||||
3. Scroll down to **How It Works** for more detail:
|
||||
- [InfluxDB Metrics Sink – How It Works ](https://vector.dev/docs/reference/sinks/influxdb_metrics/#how-it-works)
|
||||
- [InfluxDB Logs Sink – How It Works](https://vector.dev/docs/reference/sinks/influxdb_logs/#how-it-works)
|
||||
|
||||
#### Configure Apache NiFi
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ To retrieve data from the Citi Bike URL endpoint, enable the `inputs.http` input
|
|||
Specify the following options:
|
||||
|
||||
### `urls`
|
||||
One or more URLs to read metrics from. For this example, use `https://feeds.citibikenyc.com/stations/stations.json`.
|
||||
One or more URLs to read metrics from. For this example, use `https://gbfs.citibikenyc.com/gbfs/en/station_status.json`.
|
||||
|
||||
### `data_format`
|
||||
The format of the data in the HTTP endpoints that Telegraf will ingest. For this example, use JSON.
|
||||
|
|
Binary file not shown.
After Width: | Height: | Size: 160 KiB |
Binary file not shown.
After Width: | Height: | Size: 100 KiB |
Loading…
Reference in New Issue