仕事でちょっとVPC Flow logsを調査する機会があって、自分のAWSアカウントにも設定してみた。
ただ、何もしてないでも大量にログが出るようだとCloudWatchの料金が掛かりそうで心配で見てみたが、何のインスタンスもなく通信が発生しないような状況だと当然ネットワーク通信もないので出力されない＝料金がかからない。
個人利用で大したこともやっていないのならVPC Flow Logsを有効にしても、料金は無視できる程度と判断した。
ただし外から攻撃などでログの量がいきなり増える可能性もあるので、料金は定期的に見ておいたほうが良いのは言うまでもない。
リニューアルしてネットワーク接続不良、再インストール失敗を乗り越えて次のトラブルは謎のプロセスが殺される事態。
Javaのサーバープロセスなのでメモリ不足を疑い、oom killerが発動していることが判明。そんなにメモリきつきつかな？と調査してみたらナントスワップがないのでありました。
取り急ぎ以下のコマンドで２Gのスワップ作成
dd if=/dev/zero of=/swap bs=1M count=2048 chmod 600 /swap mkswap /swap swapon /swap
土日の回復は難しいかと思ったが、２４時間以内に返信がありOSインストール中に止まってたらしい。もちろんこちらでは手出しができないことなので直してもらってインストール完了状態にはなった。
全然つながらないと思ってよく見たらIP変わってやがる！今まではIP固定だったのだが、今後は再インストールでIP変わるのだろうか？
スナップショット機能が未だに調整中で提供されていないのだが、いずれまたスナップショットを取るために懲りずに再インストール予定。
今週月曜日に自分のサーバーがメンテナンスとなり、事前情報だと終日停止のようだったが、6時間後に復旧。
ただしネットワークが不安定で落ちるわけがないAWSへのTimeoutなどが頻発するようになった。これでは使い物にならないので乗り換えを検討してしまうほど。
2日後に緊急メンテナンスがあって、これも指定時間帯に再起動が走るというものでいつ使えなくなるかわからないという。。
そのメンテナンスが終わってネットワークがようやく安定してきたので再インストールしようとしたら謎のエラーがでて一切の操作ができない状況になった。
あまりサポートには期待してないのだが、これ以上はどうしょうもないので問い合わせ。さて何週間係るかな（メールのレスポンスが遅いので、最初から長期戦覚悟）
port 9000番は解放されているし、ファイヤーウォールは全部停止してみたし、他のDockerアプリは普通にアクセスできるのに何故かSonarqubeだけアクセスできないという状況。
解決してみれば大したことはなかったのだが、その原因はDBの接続に失敗していて、Webサーバーが起動されてないことであった。docker ps していると普通に上がっているように見えるので気がつくのが遅れた。
まずはきちんとログを見ることだ！基本中の基本を忘れて遠回りしてしまった。
Sonarqubeが内部で利用しているElasticSearchのせいでエラーが出ていた。
max virtual memory areas vm.max_map_count [65530] is too low
よく見るやつではあるのだが、インストールしたままの設定だと引っかかる。
とりあえずの設定だと
sudo sysctl -w vm.max_map_count=262144
再起動したら消えてしまうので/etc/sysctl.confに以下の行を追加
vm.max_map_count = 262144
ここ数年Windowsはあまり使わず、仕事ではMacを利用しているのだが、Macはコストパフォーマンスが悪い！
てなわけで私用での選択肢はUbuntuを日常的に利用している。不満に思いつつも我慢して使ってきたのだが、やはりputtyのように選択しただけでコピーされて、右クリックでペーストしたい（MacのiTermでも同じ操作ができるのでなれている）
本腰を入れて探すが、日本語だけだとなかなか見つからない。Copy On select Ubuntuのキーワードで検索したらterminatorなるターミナルソフトが対応しているらしい。
早速インストールして、設定画面でPutty Style Pasteにしたら実現できた！
しかし今度は右クリックで開けるはずの設定画面が開けなくなるというオチだ！
同じような人がいるらしく、設定画面を開くにはShift+F10のショートカットで開ける！
なぜか10月入ってからsvn upした時に接続先サーバーのSSL認証に失敗する。
まったく心当たりがないし、接続先サーバーの証明書は１２月まで有効である。
クライアント（ここではCentOS7)のroot証明書が古いという情報を得て、以下のコマンドで証明書を更新してみたところ、エラーはでなくなった！
yum update ca-certificates
せっかくなのでSSHが切れる時の対策を探してみた。
クライアント側からPINGのように生存確認を送ってくれる設定があった。
~/.ssh/configの設定以下を追加
ServerAliveInterval 60
ServerAliveCountMax 10
60秒間隔で１０回サーバーに生存確認を送ってくれるので、１０分間は切れない！
これでwimaxでSSH接続が切れまくる問題は回避できた！
他の通信業者ではあまり起きないのであるが、wimaxでSSH接続をしているとしょっちゅう切れる。
切れると言っても圏外に行くわけではないのだが、数分何の操作もしないとBroken pipeでキレてしまうという不便さ。
tmuxでセッションが切れても大丈夫なようにしておかないと怖くて本番作業では使えない。
