公開鍵認証(鍵交換)を使ってSSH 接続してみる

クライアント用の ssh コマンドを使っって、公開鍵認証(鍵交換認証)にてSSH接続を行ってみます。

開鍵認証方式による鍵ファイル+パスフレーズ(パスワード)での認証について簡単に解説してみます。

目次 ssh コマンド で 公開鍵認証を使ってSSH 接続してみる 履歴 2013.8.1 初版

ssh コマンド で 公開鍵認証を使ってSSH 接続してみる ssh-keygen コマンドで、SSH鍵を作成します。 SSH鍵は、ssh-keygen コマンドで作成することができます。 SSH2に対応した、DSAとRSAの両方の鍵を作成できます。 ここでも先のTeraTerm時と同じように 2048ビットのRSA 鍵を使ってみます。(SSH1対応のRSA1ではないので注意してください。)

2048ビットのRSA鍵ファイルを作成します。

$ ssh-keygen -t rsa -b 2048return Generating public/private rsa key pair.

ファイルの出力先、ファイル名ですが、ここではデフォルトのまま使用します。

Enter file in which to save the key (/home/hoge/.ssh/id_rsa): return

パスフレーズを入力します。

Enter passphrase (empty for no passphrase): *********return

再度、パスフレーズを入力します。

Enter same passphrase again: *******return Your identification has been saved in /home/hoge/.ssh/id_rsa. Your public key has been saved in /home/hoge/.ssh/id_rsa.pub. The key fingerprint is: 5c:42:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:e1:c8 hoge@example.com The key's randomart image is: +--[ RSA 2048]----+ | ... ..o+| | . . ....| | . . .....| | . . . ...| | . . .| | | | | | | | | +-----------------+ 上記の例では、/home/hoge/.ssh/ 配下に 公開鍵 : id_rsa.pub 秘密鍵 : id_rsa が作成されます。 ssh-keygen は、デフォルトでは、ログインユーザの ホームディレクトリ/.ssh/ に各鍵ファイルが作成します。 ssh-keygen が、クライアント側、サーバー側で実行されたかは、あまり意味がありません。 クライアント側、サーバー側ぞれぞれに、以下のようにファイルを設置する必要があります。 サーバー側 : 公開鍵(パブリックキー) クライアント側 : 秘密鍵(プライベートキー) TeraTermなどのクライアントソフトでも鍵を作成できます。 TeraTermでの作成方法は、こちら を参照してください。

接続先SSHサーバー側に 公開鍵 を設定します。 ssh-keygen で作成した公開鍵 を接続先SSHサーバー側にコピーします。 設定するファイル名は、

/ユーザホーム/.ssh/authorized_keys

で作成します。 ここでは、hoge という名前のユーザで解説してみます。

/home/hoge/.ssh/authorized_keys

ssh-rsa AA........PQ== hoge@example.com 公開鍵は、単純なテキストファイルなのでコピー&ペーストでファイルを作成してもOKです。また、SFTPなどでアップロードしてもOKです。 コピーを終えたら、公開鍵の権限を所有者のみ読み込み可(400)とします。 $ chown -R hoge. /home/hoge/.ssh/return $ chmod 400 /home/hoge/.ssh/authorized_keysreturn サーバーで鍵を作成した場合は、単純にファイル名を変更するだけで良いと思います。 この時のファイル名authorized_keysは、SSHDのデフォルトの設定になっていますので、もし、sshd の設定を変更している場合は、その変更したファイル名を指定します。 $ vi /etc/ssh/sshd_configreturn ...

公開鍵の設置ファイル名を指定します。

AuthorizedKeysFile .ssh/authorized_keys ... もし、ファイル名を変更した場合は、sshd のリロードを実行します、

クライアント側に 秘密鍵 を設定します。 サーバー側で鍵を作成した場合のみ、サーバーから秘密鍵をダウンロードし、クライアント側に設置します。 ダウンロードの際は、FTPを使わず、FTPS or SFTP or SCP を用いてダウンロードします。

これは、SFTPの例です。

サーバーのIPアドレス : 192.168.1.99 だとします。

クライアント端末から以下のようにsftpコマンドを発行します。

-ポートを指定する場合、-oPort=22 のようにオプションを追加します。

秘密鍵ファイルを指定する場合、-oIdentityFile=id_rsa のようにオプションを追加します。

$ sftp hoge@192.168.1.99return ... Connected to 192.168.1.99 sftp> pwdreturn Remote working directory: /home/hoge sftp> cd .sshreturn sftp> lsreturn authorized_keys id_rsa id_rsa.pub sftp> get id_rsareturn Fetching /home/hoge/.ssh/id_rsa to id_rsa /home/hoge/.ssh/id_rsa 100% 1743 1.7KB/s 00:00 sftp> byereturn

接続先SSHサーバーの SSHの設定を変更します。 接続先SSHサーバーの SSHの設定を 公開鍵認証を可とし、パスワードによる認証を不可とします。 /etc/ssh/sshd_config

...

プロトコルバージョンを2固定とします。

Protocol 2 ...

rhost RSA認証を不可にします。

RhostsRSAAuthentication no

host based 公開鍵認証を不可にします。

HostbasedAuthentication no

/etc/ssh_known_hosts または ~/.ssh/known_hosts を無視します。

IgnoreUserKnownHosts yes

rhost を無視します。

IgnoreRhosts yes ...

RSA認証を不可にします。

RSAAuthentication no

公開鍵認証を可にします。

PubkeyAuthentication yes

公開鍵の設置場所をユーザディレクトリ配下の .ssh/authorized_keys にします。

AuthorizedKeysFile .ssh/authorized_keys

公開認証時のコマンドは実行しません。

AuthorizedKeysCommand none

公開認証時のコマンド実行時のユーザは、nobodyとします。

AuthorizedKeysCommandRunAs nobody ...

パスワード認証を不可とします。

PasswordAuthentication no

空パスワードを不可とします。不要なのでコメントアウトします。

PermitEmptyPasswords no

... ここでは、念のため不必要な認証は、すべて不可にしています。 ここで最小限必要な項目は、以下のものです。

PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no 設定を終えたら、sshd の再読み込みか、再起動します。

$ /etc/init.d/sshd restartreturn sshd を停止中: [ OK ] sshd を起動中: [ OK ]

sshコマンドを使って接続してみます。 ここまで設定を終えたら、sshコマンドを使って接続してみます。

サーバーのIPアドレス : 192.168.1.99 だとします。

クライアント端末から以下のようにsshコマンドを発行します。

-ポートを指定する場合、-p 22 のように指定します。

秘密鍵ファイルを指定する場合、-i id_rsa のように指定します。

$ ssh -p 22 -i id_rsa hoge@192.168.1.99return

鍵作成時に設定したパスフレーズを入力します。

Enter passphrase for key 'id_rsa': *********return Last login: Thu Aug 1 07:11:54 2013 from client.example.com [hoge@example ~]$ 上記のようにログインできればOKです。 以下のようなワーニングが出力されて、先に進めないことがあります。 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: id_rsa Permission denied (publickey,gssapi-keyex,gssapi-with-mic). これは、単純に クライアント側の「秘密鍵 id_rsa のモードが誰でも読めるようになっているのでだめですよ。」という警告メッセージです。

モードを 600 or 400 へ変更します。

$ chmod 400 id_rsareturn これで上記の警告は出力されなくなるでしょう。 以下のエラーは、いろんな場合が考えられるので、非常にやっかいです。 $ ssh -p 22 -i id_rsa hoge@192.168.1.99return Enter passphrase for key 'id_rsa': Permission denied (publickey,gssapi-keyex,gssapi-with-mic). このエラーメッセージ自体は、「Permission denied」なので、拒否されたぐらいの意味でしかありません。 このエラーメッセージは、主に以下のような場合が考えられます。 クライアント側の秘密鍵が正しく読めない(ファイル名とパーミッションを確認する) サーバー側の公開鍵が正しく読めない ファイル名がauthorized_keysでない ディレクトリが正しくない(ログインするユーザホームディレクトリの .ssh 配下でなければなならい) 各ディレクトリ、ファイルのパーミッションが正しくない(1:参照) ユーザがsshdで規制されている (1) $ ls -l ~/.sshreturn drwx------ 2 hoge hoge 4096 8月 1 10:16 2013 .ssh

/home/hoge/.ssh: -rw-r--r-- 1 hoge hoge 421 8月 1 10:16 2013 authorized_keys

これ以外にも、いろんな場合が考えられます。 上記に当てはまらない場合は、デバッグ情報を確認されることをおすすめします。 $ ssh -p 22 -i id_rsa hoge@192.168.1.99 -vvvreturn ... -vvv オプションを追加するとデバッグ情報が出力されます。

うまく接続できたでしょうか。 この設定により、ユーザ+パスワードのみ場合に比べて安全になることは間違いありません。 セキュリティの向上は、常に意識しておいて損はありませんから、是非、やっておきましょう。

また、おまけですが、お名前.com VPS(KVM) や ConoHa VPS では、SSH Private Keyファイルをダウンロードできます。 お名前.com VPS(KVM) SFTPでISOファイルをアップロードする場合 SSH接続経由でシリアルコンソールへ接続する場合 に使えます。また、デフォルトOSの場合は、VPSへの root による SSH接続 のためにも使用できます。(ConoHaでは、デフォルトでこの鍵認証になります) 但し、デフォルトOS(CentOS)の場合のみ使用できる鍵ですから、注意しましょう。カスタムOSや、ISOアップロードで好きなOSをインストール場合は、使えません。 ちょっと参考まで。

rsyncの差分バックアップで!!

rsync差分バックアップするスクリプトなど
SSH
rsync

はじめに

レンタルサーバVPSを借りていると不意にデータが飛ぶことがたまにありますよね。 そんなときに備えて自宅サーバにリモートサーバのデータを差分でバックアップしておけると安心です。 有償/無償/商用も含めて様々なソリューションがあると思いますが、自分はお手軽にrsyncだけで実施しています。

方針

リモートのサーバAから、手元のサーバBにバックアップします。

リモートサーバA(IPアドレスaaa.bbb.ccc.ddd) [cron]リモートサーバA内のバックアップ対象データを /for_backup/ に集める 手元のサーバB [cron]rsyncで A:/for_backup/ を /remote_a_backup/latest に転送する [cron]rsyncで /remote_a_backup/latest を /remote_a_backup/YYYYMMDD に差分バックアップする スクリプト リモートサーバA内のバックアップ対象データを /for_backup/ に集める まあ適当に。

gather_for_backup.sh

!/bin/sh

rsync --progress -av --delete /etc /for_backup/ rsync --progress -av --delete /data /for_backup rsync --progress -av --delete /root/bin /for_backup/root rsync --progress -av --delete /var/lib/mysql /for_backup/var/lib ...

chown for rsync

chown -R takeuchi.rsync /for_backup rsyncで A:/for_backup/ を /remote_a_backup/latest に転送する rsync_from_remote_server.sh

!/bin/sh

rsync --progress -avz -e ssh --delete --bwlimit=150 takeuchi@aaa.bbb.ccc.ddd:/for_backup/ /remote_a_backup/latest rsyncで /remote_a_backup/latest を /remote_a_backup/YYYYMMDD に差分バックアップする rotation.sh

!/bin/sh

世代バックアップ

ROTATE_DAYS : LATEST_DIR を含めて何世代バックアップするか

ROTATE_DAYS=30 # BASEDIR=/remote_a_backup LATEST_DIR=${BASEDIR}/latest/ NEW_DIR=${BASEDIR}/date -d '-1 day' +%Y%m%d/ LINK_DIR=${BASEDIR}/date -d '-2 day' +%Y%m%d/ OLDEST_DIR=${BASEDIR}/date -d "-$ROTATE_DAYS day" +%Y%m%d/

rm -rf $OLDEST_DIR rsync -avz --progress --delete --link-dest=$LINK_DIR $LATEST_DIR $NEW_DIR crontab(ローカルサーバ) crontab 0 7 * * * /remote_a_backup/rsync_from_remote_server.sh > /tmp/a-backup-rsync.log; /remote_a_backup/rotation.sh > /tmp/a-backup-rotation.log 本当はもう少し異常系の処理が必要とは思いますけど 30 日以内に気づくという前提で。。

rsyncで公開鍵を指定してデータ転送する方法

ssh経由でrsyncを利用する際に、ssh鍵認証かつsshポート22以外に接続する方法。

コマンド

rsync -avz -e "ssh -p SSHポート番号 -i SSH秘密鍵ファイルパス" 送信元 username@hostname:~/dest/

例)
rsync -avz -e "ssh -p 2345 -i /c/sshkey/id_rsa" /c/develop/src/ hoge@192.168.1.10:~/dest/

公開鍵をリモート環境に保存、ローカルの秘密鍵とリモートの公開鍵で認証を行うので、ネットワーク上にパスワードが流れることがなく、セキュリティリを高めることができます。

ローカル側での設定

ローカルで秘密鍵と公開鍵のペアを生成し公開鍵をリモートに保存します。
リモートで鍵を生成し、秘密鍵をローカルに転送することも可能ですが、転送中に秘密鍵が漏れると、
公開鍵認証の意味がなくなってしまうので、ローカル側で生成したものを使用するようにします。

リモートのユーザー名 : hoge
リモートのホスト名 : example.com
リモートのディレクトリ名 : /home/hoge/
リモートのSSHポート番号 : 20022
ローカル側で秘密鍵と公開鍵のペアを生成
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): #「Enter」を押す
Enter passphrase (empty for no passphrase): # 秘密鍵パスフレーズを入力
Enter same passphrase again: # もう一度

他のユーザーに見られないようにパーミッションを変更

$ chmod 600 .ssh/id_rsa

リモートに公開鍵を転送

$ scp -P 20022 .ssh/id_rsa.pub hoge@example.com:/home/hoge/.ssh/
hoge@example.com's password: # リモートのパスワードを入力

リモート側での設定

他のユーザーに見られないようにパーミッションを変更(未設定の場合)
$ chmod 700 .ssh
$ chmod 600 .ssh/authorized_keys
転送されてきた公開鍵をリネーム
$ mv .ssh/id_rsa.pub .ssh/authorized_keys
既に他のホストの公開鍵が設定されている場合はリネームでなく追記する
$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys
$ rm .ssh/id_rsa.pub

ついでにrsyncを使う場合の方法も記しておきます。rsyncはファイルやディレクトリを転送するためのコマンドです。リモートのファイルやディレクトリをローカルに転送したり、ローカルのファイルやディレクトリをリモートに転送することができるので、バックアップ作業を行うときに活躍します。

書式 : rsync [オプション] 転送元 転送先
ローカルのファイルをリモートに転送する場合
ローカルのディレクトリ : /home/backup/backup.gzip
リモートのユーザ名 : hoge
リモートのホスト名 : example.com
リモートの転送先ディレクトリ : /home/hoge/backup/
$ rsync -avz /home/backup/backup.gzip hoge@example.com:/home/hoge/backup/
ポート番号が標準の22以外の場合
$ rsync -avze "ssh -p ポート番号" /home/backup/backup.gzip hoge@example.com:/home/hoge/backup/

Linux 蓄積されていくログディレクトリなどを定期的に削除する例(findを利用)

findを利用して、30日以前のディレクトリを削除する方法を示します。

Delete old data.

1). aaa フォルダ配下の30日以上前のディレクトリを backup フォルダへ移動 find ./aaa -type d -mtime +30 | xargs mv --target-directory=./backup

2).30日以上前のディレクトリを強制削除 find . -type d -mtime +30 | xargs rm -fr

危険なので、2)が望ましいとは思います

ファイルを消しても消えないことがある!!

なんでこうなるのか? Linux/Unixでは、ls/find等で一覧表示されなくてもプロセスがつかんでいる状況では 実際にはファイルシステムから削除されておらず、見えなくなる。 OSを再起動するとファイルシステム使用量が減るのは、表面上は見えないくプロセスが つかんでいるファイルを再起動によるプロセスにより、開放してくれる。

このような現象はプログラムバグでファイルクローズのしわすれ等の場合に発生する ことがあります。

対応方法 †

このようなとき以下ように lsof コマンドでどのプロセスがつかんでいるか確認し、 そのプロセスを終了(kill)させることで対応できます。

$ df -k . Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sdb1 988212 115412 822600 13% /mnt/sdb1
find . -ls
2 4 drwxr-xr-x 3 root root 4096 1月 19 14:54 .
11 16 drwx------ 2 root root 16384 1月 19 13:55 ./lost+found
$ lsof | grep /mnt/sdb1
bash 1910 root cwd DIR 8,17 4096 2 /mnt/sdb1
fileopen. 1932 root 3r REG 8,17 100000000 12 /mnt/sdb1/testfile.dat (deleted)
lsof 1938 root cwd DIR 8,17 4096 2 /mnt/sdb1
grep 1939 root cwd DIR 8,17 4096 2 /mnt/sdb1
lsof 1940 root cwd DIR 8,17 4096 2 /mnt/sdb1
$ ps auxww | grep 1932 | grep -v grep
root 1932 0.0 0.2 6664 1520 pts/0 S+ 14:54 0:00 /usr/bin/perl /root/fileopen.pl
kill 1932
$ find . -ls
2 4 drwxr-xr-x 3 root root 4096 1月 19 14:54 .
11 16 drwx------ 2 root root 16384 1月 19 13:55 ./lost+found

Javaビルド製品(Maven)を調べた!

Javaビルド製品(Maven)について調べたのでお伝えします。

MAVEN について

Mavenは、JAVAのビルド製品になります。プロジェクトをひとつのコマンドで利用できるなんて良いですよね。 インストール方法はあとで纏めるとして、基本的なことを記載します。

ビルドとコンパイルの違いは?

コンパイル

人間がプログラミング言語を用いて作成したソフトウェアの設計図(ソースコード)を、コンピュータ上で実行可能な形式 (オブジェクトコード)に変換すること。 そのためのソフトウェアをコンパイラという。 変換のみを一括して行い、生成したオブジェクトコードの実行は行わない。

ビルド  

ソースコードコンパイルやライブラリのリンクなどを行い、最終的な実行可能ファイルを作成すること。 また、そのような作業によって生成されたソフトウェアの版。

Mavenとは

Maven」とは、Javaプログラムをビルドするためのツール。

さまざまなプラグインを組み込むことによりソフトウェアテストツール、ソフトウェア保守ツール、ソフトウェア品質ツールの機能なども追加することが可能。

リモートリポジトリとローカルリポジトリの違いは?

プラグインやライブラリが置かれる場所です。 必要なプラグインやライブラリをリモートリポジトリからダウンロードし、それをローカルリポジトリに保存する仕様です。

下記は、Mavenアーキテクチャを表したものです。

桜

また、プロジェクトのライフサイクルに含まれるコンパイルやテストなどの各作業をコマンド一つで行うことができます

実現可能なこと


・ライブラリの一元管理 ・プロジェクト情報の配信 ・ビルドプロセスの提供(ソフトウェア構成管理) ・jUnitを使用した単体テストソフトウェアテスト) ・サイト生成機能を用いたプロジェクト情報の共有(ソフトウェア保守) ・FindBugsを使用したバグパターン検知(ソフトウェア品質)


大きな特徴

pom.xmlのタグにプロジェクトで使用したいJARライブラリ名及びバージョンを指定することで、外部サイトで集中管理されているJARを自動ダウンロードし、ローカルでビルドに使用が可能。

POMについて


pom.xmlはプロジェクトに関する情報を持つファイルです Project Object Modelの略です。


JARファイルとは

Javaのファイルを1つにまとめたファイル。 コンパイルされた複数のJavaバイトコード及びそれが使用する画像などのリソースを一つにまとめZIP形式で圧縮されたファイル、及びそれを出力するツール

JARファイルは、圧縮したままで、Javaの実行環境で動かすことができます。 zipファイル同様、圧縮・解凍ソフトで解凍できます。

その他のJAVAのビルド製品

Ant

Apache Software FoundationによってApache Software Licenseで提供されるオープンソースツール

よく利用するコマンド

プロジェクト作成

mvn -B archetype:generate \

プロジェクト作成

mvn -B archetype:generate \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DgroupId=com.myapp \ -DartifactId=myapp

プロジェクト検証

mvn validate

コンパイル

mvn compile

コンパイル時はpom.xmlには、情報を追記

テストの実行

Junitテストクラスの実行

mvn test

パッケージ生成

mvn package JAR、WAR等の成果物を生成する。 packageを実行すればvaliate、compile、test、packageのフェーズも実行される

インストール

JARをローカルリポジトリにインストールする。

mvn install

Katalon Recorder(Selenium IDE の強化版)を動作確認をしてみた感想

Seleniumの記録・再生ツールといえば「Selenium IDE」が有名ですが、これらのツールはFirefox55以降では使い物にならなくなりました。

そのほかで、無料で使える様々なSeleniumスクリプトの記録ツールがないか調べてみましたところ、「Katalon Automation Recorder」が適していましたので、動作確認してみました。

Katalon Automation Recorderとは

オープンソースではありませんが、無料で使えるSelenium IDEライクな無料の記録・再生ツールです。あらゆるブラウザで作成および再生できます。

C#、JavaRubyPython、Groovy、Robot Frameworkに幅広く対応し、自動テストケースとして記録、編集、エクスポートできます。

この拡張機能でさまざまなシナリオ環境を作成できます。

下記のURLからインストールし、Chromeプラグインできます。

https://chrome.google.com/webstore/detail/katalon-recorder-selenium/ljdobmomdgdljniojadhoplhkpialdid

テスターがWeb自動テストを実行したり、回帰テストを実行するためのサポートツールです。作業が自動化・高速化する便利なユーティリティです。

2.ユーザーガイド

2.1 ツールバー

Katalon Recorderメインツールバーには、Web記録プロセスを管理するためのボタンがあります。

header1 header2
new 新しいTestCaseを作成
Play/stop TestCaseを作る
Record/stop TestCaseを動作させる

2.2 TestCase作成

TestCaseエクスプローラビューには、テストケースの一覧が表示されます。

ユーザが任意のテストケースを整理、ブラウズ、アクセスできるようになります。 ドラッグ・アンド・ドロップ機能もあり、ユーザーがテストスイートまたはテストケースを編成するのに役立ちます。

右クリックしてコンテキストメニューを 表示します。コンテキストメニューを使用すると、New TestCaseを作成したり、名前を変更したり、削除したりすることができます。

2.3 起動と保存

TestSuitを右クリックし、コンテキストメニューから選択します。

2.4 Test case window

Katalon Automation Recorderは、記録されたテストスクリプトをウィンドウに表示します。

追加、削除、実行、新しいTest caseの追加、全てのTest caseの削除、Test caseの特定のステップでの実行など、管理に役立ちます。

2.5 テストケースの編集

Katalon Automation Recorder では、記録されたコマンドを編集、、ステップの任意のポイントで新しいコマンドを追加することが可能です。編集するステップを選択し、コマンド、ターゲット、および 値フィールドを使用して編集します

2.6 テストケースのエクスポート

メインメニューの「Export」をクリック すると、「Export Test Case as script」画面が以下のように表示されます。

生成されたテストスクリプトは、Katalon Studio(http://www.katalon.com)を使用して高度な条件、動的検証およびテストデータを使用して拡張できます。

Katalon Studioは、SeleniumとAppiumを完全なテスト自動化フレームワークで強化し、すぐにテストを開始するのに役立ちます。

まとめ

日本語のページが少ないので、動作させるまで苦労しました。より本格的にテストツールとして活用したい場合は、画面定義の共通化やデータ駆動・キーワード駆動テストなどを備えたKatalon Studioというものもあります。

RDSのスワップ領域ってどう確認するの?

前回、Amazon EC2スワップ領域の作成方法を纏めました。 今回は、RDSのスワップ領域はどうなってるのーーーーです。

RDSのスワップ領域を確認するには

RDSスワップ領域の全容量は、インスタンスの拡張モニタリングを有効にすることで、インスタンス上のエージェントより収集されたメトリクスが監視可能となります。

RDS には、DB インスタンスが実行されているオペレーティングシステム (OS) のリアルタイムのメトリクスが用意されています。

拡張モニタリングとは

RDS の拡張モニタリングを使うと CloudWatchのグラフが可能となります。

拡張モニタリング有効方法

1)拡張モニタリングを有効にしたいDBインスタンスを選択し、「インスタンスの操作」をクリック、「変更」をクリックします。

2).RDSのインスタンス一覧画面で対象のインスタンスを選択後上の「モニタリングを表示」の右の部分を選択してメニューを出して「拡張モニタリング」を表示します。

3).モニタリング画面で、下記のように設定します。 ・「拡張モニタリングを有効にする」で「はい」 ・モニタリングロールは「デフォルト」(rds_monitoring_role) ・「詳細度」は「60秒」

4).適用を押下する。

5).RDSコンソールで拡張モニタリングの有効化を行ったインスタンスを選択し、モニタリングの表示から拡張モニタリングを選択すると、拡張モニタリング画面が表示されます。

【参考URL】 http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html

スワップ領域のメトリックスは?

SwapTotal や SwapFreeが取得可能となりますので、こちらで確認が可能となります。

SwapTotal 利用可能なスワップ総容量 SwapFree swap の空き容量の合計 (キロバイト単位)。

注意:スワップ領域の容量 (SwapTotal) のみの場合は、メトリクス確認後、拡張モニタリングを再び無効にしてます。

参考に取得した値

容量:500 GB のストレージ インスタンスタイプdb.t2.small db.t2.small、db.t2.medium クラス 約 3.91GB のスワップ領域

容量:500 GB インスタンスタイプ:db.r3.large 約 14.95 GB のスワップ領域

あくまでテスト数値です。

まとめ

CloudWatchでもメトリックス(SwapTotal や SwapFree)を設定し、監視することは可能です。CloudWatch ログからの拡張モニタリング JSON 出力を使用したりできます。