乐胖代购免代理版

MackerelのAWSインテグレーション設定のページから作成ボタンを押して、External IDを取得してください。許可するAccount IDには 217452466226 を入力してください。また、Require external ID のオプションを選択した上で、External IDにはMackerelの設定作成ページで取得したExternal IDを指定して下さい。このアカウントはMackerelのシステムがユーザーのロールにアクセスする際に利用するアカウントです。この設定により、作成されたロールにはMackerelのアカウントしかアクセスできない状態になります。Require MFA はチェックせずに次の設定ページに移動してください。

続いてポリシーの付与を行います。

1-b. Access Key IDとSecret Access Keyを設定する方法

以下の方法はセキュリティー保全の観点から推奨しておりません。

IAM Management Consoleにてユーザーを作成する

IAM Management Consoleにて新しいユーザーを作成します。 MackerelAWSIntegrationUser のようにMackerelのAWSインテグレーションで使用していることが分かりやすい名前を付けることを推奨します。

アクセスキーをMackerelに登録する

作成時の画面に表示されるAccess Key IDとSecret Access Keyを、Mackerelに登録します。登録するオーガニゼーションを間違えないようにご注意ください。

2. ポリシーを付与する

作成したIAMロールもしくはIAMユーザーに、連携に必要なポリシーを付与します。

必ず以下に列挙されたポリシーやアクションを使用し、FullAccess権限などを付与しないようにご注意ください。

またAWSの仕様で、ひとつのIAMロール／IAMユーザーに対してアタッチ可能なポリシーの上限は10個に制限されています。必要に応じて、AWSに対して上限緩和申請をおこなってください。

AWSインテグレーションで使用する全ての権限を設定する場合、AWSインテグレーションで使用するIAMポリシーの項目を参照下さい。

AWS製品	必要なポリシー／アクション	備考
EC2	AmazonEC2ReadOnlyAccess
ELB (CLB)	AmazonEC2ReadOnlyAccess
ALB	AmazonEC2ReadOnlyAccess
NLB	AmazonEC2ReadOnlyAccess
RDS	AmazonRDSReadOnlyAccess
ElastiCache	AmazonElastiCacheReadOnlyAccess
Redshift	AmazonRedshiftReadOnlyAccess
Lambda *1	AWSLambda_ReadOnlyAccess
SQS	AmazonSQSReadOnlyAccess
DynamoDB	AmazonDynamoDBReadOnlyAccess
CloudFront *1	CloudFrontReadOnlyAccess
API Gateway *1	`apigateway:GET`	リソースポリシーは`arn:aws:apigateway:ap-northeast-1::/*`などのように指定します。リソースポリシーで連携対象を制限することはできません。
Kinesis Data Streams *1	AmazonKinesisReadOnlyAccess
S3 *1	AmazonS3ReadOnlyAccess	S3側でバケットのリクエストメトリックを有効にする必要があります。 S3バケットにリクエストメトリックを設定する方法を参考に`EntireBucket`というフィルタ名で設定してください。
OpenSearch Service 1 2	AmazonOpenSearchServiceReadOnlyAccess
ECS *1	`ecs:Describe` `ecs:List`
SES *1	AmazonSESReadOnlyAccess `ses:Describe*`
Step Functions *1	AWSStepFunctionsReadOnlyAccess
EFS *1	AmazonElasticFileSystemReadOnlyAccess
Kinesis Data Firehose *1	AmazonKinesisFirehoseReadOnlyAccess
Batch *1	`batch:Describe` `batch:List`
WAF *1	AWSWAFReadOnlyAccess
Billing *1	AWSBudgetsReadOnlyAccess
Route 53 *1	AmazonRoute53ReadOnlyAccess
Connect *1	AmazonConnectReadOnlyAccess
DocumentDB	AmazonRDSReadOnlyAccess
CodeBuild *1	`codebuild:BatchGetProjects` `codebuild:ListProjects`
Athena *1	`athena:ListWorkGroups` `athena:ListTagsForResource`

*1 該当のAWS製品を単一で連携させる場合、必要なポリシー／アクションに加えてCloudWatchReadOnlyAccessが必要となります。

*2 以前のElasticsearch ServiceからAmazonESReadOnlyAccessを継続してご利用が可能です。

また、AWSインテグレーションでは後述するようにタグによって絞り込みを行うことが出来ますが、ElastiCacheやSQSでタグによる絞り込みを行う場合は追加のポリシーを付与する必要があります。詳しくはタグで絞り込むの項目を参照してください。

メトリックの除外を行う場合もAWSのタグを参照するため、タグで絞り込む機能と同様に追加のポリシーを付与する必要があります。詳しくは取得するメトリックを制限するの項目を参照してください。

3. ホストを確認する

しばらくすると、ご利用のAWSクラウド製品がMackerelにホストとして登録され、メトリックが投稿されます。監視ルールを作成し、アラートを通知することもできます。詳しくは監視・通知を設定するをご覧ください。

新規メトリックの自動追加を設定する

Mackerelでは、各AWSサービスの更新に伴って、新たなメトリックが追加されることがあります。

この「新規メトリックを自動的に追加する」をオンにすると、メトリックが追加されるつどAWSインテグレーション設定ページで取得対象として選択する手間を省けます。

AWSインテグレーションの利用料金は、連携しているホスト数と、1ホストあたりの上限を超えて投稿されているメトリック数によって決定します（参考：利用料金算出方法）。

予期せぬ利用料金の増加を避けたい場合は、「新規メトリックを自動的に追加する」をオフにします。以後追加されるメトリックは自動取得対象外となりますので、必要なメトリックを個別に選択してください。

自動退役を設定する

一部のサービスでは、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",
                "athena:ListWorkGroups",
                "athena:ListTagsForResource",
                "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:DescribeDomain",
                "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": "*"
        }
    ]
}

よくある質問

アクセスキーの権限チェックと CreateInternetGateway に関して

ユーザーが登録したアクセスキーが不必要に強い権限を持っていないかチェックするために、AWSインテグレーションは定期的に CreateInternetGateway API を dry-run にて実行しています。アクセスキーが必要以上の権限を持っていた場合には、メトリックの収集と投稿は行われませんのでご注意ください。チェックを登録後にも定期的におこなう理由は、アクセスキーに対してポリシーが追加され、権限が強くなってしまう可能性があるためです。

AWSインテグレーションにより連携したホストの退役について

上記の連携設定を行うことで、対象サービスとタグ条件に合致した AWS クラウド製品は自動的に Mackerel と連携されホストとして登録されます。一方で、サービスの設定で自動退役に対応していない・自動退役を無効にしている場合、AWS 側でインスタンスの削除などを行っただけでは、Mackerel 側のホストは削除（退役）されません。AWSインテグレーションにより連携したホストを Mackerel の監視対象から外すには、別途退役の作業を実施する必要があります。

mackerel.io

仮に退役作業をしない場合でも、ホスト情報が残り続けるだけで、メトリック投稿のないホストは課金対象にはなりません。

プラグインによる監視内容の連携ホストへの集約に関して

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 OpenSearch Service と check-elasticsearch プラグインを用いた OpenSearch 監視です。mackerel-agent.conf の設定に以下のように custom_identifier を含むプラグイン設定を追加することで、 OpenSearch Service クラスターのヘルスチェックを OpenSearch Service ホストのチェック監視として集約できます。

[plugin.checks.elasticsearch]
command = ["check-elasticsearch", "-s", "https", "-H", "OpenSearch Service のエンドポイント", "-p", "443"]
custom_identifier = "OpenSearch Service の ARN"