Webサーバが100 %の容量に達した日💾 JSONRUNEはなぜバックスラッシュを追加するのですか?

初めに

ある日、数ヶ月後に、QAエンジニアは、彼がウェブアプリケーションにログインすることができなかったと言うスラックの上で私にテキストメッセージを送りました.当然、私は彼の資格情報でログインしようとしました.私は彼のパスワードを忘れたと思ったので、私は彼にそれを送って、彼は今ログインできると述べた.私はそれについて何も考えなかった.
2時間後、ログオフ時間に関して、私は、彼らがログインすることができないと言うクライアントから電子メールを得ます.私は、彼らが彼らのパスワードを忘れたと思って、彼らに明日最初に戻るようにしようとして、それを退けました.それから、私のチームのモバイル開発者は、同じことを言いました.

だから私は調査に行く.私はウェブサイトに行って、ログインしようとしました、そして、私はそうしませんでした.

同僚がデータベース接続に関する問題であるかもしれないと言及したとき、私はすぐにデバッグを始めました.私たちは最近データベース・インスタンスにデータベース・インスタンスを使用することから移動しました、そして、これは問題を引き起こしているかもしれないか、1つのインスタンスがあまりに多くの荷を引き受けていたかもしれないと仮定しました.この変化は最大で最も最近のものだったので、我々はそれに焦点を絞った.しかし、データベースコンソールは細かく見え、特定のインスタンスに余分な負荷を示しませんでした.

この問題は生産上でのみ起こったので、どんなコード変更にも関連しないと仮定するのは安全でした.この時点で、我々はクライアントからますます多くの苦情を得始めたので、私は何か危険なことをすることを決めた:生産上のデバッグ.

私は、CyberDuckを使用してサーバーに接続し、ログイン表示ファイルに移動し、logging in . 私が驚いたことに、私が保存を打つとき、ファイルは保存されませんでした.サイバーダックは、私が覚えていなくて、その時理解していなかったあいまいな誤りを示しました.

デバッグの2、3時間後に、我々はサーバーが100 %のディスク使用に達したと理解しました.その日、2つの役に立つUNIXコマンドを学びました.du and df . manページから

The du utility displays the file system block usage for each file argument and for each directory in the file hierarchy rooted in each directory argument.

The df utility displays statistics about the amount of free disk space on the specified filesystem or on the filesystem of which file is a part.

これは1つのことを意味しました:ディスクサイズをアップグレードしなければなりませんでした.ありがたいことに、同僚はダウンタイムでそれをする方法を考え出しました.
危機は回避された.人々はログインできました.

終わりない

信じているかどうかではなく、我々は当時の巨大なワークロードのために、これ以上のアクションは、サーバーのディスクスペースを監視するか、なぜこれが起こったか深く掘るために取られた.とても驚くほど、2ヵ月後に、サーバーは再び100 %の能力に達しました!
私たちは準備ができて、すぐに問題を特定して、ディスクサイズをアップグレードしました.今回は、なぜ私たちがこの2ヶ月以内にファイルをアップロードしなかったのですか?
再び、私はdu and df ディスク空間を食べているディレクトリを特定するコマンド

$ du -sh /var
...
170.3G    /mail
...

メールディレクトリは170ギガバイト、サーバー全体のディスクスペースのほぼ80 %を占めていたことを想像!更なる採掘は犯人がcrontabであることを示した.我々はいくつかのcronジョブを実行していたcrontabは/var/mail . これは以下のようにcrontabファイルに明確に記載されていましたが、特定のcronジョブの出力は、どうにか速くディレクトリをいっぱいに管理することができた多くのジャンクを返していました.

$ crontab -l
...
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
...

今何？

アクションの計画は、最初のメールを停止し、既存のメールを削除するには、サーバーを解放することでした.

$ crontab -e
MAILTO="" # to disable cron emails

$ sudo rm /var/mail/ubuntu

賢くて賢く、我々はそれが再び発生する場合には、この特定の問題をキャッチするための監視サービスを設定しようと考えた.選択のサービスはMonit そして、それは驚くほど簡単に使用を開始した.これは、ディスクの空き容量からCPUの使用量をメモリに簡単に必要なすべての番号を視覚化することができますダッシュボードを作成し、カスタムイベントに電子メールアラートを送信します.This great article 非常にubuntuサーバー上でmonitを設定するのに便利です.
そして残りは歴史です.私たちは再びディスクスペースで問題に直面しませんでした.これまで.

読書ありがとう!今度まで👋
カバー写真Taylor Vick 不平を言う