AWSインテグレーションを用いると、AWSクラウド製品をMackerelのホストとして管理し、メトリックを監視できます。本機能はTrialプランとStandardプランのみの提供となります。
AWSのクラウド製品1台が、Mackerelで1ホストとして登録され、Mackerelの課金対象のホスト数としてカウントされます。 ホストの種類は、EC2についてはスタンダードホスト、その他の製品についてはマイクロホストとなります。 また、5分ごとに取得対象となるメトリックの数だけAWSのAPIをコールして値を取得します。そのため、Amazon CloudWatch API利用の料金が発生する場合がありますのでご注意ください。 AWSのリソースを削除したとき、関連するMackerelのホストを自動的に退役したい場合は自動退役を設定するの項目を参照してください。 取得するメトリックを制限したい場合は取得するメトリックを制限するの項目を参照してください。
AWSインテグレーションは現在は以下のAWSクラウド製品に対応しています。取得メトリックなどについてはそれぞれのドキュメントを参照ください。
EC2・ELB (CLB)・ALB・NLB・RDS・ElastiCache・Redshift・Lambda・SQS・DynamoDB・CloudFront ・API Gateway ・Kinesis Data Streams・S3・Elasticsearch Service・ECS・SES・Step Functions・EFS・Kinesis Data Firehose・Batch・WAF・Billing・Route 53・Connect・DocumentDB・CodeBuild
連携方法
AWSインテグレーションの連携方法には2つの方法があります。
- MackerelのシステムのAWSアカウントからのアクセスのみを許可するIAMロールを設定し、AssumeRoleで認証する方法
- Access Key IDとSecret Access Keyを設定する方法
セキュリティー保全の観点から、IAMロールで設定する方法を強く推奨します。
IAMロールを設定する方法
1. IAM Management Consoleにてロールを作成する
IAM Management Consoleにて新しいロールを作成します。
ロールのタイプを選択する画面では「別のAWSアカウント」 (Another AWS account
) を選択します。
MackerelのAWSインテグレーション設定のページから作成ボタンを押して、External IDを取得してください。許可するAccount IDには 217452466226
を入力してください。また、Require external ID
のオプションを選択した上で、External IDにはMackerelの設定作成ページで取得したExternal IDを指定して下さい。このアカウントはMackerelのシステムがユーザーのロールにアクセスする際に利用するアカウントです。この設定により、作成されたロールにはMackerelのアカウントしかアクセスできない状態になります。Require MFA
はチェックせずに次の設定ページに移動してください。
ロールには以下のポリシーを付与します。 FullAccess権限を付与しないようにご注意ください。また、ひとつのIAMロールに対してアタッチ可能なポリシーの上限は10個に制限されており、これはAWSの仕様です。必要に応じて、AWSに対して上限緩和申請をおこなってください。
AWSインテグレーションで使用する全ての権限を設定する場合、AWSインテグレーションで使用するIAMポリシー の項目を参照下さい。
AmazonRedshiftReadOnlyAccess
AmazonEC2ReadOnlyAccess
AmazonElastiCacheReadOnlyAccess
AmazonRDSReadOnlyAccess
- RDS、またはDocumentDBの場合に指定します。
AWSLambda_ReadOnlyAccess
AmazonSQSReadOnlyAccess
AmazonDynamoDBReadOnlyAccess
CloudFrontReadOnlyAccess
apigateway:GET
- リソースポリシーは
arn:aws:apigateway:ap-northeast-1::/*
などのように指定します。リソースポリシーで対象を制限することはできません。
- リソースポリシーは
AmazonKinesisReadOnlyAccess
AmazonS3ReadOnlyAccess
AmazonESReadOnlyAccess
ecs:Describe* / ecs:List*
AmazonSESReadOnlyAccess / ses:Describe*
codebuild:BatchGetProjects / codebuild:ListProjects
AWSStepFunctionsReadOnlyAccess
AmazonElasticFileSystemReadOnlyAccess
AmazonKinesisFirehoseReadOnlyAccess
batch:Describe* / batch:List*
AWSWAFReadOnlyAccess
AWSBudgetsReadOnlyAccess
AmazonRoute53ReadOnlyAccess
AmazonConnectReadOnlyAccess
CloudWatchReadOnlyAccess
- 以下のサービスのみを設定する場合に指定します。
- CloudFront, API Gateway, Kinesis Data Streams, S3, Elasticsearch Service, ECS, SES, Step Functions, EFS, Kinesis Data Firehose, Batch, WAF, Billing, Route 53, Lambda, Connect, CodeBuild
- 以下のサービスのみを設定する場合に指定します。
また、AWSインテグレーションでは後述するようにタグによって絞り込みを行うことが出来ますが、ElastiCache、SQS、Step Functionsでタグによる絞り込みを行う場合は追加のポリシーを付与する必要があります。 詳しくはタグで絞り込む の項目を参照してください。
ロール名を指定してロールを作成します。
MackerelAWSIntegrationRole
のようにMackerelのAWSインテグレーションで使用していることが分かりやすい名前を付けることを推奨します。
2. ロールARNをMackerelに登録する
ロールARNを、先程External IDを取得したMackerelの画面で登録します。
3. ホストを確認する
しばらくすると、ご利用のAWSクラウド製品がMackerelにホストとして登録され、メトリックが投稿されます。 監視ルールを作成し、アラートを通知することもできます。 詳しくは監視・通知を設定するをご覧ください。
Access Key IDとSecret Access Keyを設定する方法
以下の方法はセキュリティー保全の観点から推奨しておりません。
1. IAM Management Consoleにてユーザーを作成する
IAM Management Consoleにて新しいユーザーを作成します。
MackerelAWSIntegrationUser
のようにMackerelのAWSインテグレーションで使用していることが分かりやすい名前を付けることを推奨します。
2. アクセスキーをMackerelに登録する
作成時の画面に表示されるAccess Key IDとSecret Access Keyを、Mackerelに登録します。 登録するオーガニゼーションを間違えないようにご注意ください。
3. ポリシーを付与する
作成したユーザーに、以下のポリシーを付与します。 FullAccess権限を付与しないようにご注意ください。また、ひとつのIAMユーザーに対してアタッチ可能なポリシーの上限は10個に制限されており、これはAWSの仕様です。必要に応じて、AWSに対して上限緩和申請をおこなってください。
AWSインテグレーションで使用する全ての権限を設定する場合、AWSインテグレーションで使用するIAMポリシー の項目を参照下さい。
AmazonRedshiftReadOnlyAccess
AmazonEC2ReadOnlyAccess
AmazonElastiCacheReadOnlyAccess
AmazonRDSReadOnlyAccess
- RDS、またはDocumentDBの場合に指定します。
AWSLambda_ReadOnlyAccess
AmazonSQSReadOnlyAccess
AmazonDynamoDBReadOnlyAccess
CloudFrontReadOnlyAccess
apigateway:GET
- リソースポリシーは
arn:aws:apigateway:ap-northeast-1::/*
などのように指定します。リソースポリシーで対象を制限することはできません。
- リソースポリシーは
AmazonKinesisReadOnlyAccess
AmazonS3ReadOnlyAccess
AmazonESReadOnlyAccess
ecs:Describe* / ecs:List*
AmazonSESReadOnlyAccess / ses:Describe*
codebuild:BatchGetProjects / codebuild:ListProjects
AWSStepFunctionsReadOnlyAccess
AmazonElasticFileSystemReadOnlyAccess
AmazonKinesisFirehoseReadOnlyAccess
batch:Describe* / batch:List*
AWSWAFReadOnlyAccess
AWSBudgetsReadOnlyAccess
AmazonRoute53ReadOnlyAccess
AmazonConnectReadOnlyAccess
CloudWatchReadOnlyAccess
- 以下のサービスのみを設定する場合に指定します。
- CloudFront, API Gateway, Kinesis Data Streams, S3, Elasticsearch Service, ECS, SES, Step Functions, EFS, Kinesis Data Firehose, Batch, WAF, Billing, Route 53, Lambda, Connect, CodeBuild
- 以下のサービスのみを設定する場合に指定します。
また、AWSインテグレーションでは後述するようにタグによって絞り込みを行うことが出来ますが、ElastiCacheやSQSでタグによる絞り込みを行う場合は追加のポリシーを付与する必要があります。 詳しくはタグで絞り込む の項目を参照してください。
メトリックの除外を行う場合もAWSのタグを参照するため、タグで絞り込む機能と同様に追加のポリシーを付与する必要があります。 詳しくは取得するメトリックを制限する の項目を参照してください。
4. ホストを確認する
しばらくすると、ご利用のAWSクラウド製品がMackerelにホストとして登録され、メトリックが投稿されます。 監視ルールを作成し、アラートを通知することもできます。 詳しくは監視・通知を設定するをご覧ください。
自動退役を設定する
一部のサービスでは、AWSリソースの削除に伴ってMackerelのホストを退役するオプションを提供しています。自動退役を有効にするには、設定画面で「自動退役を有効にする」にチェックを入れます。
AWSインテグレーションにおける自動退役は、Mackerelと連携しているリソースが削除されたと判断したとき、自動で関連するホストを退役するためのオプションです。そのため、以下の場合には自動退役を行いません。
- タグフィルタにより除外されているリソースが削除された
- ただし例外として、対象サービスがEC2の場合はタグで除外されていても退役します
- 過去に連携していたが、現在はインテグレーションの設定でサービスを無効にしている
- 過去に連携していたが、現在はインテグレーションの設定を削除している
また、AWSインテグレーションがAWSリソースの削除を検出した時点で1回だけ判定を行うため、削除の検出後に連携を有効にしても自動退役の対象となりません。複数のインテグレーション設定で同じホストを連携している場合は、どれか1つの設定で削除と判断された時点で自動退役します。
取得するメトリックを制限する
一部のメトリックを取得しないように設定して、ホスト数を削減したりCloudWatch APIの料金を減らす事ができます。
1. 取得するメトリックを制限するための権限を付与する
取得するメトリックを制限するためには、AWSインテグレーションの設定のために付与したポリシー以外に、以下のアクションに対する権限が追加で必要になります。
elasticache:ListTagsForResource
sqs:ListQueueTags
states:ListTagsForResource
これらのポリシーの付与は、Inline Policiesにて行ってください。
2. 取得するメトリックを制限する設定を行う
ホスト台数は過去一ヶ月分の移動平均での算出となります。詳しくはホスト数の計算方法についてをご確認ください。
Mackerelの設定画面で取得するメトリックを選択します。不要なメトリックのチェックを外して、保存してください。
例えばKinesis Data Streamsのkinesis.latency.#.minimum
を取得しないようにする場合は以下のようにチェックボックスを外します。この設定によりGetRecords.Latency
、PutRecord.Latency
、PutRecords.Latency
それぞれのminimumの取得を制限し、最大で3メトリックを削減します。
タグで絞り込む
ホストとして登録してメトリックを取得するAWSクラウド製品を、AWSで付与しているタグで絞り込めます。
1. タグを取得するための権限を付与する
AWSのタグで絞り込むには、AWSインテグレーションの設定のために付与したポリシー以外に、以下のアクションに対する権限が追加で必要になります。
elasticache:ListTagsForResource
sqs:ListQueueTags
states:ListTagsForResource
これらのポリシーの付与は、Inline Policiesにて行ってください。
2. タグで絞り込む設定を行う
Mackerelの設定画面でタグを指定します。連携ホスト数を確認し、保存してください。
タグをservice:foo, service:bar
のように指定すると、キーがserviceで値がfooまたはキーがserviceで値がbarであるタグが付与されているインスタンスが対象となります。
キーや値にコロン :
やカンマ ,
などを含む場合は、クォート ("
または '
) で囲ってください。例えば、キーがservice:role
で値がfoo,bar
である場合は、"service:role": "foo,bar"
のように指定します。
タグの値からサービス・ロールを割り当てる
各AWSリソースに mackerel-integration
タグを付与しておくと、AWSインテグレーションがメトリックを取得するときに自動でロールを割り当てます。タグの書式は以下の通りです。
- Key:
mackerel-integration
- Value:
<Service>:<Role> [ / <Service>:<Role> ...]
複数のロールを割り当てたい場合は、/
で区切って必要なだけ記述してください。ここで設定したサービス・ロールがMackerelに存在しない場合は、AWSインテグレーションが必要なサービス・ロールを作成します。
ElastiCache、SQSでタグによるサービス・ロール割り当てを行う場合は追加のポリシーを付与する必要があります。詳しくはタグで絞り込むの「タグを取得するための権限を付与する」を参照してください。
また、mackerel-integration
タグを設定したホストでは、MackerelのWebコンソールで設定したデフォルトロールの割り当ては行われません。
タグの設定が反映されない場合
タグの内容がロールに反映されない場合は、以下の項目に該当するかご確認ください。
- タグに設定したサービス・ロール名に不正な文字がないか
- 利用できる文字はMackerelのサービス・ロールに使える文字と同等です
- タグを追加したAWSサービスが
mackerel-integration
に対応しているかmackerel-integration
への対応は随時行っていきます- 対応状況は各インテグレーションのドキュメントを参照ください
なお、ホストにロールを反映するまで数時間いただくことがあります。
AWS インテグレーションで使用するIAMポリシー
以下の権限リストはAWSインテグレーションで使用する全ての権限を指定しています。 独自のポリシーを作成してアタッチを行うか、Inline Policiesにて指定します。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "apigateway:Get*", "application-autoscaling:DescribeScalableTargets", "batch:Describe*", "batch:ListJobs", "budgets:ViewBudget", "cloudfront:Get*", "cloudfront:List*", "cloudwatch:Get*", "cloudwatch:List*", "codebuild:BatchGetProjects", "codebuild:ListProjects", "connect:ListInstances", "dynamodb:Describe*", "dynamodb:List*", "ds:DescribeDirectories", "ec2:DescribeInstances", "ecs:DescribeClusters", "ecs:List*", "elasticache:Describe*", "elasticache:ListTagsForResource", "elasticfilesystem:Describe*", "elasticloadbalancing:Describe*", "es:DescribeElasticsearchDomain", "es:List*", "firehose:DescribeDeliveryStream", "firehose:List*", "kinesis:Describe*", "kinesis:List*", "lambda:GetFunctionConfiguration", "lambda:List*", "rds:Describe*", "rds:ListTagsForResource", "redshift:Describe*", "route53:List*", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketLogging", "s3:GetBucketTagging", "s3:GetEncryptionConfiguration", "s3:GetMetricsConfiguration", "ses:DescribeActiveReceiptRuleSet", "ses:GetSendQuota", "ses:ListIdentities", "sqs:GetQueueAttributes", "sqs:List*", "states:DescribeStateMachine", "states:List*", "waf-regional:Get*", "waf-regional:List*", "waf:Get*", "waf:List*", "wafv2:GetWebACL", "wafv2:List*" ], "Effect": "Allow", "Resource": "*" } ] }
FAQ
アクセスキーの権限チェックと CreateInternetGateway に関して
ユーザーが登録したアクセスキーが不必要に強い権限を持っていないかのチェックのために、AWSインテグレーションは定期的に CreateInternetGateway API を dry-run にて実行しています。アクセスキーが必要以上の権限を持っていた場合には、メトリックの収集と投稿は行われませんのでご注意ください。チェックを登録後にも定期的におこなう理由は、アクセスキーに対してポリシーが追加され、権限が強くなってしまう可能性があるためです。
AWSインテグレーションにより連携したホストの退役について
上記の連携設定を行うことで、対象サービスとタグ条件に合致した AWS クラウド製品は自動的に Mackerel と連携されホストとして登録されます。一方で、サービスの設定で自動退役に対応していない・自動退役を無効にしている場合、AWS 側でインスタンスの削除などを行っただけでは、Mackerel 側のホストは削除(退役)されません。AWSインテグレーションにより連携したホストを Mackerel の監視対象から外すには、別途退役の作業を実施する必要があります。
仮に退役作業をしない場合でも、ホスト情報が残り続けるだけで、メトリック投稿のないホストは課金対象にはなりません。
プラグインによる監視内容の連携ホストへの集約に関して
mackerel-agent のカスタムメトリックとチェック監視の plugin 設定には、custom_identifier
を指定できます。custom_identifier
とは、ホストの識別子としてユーザー独自の identifier を付与するための仕組みです。これを利用して、別のマシンにインストールした mackerel-agent から投稿されたメトリックやチェック監視を、AWSインテグレーション連携ホストの物として集約できます。custom_identifier
は、対応するプラグイン設定に指定します。
例えば Amazon RDS の場合はそのエンドポイントが、ELB の場合は DNS Name が、それぞれ custom_identifier
文字列となります。
利用例
以下にふたつの利用例を紹介します。いずれの場合も、mackerel-agent の設定ファイルへの追記後はエージェントの再起動が必要です。
ひとつめの例は、Amazon RDS に対する mackerel-plugin-mysql プラグインを用いた MySQL 監視です。mackerel-agent.conf の設定に以下のように custom_identifier
を含むプラグイン設定を追加することで、プラグインで取得したメトリックをRDSホストのカスタムメトリックとして集約できます。
[plugin.metrics.mysql] command = ["mackerel-plugin-mysql", "-host", "RDSのエンドポイント", "-username", "user", "-password", "pass"] custom_identifier = "RDSのエンドポイント"
ふたつめの例は、 Amazon Elasticsearch Service と check-elasticsearch プラグインを用いた Elasticsearch 監視です。mackerel-agent.conf の設定に以下のように custom_identifier
を含むプラグイン設定を追加することで、 Elasticsearch Service クラスターのヘルスチェックを Elasticsearch Service ホストのチェック監視として集約できます。
[plugin.checks.elasticsearch] command = ["check-elasticsearch", "-s", "https", "-H", "Elasticsearch Service のエンドポイント", "-p", "443"] custom_identifier = "Elasticsearch Service の ARN"