Amazon Managed Grafana での Athena の使用
このレシピでは、Amazon Athena(標準 SQL を使用して Amazon S3 のデータを分析できるサーバーレスの対話型クエリサービス)を Amazon Managed Grafana で使用する方法を紹介します。この統合は、Grafana 用 Athena データソース(オープンソースのプラグイン)によって実現されており、任意の DIY Grafana インスタンスで使用できるだけでなく、Amazon Managed Grafana にもプリインストールされています。
このガイドは約 20 分で完了します。
前提条件
インフラストラクチャ
まず、必要なインフラストラクチャをセットアップしましょう。
Amazon Athena のセットアップ
Athena を 2 つの異なるシナリオで使用する方法を見ていきます。1 つは地理データと Geomap プラグインに関するシナリオで、もう 1 つは VPC フローログに関するセキュリティ関連のシナリオです。
まず、Athena がセットアップされ、データセットがロードされていることを確認しましょう。
これらのクエリを実行するには、Amazon Athena コンソールを使用する必要があります。Grafana は一般的にデータソースへの読み取り専用アクセスを持つため、データの作成や更新には使用できません。
地理データの読み込み
この最初のユースケースでは、AWS オープンデータレジストリ からのデータセットを使用します。 具体的には、地理データに関連するユースケースにおける Athena プラグインの使用方法を示すために、OpenStreetMap (OSM) を使用します。 そのためには、まず OSM データを Athena に取り込む必要があります。
まず、Athena で新しいデータベースを作成します。Athena コンソール に移動し、以下の 3 つの SQL クエリを使用して OSM データをデータベースにインポートします。
クエリ 1:
CREATE EXTERNAL TABLE planet (
id BIGINT,
type STRING,
tags MAP<STRING,STRING>,
lat DECIMAL(9,7),
lon DECIMAL(10,7),
nds ARRAY<STRUCT<ref: BIGINT>>,
members ARRAY<STRUCT<type: STRING, ref: BIGINT, role: STRING>>,
changeset BIGINT,
timestamp TIMESTAMP,
uid BIGINT,
user STRING,
version BIGINT
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/planet/';
クエリ 2:
CREATE EXTERNAL TABLE planet_history (
id BIGINT,
type STRING,
tags MAP<STRING,STRING>,
lat DECIMAL(9,7),
lon DECIMAL(10,7),
nds ARRAY<STRUCT<ref: BIGINT>>,
members ARRAY<STRUCT<type: STRING, ref: BIGINT, role: STRING>>,
changeset BIGINT,
timestamp TIMESTAMP,
uid BIGINT,
user STRING,
version BIGINT,
visible BOOLEAN
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/planet-history/';
クエリ 3:
CREATE EXTERNAL TABLE changesets (
id BIGINT,
tags MAP<STRING,STRING>,
created_at TIMESTAMP,
open BOOLEAN,
closed_at TIMESTAMP,
comments_count BIGINT,
min_lat DECIMAL(9,7),
max_lat DECIMAL(9,7),
min_lon DECIMAL(10,7),
max_lon DECIMAL(10,7),
num_changes BIGINT,
uid BIGINT,
user STRING
)
STORED AS ORCFILE
LOCATION 's3://osm-pds/changesets/';
VPC フローログデータの読み込み
2 つ目のユースケースはセキュリティに関連するものです。VPC フローログ を使用してネットワークトラフィックを分析します。
まず、EC2 に VPC フローログを生成するよう指示する必要があります。まだ行っていない場合は、VPC フローログを作成 してください。ネットワークインターフェースレベル、サブネットレベル、または VPC レベルのいずれかで作成できます。
クエリのパフォーマンスを向上させ、ストレージの使用量を最小限に抑えるため、VPC フローログはネストされたデータをサポートする列指向ストレージ形式である Parquet で保存します。
今回のセットアップでは、以下に示すように Parquet 形式で S3 バケットに公開する限り、どのオプショ ン(ネットワークインターフェース、サブネット、または VPC)を選択しても問題ありません。
次に、Athena コンソール を使用して、OSM データをインポートしたのと同じデータベース内に VPC フローログデータのテーブルを作成します。または、必要に応じて新しいデータベースを作成してもかまいません。
以下の SQL クエリを使用し、VPC_FLOW_LOGS_LOCATION_IN_S3
を自分のバケット/フォルダに置き換えてください。
CREATE EXTERNAL TABLE vpclogs (
`version` int,
`account_id` string,
`interface_id` string,
`srcaddr` string,
`dstaddr` string,
`srcport` int,
`dstport` int,
`protocol` bigint,
`packets` bigint,
`bytes` bigint,
`start` bigint,
`end` bigint,
`action` string,
`log_status` string,
`vpc_id` string,
`subnet_id` string,
`instance_id` string,
`tcp_flags` int,
`type` string,
`pkt_srcaddr` string,
`pkt_dstaddr` string,
`region` string,
`az_id` string,
`sublocation_type` string,
`sublocation_id` string,
`pkt_src_aws_service` string,
`pkt_dst_aws_service` string,
`flow_direction` string,
`traffic_path` int
)
STORED AS PARQUET
LOCATION 'VPC_FLOW_LOGS_LOCATION_IN_S3'
例えば、S3 バケット allmyflowlogs
を使用している場合、VPC_FLOW_LOGS_LOCATION_IN_S3
は以下のようになります。
s3://allmyflowlogs/AWSLogs/12345678901/vpcflowlogs/eu-west-1/2021/