AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post

CloudWatch がインストールされている EC2 インスタンスでの、一般的なアクセス許可エラーをトラブルシューティングする方法を教えてください。

所要時間5分
0

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでの Amazon CloudWatch に関する、一般的なアクセス許可エラーをトラブルシューティングしたいです。

簡単な説明

Amazon EC2 インスタンスで最も一般的な CloudWatch アクセス許可エラーを次に示します。

  • AWS Identity and Access Management (IAM) ロールがアタッチされていない
  • アタッチされている IAM ロールにアクセス許可がない
  • CloudWatch サービスエンドポイントにアクセスできない
  • プロファイルの関連付け状態が停止している
  • 認証情報が正しく設定されていない
  • メタデータ情報の取得に失敗した
  • 証明書バンドルが欠けている

解決策

IAM ロールがアタッチされていない

IAM ロールがアタッチされていないと、CloudWatch のログファイル amazon-cloudwatch-agent.log に次のエラーが示される場合があります。

「セッションから認証情報を取得できませんでした。 NoCredentialProviders: チェーンに有効なプロバイダーがありません。理由: EnvAccessKeyNotFound: 環境内で認証情報が見つかりませんでした。」

CloudWatch エージェントを実行するには、インスタンスが IAM ロールに正しく関連付けられていることを確認してください。AWS マネージドポリシー CloudWatchAgentServerPolicy を使用して、各サーバーが CloudWatch エージェントを実行するために必要な IAM ロールを作成します。エージェントが CloudWatch Logs にログを送信していて、ロググループの保持ポリシーを設定する場合は、アクセス許可 logs:PutRetentionPolicy をロールに追加します。

詳細については、「CloudWatch エージェントで使用する IAM ロールとユーザーを作成する」を参照してください。

アタッチされている IAM ロールにアクセス許可がない

アタッチされた IAM ロールで、CloudWatch エージェント用の次のアクセス許可が含まれていることを確認してください。

"Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "ec2:DescribeVolumes",
                "ec2:DescribeTags",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams",
                "logs:DescribeLogGroups",
                "logs:CreateLogStream",
                "logs:CreateLogGroup",
                "logs:PutRetentionPolicy",
                "xray:PutTraceSegments",
                "xray:PutTelemetryRecords",
                "xray:GetSamplingRules",
                "xray:GetSamplingTargets",
                "xray:GetSamplingStatisticSummaries"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetParameter"
            ],
            "Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
        }
    ]
}

CloudWatch サービスエンドポイントにアクセスできない

サービスエンドポイントへの接続は、インターネット接続または Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを介して確立できます。メトリクスとログを送信するには、CloudWatch エージェントは特定の CloudWatch サービスエンドポイントとの接続を維持する必要があります。

  • メトリクスの場合、CloudWatch エージェントにはサービスエンドポイント https://ec2.example-region.amazonaws.com および **https://monitoring.example-region.amazonaws.com ** との接続が必要です。
  • ログの場合、CloudWatch エージェントにはサービスエンドポイント https://logs.example-region.amazonaws.com との接続が必要です。

CloudWatch サービスエンドポイントにアクセスできない場合、CloudWatch エージェントのログファイル amazon-cloudwatch-agent.log に次のエラー (またはそれに類似したエラー) が示される場合があります。

"2023-12-30T02:56:37Z W! {"caller":"ec2tagger/ec2tagger.go:485","msg":"ec2tagger: Unable to describe ec2 tags for initial retrieval (初期取得用の EC2 タグを記述できません)","kind":"processor","name":"ec2tagger","pipeline":"metrics/host","error":"RequestError: send request failed (リクエストの送信に失敗しました)\caused by: (理由) Post \"https://ec2.us-west-1.amazonaws.com/\": dial tcp 176.32.118.30:443: i/o timeout"}"

接続されていない Amazon EC2 インスタンスからメトリクスをプッシュするには、NAT ゲートウェイを設定するか、Amazon VPC エンドポイントを作成します。Amazon VPC エンドポイントを作成する場合は、必ず接続をテストしてください。また、CloudWatch にアクセスするアベイラビリティーゾーンごとに、サブネットを 1 つ選択します。

注: NAT ゲートウェイを設定したり、Amazon VPC エンドポイントを作成したりすると、追加料金が発生します。詳細については、「AWS PrivateLink の料金」と「Amazon VPC の料金」を参照してください。

プロファイルの関連付け状態が停止している

プロファイルの関連付け状態は、インスタンスプロファイルを更新したときに、あるロールの関連付けが解除され、別のロールが関連付けられる際に停止することがあります。古いロールの関連付けが完全に解除されない場合、プロファイルの関連付け状態が停止します。

インスタンスの関連付けを一覧表示するには、次のコマンドを実行します。

注: example-instance-id を必要なインスタンス ID に、example-region を必要な AWS リージョンに置き換えます。

$ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=example-instance-id --region example-region

出力例:

{
    "IamInstanceProfileAssociations": [
        {
            "AssociationId": "iip-assoc-aaaaaaaaa",
            "InstanceId": "i-08c9a2ccvssdfgge",
            "IamInstanceProfile": {
                "Arn": "arn:aws:iam::1234567890:instance-profile/CloudWatch_Monitoring",
                "Id": "AIPAdddddsgggggg"
            },
            "State": "disassociating"
        },
        {
            "AssociationId": "iip-assoc-bbbbbbb",
            "InstanceId": "i-08c9a2ccvssdfgge",
            "IamInstanceProfile": {
                "Arn": "arn:aws:iam::1234567890:instance-profile/Grafana",
                "Id": "AIPA3gggdddddddgg"
            },
            "State": "associating"
        }
        ]
    }

停止したプロファイルの関連付け状態を解決するには、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用します。

AWS マネジメントコンソールを使用する

  1. IAM ロールをインスタンスからデタッチします。
  2. IAM ロールをインスタンスに再アタッチします。

AWS CLI を使用する

**注:**AWS CLI のコマンドの実行時にエラーが発生する場合は、「AWS CLI エラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

  1. すべての関連付けを 1 つずつ解除します。関連付け解除を行う関連付けごとに、次のコマンドを実行します。
    注: example-association-id は、関連付け解除を行う関連付け ID に置き換えてください。

    $ aws ec2 disassociate-iam-instance-profile --association-id example-association-id

  2. インスタンスプロファイルの関連付けを一覧表示して、必要な関連付けがすべて解除されていることを確認します。
    注: example-instance-id を必要なインスタンス ID に、example-region を必要な AWS リージョンに置き換えます。

    $ aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=example-instance-id --region example-region

  3. IAM プロファイルをアタッチします。
    注: example-instance-id を必要なインスタンス ID に、example-profile-name を必要なプロファイル名に置き換えます。

    aws ec2 associate-iam-instance-profile \
    --instance-id example-instance-id \
    --iam-instance-profile Name=example-profile-name

認証情報が正しく設定されていない

CloudWatch エージェントは、次の種類の認証情報を順番に検索します。

  • env
  • assume-role
  • assume-role-with-web-identity
  • sso
  • shared-credentials-file
  • custom-process
  • config-file
  • ec2-credentials-file
  • boto-config
  • container-role
  • iam-role

注: iam-role の認証情報は、CloudWatch エージェントが検索する認証情報リストの最後にあります。iam-role の前に他の認証情報が見つかった場合、iam-role の認証情報は使用されません。

どの認証情報が使用されているかを確認するには、インスタンスに対し次のコマンドを実行します。

$ aws sts get-caller-identity --debug

iam-role の認証情報が使用されない問題を解決するには、検出した認証情報に適切なポリシーをアタッチするか、検出した認証情報を削除します。検出された認証情報を削除すると、**iam-role ** の認証情報がプライマリ認証情報になります。

メタデータ情報の取得に失敗した

CloudWatch エージェントがメタデータ情報を取得できない場合、ログファイル amazon-cloudwatch-agent.log に EC2MetadataError が記録されることがあります。このエラーを解決するには、次の手順を実行してください。

メタデータのアクセシビリティを確認する

  • メタデータのアクセシビリティを確認するには、次のコマンドを実行します。

    ```bash
     curl http://169.254.169.254/latest/meta-data/iam/security-credentials
     curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
     curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials
     curl http://169.254.169.254/latest/meta-data
     ```

  • 異なるメタデータバージョンに対しては、次のコマンドを実行します。
    IMDSv1:

    wget -q -O - http://169.254.169.254/latest/meta-data/instance-id  
curl http://169.254.169.254/

    IMDSv2:

    TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/

ネットワーク設定を確認する

ルートテーブルをチェックして、メタデータの IP アドレス 169.254.169.254 に対するルートが作成されていないことを確認します。

  • Linux の場合は、次のコマンドを実行します。
    OS カーネルレベルのルートテーブルを確認します。

    sudo route -n
netstat -rn
ip route list

    ファイアウォールを確認します。

    sudo iptables -L

    ルートがない場合は、カーネルレベルのルートテーブルにルートを追加します。
    注: example-gateway は、必要なゲートウェイに置き換えてください。

    sudo ip route add 169.254.169.254 via <example-gateway>

  • Windows の場合は、以下のコマンドを実行します。
    ルートテーブルを確認します。

    ipconfig /all
route print

    ルートがない場合は、静的ルートを追加します。
    注: example-gateway は、必要なゲートウェイ IP アドレスに置き換えてください。

    route -p ADD 169.254.169.251 MASK 255.255.255.255 <gateway-ip>
       route -p ADD 169.254.169.250 MASK 255.255.255.255 <example-gateway>
       route -p ADD 169.254.169.254 MASK 255.255.255.255 <example-gateway>
       route -p ADD 169.254.169.249 MASK 255.255.255.255 <example-gateway>
       route -p ADD 169.254.169.123 MASK 255.255.255.255 <example-gateway>
       route -p ADD 169.254.169.253 MASK 255.255.255.255 <example-gateway>

IMDS の PUT レスポンスのホップ制限を確認する

デフォルトでは、HttpPutResponseHopLimit は 1 に設定されています。これにより、パケットは 1 つのルーターまたはホップでのみ転送され、リクエストはインスタンスのローカルネットワーク内に留まることができます。次のような場合は、ホップ制限を調整します。

  • 複数のネットワークホップを通過する IMDS リクエストがある場合は、HttpPutResponseHopLimit を調整します。
  • Amazon EC2 インスタンスでコンテナオーケストレーションシステムを使用していて、メタデータサービスリクエストに追加のホップが発生している場合は、ホップ制限を調整します。コンテナが引き続き IMDS にアクセスできるように、ホップ制限を調整します。
  • 検査やログ記録を行うために、特定のネットワークパスを経由してリクエストを転送またはルーティングする場合は、ホップ制限を調整します。
  • IMDS へのアクセス時にネットワークの問題が原因で障害が発生した場合は、診断を行うためにホップ制限を調整します。トラブルシューティングが完了したら、必ずホップ制限値をロールバックしてください。

プロキシ設定を確認する

プロキシ設定により、CloudWatch エージェントがメタデータ情報を取得できなくなる場合があります。プロキシが設定されている場合は、common-config.toml を適切なプロキシ値で更新します。

プロキシ設定の例:

```toml
   [proxy]
   # http_proxy = "{example-http-url}"
   # https_proxy = "{example-https-url}"
   no_proxy = "169.254.169.254"

IMDSv2 とのバージョン互換性を確認する

CloudWatch エージェント 1.23 よりも前のバージョンは IMDSv2 をサポートしていません。古いバージョンの CloudWatch エージェントを実行している場合は、CloudWatch エージェントを最新バージョンに更新してください。

CloudWatch エージェントのバージョンを確認するには、次のコマンドを実行します。

Linux の場合:

```bash
     sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
     ```

Windows の場合:

```powershell
     & $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
     ```

CloudWatch エージェントがオンプレミスで実行されていると想定しているかどうかを確認する

CloudWatch エージェントが Amazon EC2 Docker コンテナにインストールされていて、メタデータ情報を取得できない場合、エージェントはオンプレミスで実行されていると想定して動作します。次のエラーが発生する場合があります。

「2023/05/19 11:43:50 I! ECS タスクのメタデータへのアクセスが失敗しました。http://169.254.170.2/v2/metadata から応答を取得できません。エラー: Get "http://169.254.170.2/v2/metadata": コンテキストの期限を超過しました (ヘッダーの待機中に Client.Timeout を超過)。ECS で実行中ではないと見なしています。
I! インスタンスが OnPremise であることを検出しました」

このエラーは、CloudWatch エージェントが Linux マシンの /root/.aws/credentials パスにある認証情報を検索しようとしてタイムアウトになった場合に発生します。このタイムアウトは、エージェントが Amazon EC2 ではなく Amazon Elastic Container Service (Amazon ECS) のメタデータエンドポイントの IP に接続しようとしたときに発生します。これを解決するには、次のいずれかを実行します。

  • 基盤となる OS にインストールされているフルバージョンの CloudWatch エージェントを使用してください。こうすることで、クラスターの設定をバイパスできます。
  • CloudWatch Container Insights で CloudWatch エージェントの OnPremise オプションを使用し、正しい AWS 認証情報が指定されていることを確認します。これにより、Amazon ECS エンドポイントへのメタデータ呼び出しが防止されます。

証明書バンドルが欠けている

証明書バンドルに必要な Amazon ルート証明書が含まれていない場合、Amazon EC2 クライアントで信頼の問題が発生します。CloudWatch エージェントログファイルに次のエラーが示される場合があります。

"caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed 2023-08-08T17:24:10Z E! refresh EC2 Instance Tags failed: RequestError: send request failed caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed 2023-08-08T17:34:10Z E! refresh EC2 Instance Tags failed: RequestError: send request failed caused by: Post "https://ec2.ca-central-1.amazonaws.com/": x509: certificate signed by unknown authority, metrics will be dropped until it got fixed"

証明書バンドルを検査するには、次のコマンドを実行します。

  • Linux の場合、証明書は /etc/ssl/certs/ に保存されます。プライマリ証明書バンドルを検査するには、次のコマンドを実行します。

    ``bash
    cat /etc/ssl/certs/ca-certificates.crt
    ``

  • 独自の証明書を持つアプリケーションの場合は、次のコマンドを実行します。
    注: example-region は、必要な AWS リージョンに置き換えます。

    ``bash
    curl --cacert /path/to/ca-bundle.crt -Iv https://ec2.example-region.amazonaws.com/
    ``

  • Windows の場合、証明書は Microsoft 管理コンソール (MMC) で管理します。Windows マシンから MMC にアクセスするには、Windows アイコンボタンと R キーを同時に押します。プロンプトが表示されたら、mmc と入力し、Enter キーを押します。

注: Amazon ルート証明書がない場合は、システムまたはアプリケーションの証明書バンドルに追加します。

トピック
計算する管理とガバナンスネットワークとコンテンツ配信
タグ
Amazon EC2Amazon CloudWatch
言語
日本語
AWS公式
AWS公式更新しました 10ヶ月前
コメントはありません

関連するコンテンツ