【エンジニア必見】知っ得！インフラTips7選！！

# はじめに :flushed:
今回は ”知っ得！” ということで読むだけでお得な情報をまとめました。
レベルはまちまちですが、皆さんの辛い想いが減るといいなと思います。

「私はこんな飛び道具もってるよ！」というかたは是非コメント欄でコメントをいただければと思います！

それでは、いってみましょう！

# Tips
## 1. messagesが見ずらい！大事なメッセージだけ見たい

```
egrep -i 'resource|allocate|memory|error|fatal' /var/log/messages
```

## 2. PSコマンドの見かたがわからない、CPUを多く使用しているプロセスだけみたい

```
ps -e aux | sort -r -k 3 | head -n 10
```

## 3. PSコマンドの見かたがわからない、メモリを多く使用しているプロセスだけみたい

```
ps -e aux | sort -r -k 4 | head -n 10
```

## 4. SSL証明書を更新したのにエラーでwebページが表示できない

更新した証明書が過去のものとごちゃまぜになっていてペアが間違っていたなんてことがあります。
そういうときはそれぞれの証明書や秘密鍵の整合性をチェックしましょう。
　※配置した証明書に無駄な改行が入っていた。なんてこともあるので要確認。

- key (秘密鍵)
- cert (証明書)
- ca (中間証明書)


秘密鍵とサーバ証明書の確認

```
openssl rsa -in /etc/httpd/conf/ssl/key -modulus -noout | openssl md5
openssl x509 -in /etc/httpd/conf/ssl/cert -modulus -noout | openssl md5

 ⇒ 出力された2つのhash値を確認し、同一ならOK
```

中間証明書とサーバ証明書の確認

```
openssl x509 -subject_hash -noout -in /etc/httpd/conf/ssl/ca
openssl x509 -issuer_hash -noout -in /etc/httpd/conf/ssl/cert

 ⇒ 出力された2つのhash値を確認し、同一ならOK
```

有効期限の確認

```
openssl x509 -in /etc/httpd/conf/ssl/cert -noout -dates

　⇒　有効期限が正常に更新されているか確認
```

## 5. 「No space left on device」 Apacheが起動できない

細かい説明は省きますがセマフォというものがあり簡単に言うと、Linux上で展開できるプロセス数には上限があるよ～ということ。

kernelに関わる設定変更を含むのでOSの動作に不具合が出る可能性があります。
スナップショット等で切り戻しができるような体制は取るようにしましょう。

```
/sbin/sysctl -a | grep sem
　　kernel.sem = 250 32000 32 128　　←ここの128が上限
　　kernel.sem_next_id = -1
```

Apacheの再起動を繰り返しているうちに子プロセスが落ちる前にApacheが起動してしまいそれが残り続け積み重ねで上限にまで達してしまうなんてことが起きることがあります。

上限まできているかの確認はこちら

```
ipcs -s
 行数をカウント
```

128を超えている場合は上限の引き上げで対応できます。
　※以下は1024に引き上げる際の例

```
vi /etc/sysctl.conf
  以下の行を修正
  # Semaphore
  kernel.sem = 250 32000 32 1024

/sbin/sysctl -p
/sbin/sysctl -a | grep sem
```

## 6. bash上に時刻を表示したい

作業履歴などの利便性が上がります。

```
[user@saba ~]$ export PS1="[\u@\h \W \t]\\$ "
[user@saba ~ 10:29:50]$
```

## 7. Disk逼迫しているのに実体が存在しない！
### 事象
webusa-ba-1/2間で`/`配下に30%近くの差が生まれている。
が、下記の通り`/`配下に逼迫させているディレクトリが存在しない

```
webusa-ba-1         webusa-ba-2
7.6M    /bin        7.6M    /bin
23M     /boot       23M     /boot
192K    /dev        196K    /dev
30M     /etc        30M     /etc
1.8G    /web_app    1.8G    /web_app
959M    /home       1.1G    /home
136M    /lib        136M    /lib
26M     /lib64      26M     /lib64
16K     /lost+found 16K     /lost+found
4.0K    /media      4.0K    /media
0       /misc       0       /misc
4.0K    /mnt        4.0K    /mnt
0       /net        0       /net
206M    /opt        206M    /opt
0       /proc       0       /proc
25M     /root       25M     /root
14M     /sbin       14M     /sbin
4.0K    /selinux    4.0K    /selinux
4.0K    /srv        4.0K    /srv
0       /sys        0       /sys
218M    /tmp        217M    /tmp
26G     /usr        26G     /usr
83G     /var        84G     /var
```

### 対処法
プロセスが削除しようとしたファイル(NAME項に(deleted)と書いてあるファイル)を裏で掴み続けていることがあり、実ファイルが存在しないことから`du`では表示されない模様。
`lsof`ではPIDを確認できるので、掴んでいるプロセスをKillすればOK。
　※killの際には、サービス影響に十分考慮すること

```
[root@webusa-ba-2 ~]# lsof |sort -k 7 |tail -n 50
COMMAND     PID      USER   FD      TYPE             DEVICE  SIZE/OFF       NODE NAME
～略～
jstat      6569    tomcat    1w      REG              253,0  43939230041   11404478 /tmp/tomcat/javastat_tmp.log (deleted)
[root@webusa-ba-2 ~]#
```

### 根本原因を探るには
PIDがわかる
↓
ps aufxwww |grep {PID}
↓
対象プロセスがわかる
↓
子プロセスなら問題の親プロセスまで辿れる
↓
ふむふむ・・・などなど...

今回はtomcatが掴んでいるようにみえるが、実際はcrontabでルーチンさせてるshellが掴んでいたというところまでたどり着いたので、tomcatという文字列だけみてtomcatッスネ・・・という判断を行うと危険なのでそこは注意
　※そもそもミドルウェアが/tmp/配下に何かを展開するのは妙だなというアプローチもある。