東京生まれHOUSE MUSIC育ち

悪そうな奴はだいたい友達なの?

録画サーバのCPU温度とHDD温度を確認する

夏に向かって、温度を調べる

これから夏に向かって温度がどんどん上昇していきます。

常に稼働している録画サーバのCPU温度がどうなっていくか不安なので、現時点の温度を確認しました。5月なので、まだ涼しいからこのタイミングでベースライン的な温度を測っておきたくて。

CPUの温度

以下でlm_sensorsをインストールします。

# yum install lm_sensors

以下でセンサーを検出します。yes/noを聞かれるの全てYesを答えます

# sensors-detect 

アイドリング時の温度

実機での温度出力は以下です。全て31度以下なので、良い感じです。

「Virtual device」が27.8°C になってます。「Virtual device」って何でしょう?調べたいところ。

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +119.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +31.0°C  (high = +78.0°C, crit = +100.0°C)
Core 0:         +31.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:         +30.0°C  (high = +78.0°C, crit = +100.0°C)

エンコード時の温度

mp4へのエンコード時は以下のように60度ぐらいまで上昇

# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:        +27.8°C  (crit = +119.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +60.0°C  (high = +78.0°C, crit = +100.0°C)
Core 0:         +58.0°C  (high = +78.0°C, crit = +100.0°C)
Core 1:         +60.0°C  (high = +78.0°C, crit = +100.0°C)

HDDの温度

HDDのSMART情報を取得するツールをインストールします。

yum -y install smartmontools

インストールしたら、SMART情報の出力です。「/dev/sda」は接続しているHDDです。多分、2台目のHDDを接続したら「/dev/sdb」になると思います。

# smartctl /dev/sda -A
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-3.10.0-693.21.1.el7.x86_64] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   119   099   006    Pre-fail  Always       -       234019189
  3 Spin_Up_Time            0x0003   100   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       921
  5 Reallocated_Sector_Ct   0x0033   099   099   036    Pre-fail  Always       -       81
  7 Seek_Error_Rate         0x000f   080   060   030    Pre-fail  Always       -       114838934
  9 Power_On_Hours          0x0032   090   090   000    Old_age   Always       -       9286
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       1
 12 Power_Cycle_Count       0x0032   100   037   020    Old_age   Always       -       930
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   098   098   000    Old_age   Always       -       2
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   070   070   000    Old_age   Always       -       30
190 Airflow_Temperature_Cel 0x0022   061   043   045    Old_age   Always   In_the_past 39 (Min/Max 38/40 #17)
194 Temperature_Celsius     0x0022   039   057   000    Old_age   Always       -       39 (0 6 0 0 0)
195 Hardware_ECC_Recovered  0x001a   046   029   000    Old_age   Always       -       234019189
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       9281 (249 232 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       3247295132
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       388916418

もう少し情報をということで、以下のwikipediaのページを参照すると、194番が温度になっています。

Self-Monitoring, Analysis and Reporting Technology - Wikipedia

実機で「smartctl /dev/sda -A」を実行してみます。194番は「39」となっていますので、39度ということなのかな。

HDDの温度は高いと感じる

このHDDの39度は高いように思います。というのも、運用しているNASのHDDもたまにチェックしていて、だいたい36度か37度だからです。

39度は2度ぐらいの差なので、そんなに大きな心配をしなくてもいいのかもしれませんが。

録画サーバでmp4へのエンコード開始と終了をslackに通知する

録画サーバでの録画後にm2tsファイルをmp4にエンコードしています。

試したみたところ、エンコードは番組の長さ分の時間がかかります。例えば、60分番組だったら、60分のエンコード時間がかかります。

ただもう少し実績値を知りたくて、暫定的ではありますが、エンコード開始とエンコード終了のタイミングをslackに通知するようにしました。

変更するファイル

以下のファイルを変更します。

/usr/local/bin/recordedEnc.sh

変更する個所

エンコードする行の前後にslackに通知する命令を入れます。

/usr/local/bin/ts2enc.pl "$1" "${dir_output}/${mp4file}" > /dev/null 2>&1

変更後

NowDateTime=`date '+%Y-%m-%d %T'`  ← 時間の取得
curl -X POST --data-urlencode "payload={\"text\": \"$NowDateTime START ${mp4file} encord \"}" https://hooks.slack.com/services/xxx/xxx/xxxxx ← エンコード開始を通知

/usr/local/bin/ts2enc.pl "$1" "${dir_output}/${mp4file}" > /dev/null 2>&1 ←元からあった個所

AfterDateTime=`date '+%Y-%m-%d %T'` ← 時間の取得    
curl -X POST --data-urlencode "payload={\"text\": \"$AfterDateTime END   ${mp4file} encord \"}" https://hooks.slack.com/services/xxx/xxx/xxxxx ← エンコード終了を通知

chinachuでの録画開始、録画終了をslackに連携する

はじめに

録画サーバで録画開始と録画終了をslackに通知するようにしました。

同じようなことを考えている人は私の他にもいらっしゃって、様々な方法があるようです。例えば、以下のようなページが参考になります。

上記のページを参考にしながら、自分の勉強を兼ねて実装してみました。

どうやって実現するか

色々と調べると開始と終了は以下のchinachuのログに出力されています。録画開始は「RECORD」という文字列、録画終了は「FIN」という文字列がキーワードになりそうです。このログを監視して、キーワードにひっかかった場合にslackに通知することを考えました。

/usr/local/var/log/chinachu-operator.stdout.log

Slackへの通知はIncoming Webhooksをcurlで使用する

slackへの通知はIncoming Webhooksを使用することにしました。URLだけ指定すればいいので、よりシンプルに実装できると考えたからです。

slackのIncoming Webhooks設定ページにサンプルとしてcurlでの使用方法が記載されています。それをほぼそのまま使用することにしました。

ログ監視はlogmonを使用する

最初、ログ監視はfluentdやnegiosを使ってみようと考えたのですが、設定が複雑そうでした。

そこで、logmonというツールを使ってみることにしました。以下の記事を参照すると、簡単に設定することができるとわかりました。

qiita.com

logmonのインストールと設定

上記のページにインストール方法や設定方法が書いてあるので、そのとおりにインストールしました。

監視用の設定は以下です。

/etc/logmon/logmon.conf

chinachu用に設定したのは以下です。chinachuのログである「/usr/local/var/log/chinachu-operator.stdout.log」を監視対象にしています。ログに「RECORD」または「FIN」の文字列があれば、出力されたログのままslackに通知するというように設定しています。

# Monitor for messages
:/usr/local/var/log/chinachu-operator.stdout.log
(RECORD|FIN)
curl -X POST --data-urlencode "payload={\"text\": \"<%%%%>\"}" https://hooks.slack.com/services/XXX/XXX/xxxxxxxx

録画サーバを約2週間使用してのディスク使用状況

2週間使用して、362.1GB使用。全体の4分の1ぐらいの使用です。

f:id:padobure:20180520222729p:plain

以下の記事で30日経過したらファイルを削除するというのを準備していましたが、それほど必要ではなさそうです。

nomusicnolife.hatenablog.com

ポケモンgo 5月19日のコミュニティデイ成果

今回のコミュニティデイに参加しました。

以下、成果です。

ブラストバーンを覚えた、リザードン

f:id:padobure:20180519223323p:plain:w250

色違いのヒトカゲ

f:id:padobure:20180519223325p:plain:w250

なんだかんだ言って、また続けてます。

CentOS7でradikoを録音する環境を構築した

この記事で書くこと

CentOS7にradikoを録音する環境を作りました。その手順をまとめています。

背景

過去にこの記事を書いて、ubuntu環境でradikoを録音できる環境を構築しました。 現在、VM上にCentoOSを入れてまして、ubuntuではなくCentOS上で動かすことができないか試行錯誤してみようと考えました。

nomusicnolife.hatenablog.com

構築手順

検索すると、先達が様々な記事を書いてくれています。それらを参考にしました。自分のスキルが不足していることから、手順をそのままなぞっているだけのものもあります。。。

それでも、動けばいいと考えて、突き進めています。

必要なアプリケーションのインストール

yumを使用すれば、必要なアプリケーションはほとんどインストールできます。

# yum -y install autoconf automake make gcc gcc-c++ pkgconfig w get libtool zlib-devel
# yum -y install wget git vim libxml

インストールでうまくいかなかったポイント

インストールでうまくいかなった個所とそれを乗り越えるために参考にした記事を以下に書きます。

swftools

以下の記事を参考にしています。コンパイルしている途中でワーニングが出力されます。しかし、コンパイルが通ればいいと考えたので無視しています。

swftools のインストールで参考にした記事

qiita.com

ffmpeg

ffmpegをインストールするのに参考にした記事

qiita.com

radiko.sh

radiko.shのダウンロード。これはシェルを動かすようにすればいいので、つまづきませんでした。

簡易Radiko録音スクリプト · GitHub

録画サーバを1週間運用して変更した設定

録画サーバを試行錯誤しながら約1週間運用してきました。

1週間経過する中で、以下のように変更しました。

録画ファイルの保存先

当初、m2tsファイルは/recorderというディレクトリに保存していました。同じディレクトリにmp4に変換した動画ファイルも保存して、パソコンやiPhoneからアクセスするようにしていました。

しかし、ディスクのサイズを確認すると、1.5TBのディスクを使用しているのに、/recorderの保存領域が500GBとなっていました。

色々と調べてみると、minimalでのインストール時はディスクの割り当てを変更できずにデフォルトでCentOSがインストールされてしまうということがわかりました。

ディスクの割り当てを変更するのは、いったん別領域のディスクをバックアップして、アンマウントして、再びマウントしなおすような複雑な手順を踏まなければいけないようです。

ということで、m2tsファイルとmp4ファイルを以下のように分けて保存するようにしました。

  • m2tsファイル:/home/chinachu/chinachu/recorded に格納。(chinachuのデフォルト)
  • mp4ファイル:/recorder sambaで共有フォルダにして、パソコンやiPhoneからアクセス可能にする

NASをマウント

保存しておきたい番組のファイルはNASであるDS215jに移動するようにしています。

ほとんどの番組は1回観たら2度と観ることはありません。けど、フリースタイルダンジョン等は複数回観ることが多いので、そういう動画はNASに移動するようにしました。

パソコンにダウンロードして、NASにアップロードするという運用をすると、とても面倒です。

そこで、移動が簡単になるようにsambaのクライアントを導入し、以下のコマンドでNASの共有フォルダをマウントするようにしました。(IPアドレスNASのアドレスです)

mount -t cifs //192.168.1.11/video /media

移動するのはmp4ファイルです。現時点では、m2tsファイルはファイルサイズが大きく扱いにくいため、mp4に変換したら使用することは無いと考えてます。

30日以上経過したm2tsファイルを削除する

m2tsファイルは1時間番組で約7GBぐらいのファイルサイズになります。

1.5TBのディスクがあるといっても、すぐにディスクFULLになると思います。

そこで、実際は動かしていませんが、以下のcronに用意しました。30日以上過去のm2tsファイルを削除するというものです。

find /home/chinachu/chinachu/recorded *.m2ts -mtime +30 -delete

ただ、chinachuの config.jsonを参照すると、以下のようになっていてディスクがいっぱいの場合は、古いファイルを削除するというような設定になっています。

"storageLowSpaceAction": "remove",

ということなので、cronは用意したものの実際は動かさないでchinachuの動作を確認しようと考えています。