Amazon Managed Service for Prometheus ( AMP )で心当たりのないCollectorの課金があった話
心当たりのないAMPの課金
先日いつもは届かないAWSの月額課金アラームのメールが届いたので、Cost Explorerで状況を確認すると「AMP:CollectorHours」という使用タイプで1 USD/日程度の課金が発生していました。
調査
まずはAMPマネジメントコンソールで、削除忘れのリソースがないか確認しましたが、何もリソースはありません。
課金が始まったタイミングがちょうどテスト用のEKSクラスタを作成→削除したタイミングだったため、EKSも確認しましたがそれらしきリソースはありません。
サポート問い合わせ
課金に関する事象のため、「アカウントと請求」カテゴリでサポートに問い合わせたところ、2週間ほどで回答がありました。
AMPのスクレイパーが残存しているため、AWS CLIで削除すれば良いとのことです。 docs.aws.amazon.com
解決
以下のCLIで以下のコマンドを実行すると確かにスクレイパーがありました。
$ aws amp list-scrapers
{
"scrapers": [
{
"alias": "test_scraper",
"arn": "arn:aws:aps:<region>:<AWSアカウントID>:scraper/<スクレイパーのID>",
...
以下のコマンドで削除します。
$ aws amp delete-scraper --scraper-id <スクレイパーのID>
削除には少し時間がかかります。削除途中で再度Deleteコマンドを実行すると以下の出力が返されます。
An error occurred (ConflictException) when calling the DeleteScraper operation: Can't delete scraper in non-ACTIVE state. Current status is DELETING
10分ほどで削除され、Listコマンドに何も表示されなくなりました。
$ aws amp list-scrapers
{
"scrapers": []
}
原因調査
マネジメントコンソールから見えないスクレイパーが残っていたのは、EKSクラスタを削除する前にスクレイパーを削除していなかったことが原因のようです。
また、AMP用のスクレイパーが作成されたのは、EKSクラスタ作成時にObservabilityの設定でPrometheusへのメトリクス送信をONにしたためでした。
この設定はオプションなので、通常はスクレイパーが作成されることはありません。
学び
参考サイト
Amazon InspectorでEC2がスキャンされるタイミング
Amazon InspectorでEC2の脆弱性が指摘された際に、yumで対象のパッケージを更新することで対応することがあります。
その際にどのタイミングでInspectorに更新が反映されるのか疑問に思ったので実際にやってみました。
結論としては、パッケージの更新をトリガとしてインベントリが走り、約5分後にはInspectorの画面に反映されます。
以下、実際にパッケージを更新した際の経緯です。
kernelを更新する前のInspectorの画面は以下のようになっています。
現在使用しているkernelバージョンの脆弱性がリストされています。
yum updateで更新し、再起動して少しすると以下のような画面に変わりました。
kernelの脆弱性の指摘がなくなっています。
パッケージ情報の収集はSystems Managerのステートマネージャの「AWS-GatherSoftwareInventory」というドキュメントで実行されているようです。
ステートマネージャのコンソールで「関連付けを今すぐ適用」をクリックすれば、即時で実行することもできます。
参考
Inspectorの再スキャンについて、FAQに以下の記述があります。
Q: 自動再スキャンはどのくらいの頻度で実行されますか?
すべてのスキャンは、イベントに基づいて自動的に実行されます。すべてのワークロードは、最初に検出時にスキャンされ、その後再スキャンされます。
Amazon EC2 インスタンスの場合: 再スキャンは、インスタンスに新しいソフトウェアパッケージがインストールまたはアンインストールされたとき、新しい CVE がパブリッシュされたとき、および脆弱なパッケージが更新された後に開始されます (追加の脆弱性がないことを確認するため)。
MariaDB 10.6でmysql_secure_installationが見つからないときの対処方法
問題
mariadbのインストール後の初期設定でmysql_secure_installationを実行すると「コマンドが見つかりません」と返されます。
# mysql_secure_installation -bash: mysql_secure_installation: コマンドが見つかりません
解決方法
代わりに以下のコマンドを使用します。
mariadb-secure-installation
説明
MariaDB 10.5からより多くのコマンドでmariadbの名前が使用されるようになったようです。
以下の公式ドキュメントに対象のコマンドの一覧があり、ここに「mariadb-secure-installation」もリストされています。
mariadb.com
AWS Systems ManagerでEC2インスタンスの起動停止をスケジュール実行する
常時稼働が不要なEC2インスタンスを、毎日同じ時間に起動停止したいことがあると思います。
そんな時AWS Systems Managerを使えば、スクリプトを書くことなく起動停止をスケジュール実行することができます。
IAMロール作成
まずは、Systems ManagerがEC2に対してタスクを実行する際に使用するIAMロールを作成します。
信頼されたエンティティの選択では、「AWSのサービス」＞「Systems Manager」を選択します。
ポリシーは「AmazonSSMAutomationRole」を選択します。（今回のタスクに対しては余分な権限も入っています）
適切な名前を付けて「ロールを作成」をクリックします。
メンテナンスウィンドウを作成する
Systems Managerコンソールを開き、メニューから「メンテナンスウィンドウ」を選択します。
「メンテナンスウィンドウの作成」をクリックします。
名前を付けます。今回は停止のウィンドウから作成します。
メンテナンスウィンドウのスケジュールを指定します。今回は毎日午前2時から1時間で指定します。
「メンテナンスウィンドウの作成」をクリックします。
作成されました。「次の実行時間」はUTC表示になっているので注意が必要です。
メンテナンスウィンドウにタスクを登録する
続いて、作成したメンテナンスウィンドウに対してタスクを登録します。
メンテナンスウィンドウの詳細を開いて、タスクタブで「オートメーションタスクの登録」をクリックします。
オートメーションもSystems Managerの機能の一つです。
オートメーションドキュメントで「AWS-StopEC2Instance」を選択します。検索欄では大文字小文字の区別があるので注意です。
ターゲットは「Task target not required」を選択し、入力パラメータのInstanceIDで停止したいインスタンスIDを入力します。
IAMサービスロールで先ほど作成したロールを指定し「オートメーションタスクの編集」をクリックします。
タスクが作成されました。これで停止のスケジュールは完了です。
起動についても同様にメンテナンスウィンドウの作成とタスクの登録を行います。
タスク登録時に使用するドキュメントは「AWS-StartEC2Instance」です。
実行履歴の確認
起動停止が実行されたらその履歴を確認することができます。
メンテナンスウィンドウのコンソールでIDをクリックします。
履歴タブを確認します。ステータスや開始終了時刻を知ることができます。
履歴のIDを選択して「詳細の表示」をクリックすればさらに詳細を調べることができます。
オートメーションドキュメントに渡したパラメータも確認できます。
AWS CloudTrailで証跡を作成する方法
AWS CloudTrailはAWS内で実行されたアクションをイベントとして記録してくれるサービスです。
特に設定しない場合は90日間のイベント履歴のみが保存されますが、それ以上の期間に渡ってイベントを保持したい場合は証跡の取得を有効化する必要があります。
今回はCloudTrailで証跡を作成する方法を説明します。
証跡の作成
CloudTrailコンソールのダッシュボードにアクセスし、「証跡の作成」をクリックします。
パラメータを指定していきます。
ログイベントの詳細ページでは収集するイベントを選択します。
確認と作成画面で設定を確認し、証跡を作成します。
CloudTrailコンソール＞証跡 で証跡が作成されていることを確認します。
ログファイルの確認
S3コンソールでは指定したバケットに証跡のログが格納されていることを確認できます。
証跡の取得開始からログファイルが作成されるまで15分程度かかります。
EC2インスタンス（Ubuntu）にCloudWatchエージェントをインストールする方法
CloudWatchでは標準でいくつかのメトリクスを利用できますが、メモリ使用率などのデータを収集するためにはCloudWatchエージェントのインストールが必要です。
今回はUbuntuのEC2インスタンスにCloudWatchエージェントをインストールする手順を説明します。
CloudWatchエージェントのインストール
サーバにSSHなどで接続し、以下のコマンドを実行します。
wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
パッケージをダウンロードしたディレクトリへ移動し、以下を実行します。
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
エージェントの設定ファイルを作成する
以下のコマンドを実行します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
質問に答えることでパラメータが設定されていきます。詳しい内容は公式ガイド参照。
作成された設定ファイルは以下のディレクトリに保存されます。
/opt/aws/amazon-cloudwatch-agent/bin/
エージェントを起動する
以下のコマンドを実行してエージェントを起動します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json
エージェントのステータスを確認します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
