CI部 佐竹です。
本日は、ちょっとした運用知見の共有です。
はじめに
今回のブログは、以下の公式トラブルシューティング([Connection Lost] ステータスの Systems Manager のマネージドインスタンスをトラブルシューティングする方法を教えてください。
)に掲載がないトラブルに見舞われたので、その記録と共有が目的です。
結論
SSM Agent を動作させる EC2 インスタンスでは、OSにおける時刻同期をしっかりしましょう。
補足:今回トラブルが起きた OS は Windows Server です。
何が起きたのか
SSM による作業が必要な EC2 インスタンスにおいて、SSM Agent ping status
が突然「Connection Lost」のステータスになってしまいました。作業が正常に行えず、作業のためにトラブルシューティングが必要です。
先ほどご紹介した公式ドキュメントにはチェック項目として以下の記載があります。
- AWS Systems Manager エージェント (SSM エージェント) がインストールされ実行中である。
- SSM エージェントを使用して Systems Manager エンドポイントに接続されている。
- 適切な AWS Identity and Access Management (IAM) ロールがアタッチされている。
- インスタンスメタデータサービスに接続している。
これらは、既に確認済でした。後述のブログでも「SSM が動作するかのチェックポイント」としてご紹介しているものが以下のリストです。これらも確認済であり、突然動作しなくなったことの原因が不明でした。
- EC2 Instance に Systems Manager が動作するための IAM Role が付与されている
- EC2 Instance が起動しており、正常に動作(2/2)している
- EC2 Instance に Systems Manager Agent がインストールされている
- EC2 Instance で Systems Manager Agent が実行中であり、正常に動作している
- EC2 Instance がネットワーク経路として Systems Manager の Endpoint にアクセス可能となっている(インターネット経由もしくは VPC Endpoint を活用)
- SSM Fleet Manager の Managed instances に Online と表示される
AWSSupport-TroubleshootManagedInstance を実行してみる
対応として AWSSupport-TroubleshootManagedInstance
の Automation Document を実行してみました。
結果としては、問題はありませんでした。ドキュメントの実行結果として、Output は以下の通りでした(一部改変)。
Total Number of Tests: 5 1. Checking for VPC Endpoints: VPC endpoint for SSM Found: vpce-06d419bbbbbbbbbbb a. Subnets configured for the vpc endpoint found:subnet-5daaaaaa,subnet-d4dddddd b. PrivateDNS is set as True or False? Answer: True. (Recommended to set as True.) c. Security group attached to the vpc endpoints sg-0ffffffffffffffff Warning : VPC endpoint for SSM exist, vpce-06d419bbbbbbbbbbb but subnets associated with the VPC Endpoint does not include the subnet of instance. This can still work if the NACL rules are correct to allow traffic between the subnets on port 443. Or alternatively, you can add the Instance subnet subnet-12341234 to the VPC endpoint. For reference, Modifying an Interface endpoint - https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint 2. Checking Route Table entries of the instance's subnet : PASSED : Local route available for 10.7.17.0/2510.7.16.0/2410.6.8.0/2310.7.18.0/2310.7.20.0/2310.7.22.0/2310.6.0.0/2110.7.0.0/20. If VPC endpoint for SSM is present, then Local route is used to communicate with VPC endpoint interface. WARNING : ENI eni-02e9f9441f234234b is present and routing traffic towards 0.0.0.0. This could be working as NAT Instance.If Internet is not working, Check the NACL/Security Groups associated with eni-02e9f9441f234234b are configured correctly for internet access. 3. Checking NACL rules of the instance subnet: PASSED : Network Acl Egress Rules ALLOWS outbound traffic on port 443 towards 0.0.0.0/0. PASSED : Network Acl Ingress Rules ALLOWS inbound traffic on ephemeral ports from 0.0.0.0/0 4. Checking SGs of the instance for Port 443 outbound rule: PASSED : Found Outbound Rule for TCP 443 to 0.0.0.0/0 5. Checking if Instance Profile is attached : PASSED: Found Instance profile attached to the Instance: arn:aws:iam::123456789012:instance-profile/satake-instance. AWS Managed policy,AmazonSSMManagedInstanceCore is attached to the Instance profile. - - - - - - - - - - - - - - - - - - - | For Further Investigation | - - - - - - - - - - - - - - - - - - - You can use SSMAgentToolkit-Windows to troubleshoot further for Operating system level problems. The SSMAgent-Toolkit is a set of PowerShell scripts developed to run multiple checks to determined why a Windows EC2 instance does not come online as Managed Instance. Simply download the ZIP file included in the below package and extract. Package location : https://github.com/awslabs/aws-support-tools/tree/master/Systems%20Manager/SSMAgent-Toolkit-Windows Change directory to the extracted folder and Run the followings as administrator in PowerShell. Import-Module .\SSMAgent-Toolkit.psm1;Invoke-SSMChecks # Reference : a. https://github.com/awslabs/aws-support-tools/tree/master/Systems%20Manager/SSMAGENT-TOOLKIT-LINUX b. https://aws.amazon.com/premiumsupport/knowledge-center/systems-manager-ec2-instance-not-appear/
SSM Agent のログを確認してみる
以下の通りのログが出ており、何かが原因で Agent が強制的に停止されたように見えます。
2021-07-14 12:31:00 INFO [amazon-ssm-agent] Service received stop ChangeRequest 2021-07-14 12:31:00 INFO [amazon-ssm-agent] Stopping Core Agent 2021-07-14 12:31:00 INFO [amazon-ssm-agent] [LongRunningWorkerContainer] Receiving stop signal, stop worker monitor 2021-07-14 12:31:02 INFO [amazon-ssm-agent] [LongRunningWorkerContainer] Received worker termination result, &{SchemaVersion:1 Topic:GetWorkerHealthResult Payload:[123 34 83 99 104 101 109 97 86 101 114 115 105 111 110 34 58 49 44 34 78 97 109 101 34 58 34 115 115 109 45 97 103 101 110 116 45 119 111 114 107 101 114 34 44 34 87 111 114 107 101 114 84 121 112 101 34 58 34 76 111 110 103 82 117 110 110 105 110 103 34 44 34 80 105 100 34 58 50 54 52 48 44 34 73 115 84 101 114 109 105 110 97 116 105 110 103 34 58 116 114 117 101 125]} 2021-07-14 12:31:02 INFO [amazon-ssm-agent] channel C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/health requested close 2021-07-14 12:31:02 INFO [amazon-ssm-agent] surveyor listener stopped on path: C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/health 2021-07-14 12:31:02 INFO [amazon-ssm-agent] channel C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/health closed 2021-07-14 12:31:02 INFO [amazon-ssm-agent] channel C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/termination requested close 2021-07-14 12:31:02 INFO [amazon-ssm-agent] surveyor listener stopped on path: C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/termination 2021-07-14 12:31:02 INFO [amazon-ssm-agent] channel C:\ProgramData\Amazon\SSM\InstanceData/i-12345678901234567/channels/termination closed
OS の時刻がズレていることに気付く
作業の中で、ログの時間が現在と10分程度ずれていることがわかりました。
時刻を手動で同期させると、すぐに SSM Agent ping status
が「Online」に回復しました。
この理由ですが、まず SSM Agent と SSM の Endpoint 間は https で通信を行っています。そして OS 側の時刻がズレることで、SSL 証明書の有効日付とのズレが起こり、安全なサイトと OS 側から認識されなくなるために https 通信が正常にできない状態となり、コネクションが確立できなくなってしまいます。
つまり、時刻を正常な時間に合わせれば https の通信は正常に行えるようになります。およそ OS 内の時刻が10分程度ズレると、本事象が発生します。
まとめ
本日のブログでは、AWS Systems Manager でマネージドインスタンスが Connection Lost になる場合に、その原因の1つとしてサーバーOSの「時刻ズレ」があるという実体験について記載しました。
同様の現象でお困りの方は、一度「時刻同期が正常に動作しているか」を疑ってみてください。
なお AWS Windows AMI はデフォルトで Amazon Time Sync Service と同期します。時刻同期についての詳細は以下のドキュメントをご確認ください。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。