NetAppのperfstatデータ収集ツールで取得したファイルを分解する


現用のNetAppの状況確認をするために「perfstatデータ収集ツール」というのが配布されている。
注:ONTAP 9.5以降はperfstatは非対応とのこと

rsh/sshで対象のNetAppにログインして、いろんなコマンドを実行して、1つのテキストファイルとして出力をする。

この「1つのテキストファイル」というのがくせ者で、200MBぐらいのファイルができたりする。

これだとエディタで取り扱いづらいので細かく分割することにした。

中をみてみると「=-=-=-=-=-= CONFIG IPアドレス PRESTATS =-=-=-=-=-= aggr status -v」という感じで「 =-=-=-=-=-= 」区切りでファイルが出力されている。

それを元にファイルを分割したのが下記スクリプト。

$inputfile="x:\tmp\source\perfstat7_20191122_1400.txt"
$outdir="x:\tmp\output"

$filename=""

Get-Content $inputfile -Encoding UTF8 | ForEach-Object {
    $line=$_
    if( $line.Contains("=-=-=-=-=-=") ){
        $filename=$line
        $filename=$filename.Replace("=-=-=-=-=-= ","")
        $filename=$filename.Replace("/","-")
        $filename=$filename.Replace(":","")
        $filename=$outdir+"\"+$filename+".txt"
        New-Item $filename
    }
    if($filename -ne ""){
        $line | Add-Content $filename
    }
}

今回は1回しか実行しないので速度を気にする必要がないので簡単さを優先している。

もし、出力速度を気にするのであれば1行毎にAdd-Contentするのは非常に効率が悪いので工夫が必要となる。

参考例:「PowerShellで巨大なファイルをGet-Contentし、Export-Csvするのを省メモリで行う


2019/11/25 追記

上記のスクリプトだと遅すぎで、約200MBのファイル処理に5時間かかりました。

やはり改行のみ行が数万行ある、というのが悪かったようです。

また、同じヘッダ行が何回か登場するようで単純に「New-Item」としているとファイル名が重複しているというエラーがでてしまっていました。

さすがに5時間はないなーということで、高速化処理をしたのが下記となります。

実行にかかる時間は2分と大幅短縮となりました。

$inputfile="x:\tmp\source\perfstat7_20191122_1400.txt"
$outdir="x:\tmp\output2"

$filename=""

$results=@()
$linecount=0

Get-Content $inputfile -Encoding UTF8 | ForEach-Object {
    $line=$_
    if( $line.Contains("=-=-=-=-=-=") ){
        if($filename -ne ""){
            $results | Add-Content $filename
            $results=@()
            $linecount=0
        }
        $filename=$line
        $filename=$filename.Replace("=-=-=-=-=-= ","")
        $filename=$filename.Replace("/","-")
        $filename=$filename.Replace(":","")
        $filename=$outdir+"\"+$filename+".txt"
        if ( !(Test-Path $filename) ){
            New-Item $filename
        }
    }

    if($filename -ne ""){
        $results += $line
        $linecount++
        if(($linecount % 1000) -eq 0 ){
            $results | Add-Content $filename
            $results=@()
        }
    }
}

技適未取得機器を用いた実験等の特例制度で使えるものは何か確認してみた


技適未取得機器を用いた実験等の特例制度」の「技適未取得機器を用いた実験等の特例制度 関係法令」を見ると下記の記載がある。

法第四条の二第二項の規定により法第三章に定める技術基準に相当する技術基準として総務大臣が指定する技術基準は、次のいずれかに該当するものとする。
一 法第三章に定める技術基準
二 国際電気通信連合無線通信部門の勧告M.1450-5に定める技術基準及び米国電気電子学会が定める規格のうち、次のいずれかのもの
1 IEEE802.11b
2 IEEE802.11a
3 IEEE802.11g
4 IEEE802.11n
5 IEEE802.11ac
6 IEEE802.11ad
7 IEEE802.11ax(Draft 1.0からDraft 4.0まで)
三 Bluetooth SIGが定める規格のうち、Bluetooth Core Specification Version 2.1からVersion 5.1までのいずれかのもの
四 米国電気電子学会が定める規格のうち、IEEE802.15.4
五 一般社団法人電波産業会が定める規格のうち、ARIB STD-T107又はARIB STD-T108
六 LoRa Allianceが定める規格のうち、LoRaWAN AS923
七 Sigfox S.A.が定める規格のうち、Sigfox RC3
八 国際電気通信連合電気通信標準化部門の勧告G.9959に定める技術基準
九 米国電気電子学会が定める規格のうち、IEEE802.15.4g
十 XGPフォーラムが定める規格のうち、A-GN6.00
十一 欧州電気通信標準化機構が定める規格のうち、ETSI TS 103 357 Lfour family
十二 欧州電気通信標準化機構が定める規格のうち、ETSI EN 302 264又はETSI EN 303 360

これらの示す機器が具体的に何であるのかを確認した。

一 法第三章に定める技術基準

該当の記述は「電波法 第三章の二 特定無線設備の技術基準適合証明

「技術基準適合証明」と「特定無線設備の工事設計についての認証」の双方を指している
一般的には両者をあわせて「技適など」と表現される。

二 国際電気通信連合無線通信部門の勧告M.1450-5に定める技術基準及び米国電気電子学会が定める規格のうち、次のいずれかのもの

1 IEEE802.11b
2 IEEE802.11a
3 IEEE802.11g
4 IEEE802.11n
5 IEEE802.11ac
6 IEEE802.11ad
7 IEEE802.11ax(Draft 1.0からDraft 4.0まで)
まぁ、2.5GHzと5Ghzを使用するWiFiのことである。

三 Bluetooth SIGが定める規格のうち、Bluetooth Core Specification Version 2.1からVersion 5.1までのいずれかのもの

そのままBluetoothデバイスである。

四 米国電気電子学会が定める規格のうち、IEEE802.15.4

LR-WPAN(Low Rate Wireless Personal Area Network)である ZigBee,Wi-SUN,EchoNet Liteなどのスマートグリッド機器などが該当すると思うが、後述の802.15.4gとの違いがいまいち認識出来ていない。

920MHz帯を使用する機器を想定しているものと思われる。

五 一般社団法人電波産業会が定める規格のうち、ARIB STD-T107又はARIB STD-T108

ARIB STD-T107は「特定小電力無線局920MHz帯移動体識別用無線設備」でスマートタグ

ARIB STD-T108は「920MHz帯テレメータ用、テレコントロール用およびデータ伝送用無線設備」で、Z-Waveなど。また、後述するG.9959相当

六 LoRa Allianceが定める規格のうち、LoRaWAN AS923

「LoRaWAN V1.0.2 forAS923MHz ISM Band(AS923)」というのは

ヨーロッパ向け認証プログラムをベースとし、日本を含むアジア 10 カ国向けに周波数帯(923MHz)などを変更した認証プログラム。対象国は、日本、ブルネイ、カンボジア、インドネシア、ラオス、ニュージーランド、シンガポール、台湾、タイ、ベトナムの 10 の国や地域

https://www.toyo.co.jp/files/user/corporate/doc/release/170905_TOYO_LoRaWANAS923_65135.pdf

LoRaWAN® Regional Parameters」によるとChannel Planは10種類あるようだ。

七 Sigfox S.A.が定める規格のうち、Sigfox RC3

Sigfoxの「Geographical zones」の「RC3」は日本向け設定という意味で、923.200MHzを使用する。

なお、RC1~RC7まであるが全部使用する周波数が異なるので地域違いは使うことができない。

八 国際電気通信連合電気通信標準化部門の勧告G.9959に定める技術基準

G.9959 : Short range narrow-band digital radiocommunication transceivers – PHY, MAC, SAR and LLC layer specifications」でARIB STB-T108 相当(Z-waveなど)

九 米国電気電子学会が定める規格のうち、IEEE802.15.4g

すでに登場しているIEEE802.15.4の詳細規格で、スマートメーター用の規格・・・という認識でいいのだろうか?

十 XGPフォーラムが定める規格のうち、A-GN6.00

sXGP (shared XGP) Specifications Version 1」で1.9GHzを使用する新自営システム

周波数帯域を1.9GHz帯としたTD-LTE方式の小電力携帯電話システムで、構内PHSの代わりに使用されることになるが、スマホが流用できるので期待されているもの。

十一 欧州電気通信標準化機構が定める規格のうち、ETSI TS 103 357 Lfour family

Short Range Devices;Low Throughput Networks (LTN);Protocols for radio interface A

一見、EU圏発祥の規格っぽいが、「SONY ELTRES」で920MHz帯を使用する。

十二 欧州電気通信標準化機構が定める規格のうち、ETSI EN 302 264又はETSI EN 303 360

ETSI EN 302 264は「Short Range Devices;Transport and Traffic Telematics (TTT); Short Range Radar equipment operating in the 77 GHz to 81 GHz band; Harmonised Standard covering the essential requirements of article 3.2 of Directive 2014/53/EU

77GHz~81GHz帯を使用する機器。79GHz帯高分解能レーダシステムで、ARIB STD-T111「79GHz帯高分解能レーダー」

ETSI EN 303 360「Short Range Devices; Transport and Traffic Telematics (TTT); Radar equipment operating in the 76 GHz to 77 GHz range; Harmonised Standard covering the essential requirements of article 3.2 of Directive 2014/53/EU; Obstacle Detection Radars for Use on Manned Rotorcraft

76GHz~77GHz帯を使用する機器。76GHz帯ミリ波レーダシステムで ARIB STD-T48「特定省電力無線局ミリ波レーダー用無線設備」

どちらも車載レーダーとして使用されるため、自動運転用のシステム関連と想定される。(下記は「電波防護に関する国外の基準・規制動向調査」からの引用」

楽天モバイルの無料サポータープログラムをWindowsタブレットDELL Venue 10 Pro 5055で使って見た


楽天モバイルの無料サポータープログラムのSIMをmicroSIMスロットがついているDELL Venue 10 Pro 5055にさしてみた。

SIMをさしてみると「Rakuten」と認識はしているものの通信が出来る状態にならない。

自宅だとバンド3の入りが悪いので安定してバンド3で受信できる環境で試してみると、アンテナピクトが増減しているので受信できているものの通信はできない。

DELL Venue 10 Proで使用されている通信カードは Dell wireless 5810e で、現状のfirmwareは FIH7160_V1.2_WW_01.1528.31 だった。

新しいバージョンってあるのか?と探してみたところ「Dell Wireless 5810e LTE Mobile Broadband Driver」に「汎用ファームウェアv1616.01」という記載が・・・

そういえば、Windows10をインストールした際にWindows標準ドライバで認識したのでこれをインストールしてなかったな、ということでインストール。

インストール後に再起動し、初回ログインをすると、firmwareアップデートが実行されました。

その結果、firmwareは「FIH7160_V1.2_WW_01.1616.01」になり、アンテナ認識は「Rakuten(LTE)」表記に変化。

APN設定は、以下でOKでした。

APN名:rakuten.jp
ユーザ名/パスワード:空欄
サインイン情報:なし
IPの種類:既定

なお、動作状況からみると Dell wireless 5810e はバンド18には非対応である模様

FIH7160で検索すると「インテル® XMM™ 7160 スリムモデム」が出てくる。どうやらこれを利用しているようだが、対応バンドとしては「15-band LTE, 8-band HSPA, 4-band EDGE, MSC33」としか記載されていないので実際にどこで使えるのかが分からない。

PinePhone BraveHeart Limited Edition購入申し込み


Allwinner A64搭載のオープンハードウェア「PinePhone BraveHeart Limited Edition」の申し込みが始まったので手続きしてみた。

「BraveHeart Limited Edition」 とは「勇者の心」、意訳すると「人柱エディション」ですね。

どう人柱なのかというと、まず、発送時のハードウェアにはOSが入っていない。

先行してOS開発者向けにPinePhone Developer kitというのが2019年初頭から出回っていて、いろんなOSが開発中。

どんなOSがあるかと「Project Don’t be evil」のページを確認してみると・・・

OS名称ベース
Postmarket OSAlpine Linux
UBPortsUbuntu Touch
KDE Plasma MobileUbuntu Touch+Lineage OS/KDE
Sailfish OSMeeGo OSだけどAndroid寄りの商用
Maemo LesteMeeGo OS 
NixOSLinuxベースの関数型ディストリビューション
LunaOSpalmOSの末裔webOS
Nemo MobileSailfish OSの全てをOSS実装に?

Allwinner SoCなだけあってLinux kernelベースのものがずらりと並んでいます。

現状は基本的にUbuntuなどが稼働しているマシンにUSB接続してfirmwareを書き込むという感じになっている。

人柱エディションを卒業するまではこの初期導入の高さは抜けられないでしょう。

次に、メモリスペックが2GBというところが難点といえば難点ですが、そもそも↑であがっているOSが動くハードウェアでメモリ2GBって普通なので、まぁ・・・

PinePhoneの通信関連のスペックは下記の様になっている。

  • Worldwide, Global LTE bands
  • LTE-FDD: B1/ B2/ B3/ B4/ B5/ B7/ B8/ B12/ B13/ B18/ B19/ B20/ B25/ B26/ B28
  • LTE-TDD: B38/ B39/ B40/ B41
  • WCDMA: B1/ B2/ B4/ B5/ B6/ B8/ B19
  • GSM: 850/900/1800/1900MHz
  • WLAN: Wi-Fi 802.11 b/g/n, single-band, hotspot
  • Bluetooth: 4.0, A2DP
  • GPS: Yes, with A-GPS, GLONASS

使用されるモジュールは「Quectel Wireless EG25-G」で、メーカ製品ページには「JATE/TELEC」と技適などが取得されているような記述が・・・まぁ、アンテナ込みでの認証になるところチップのみ提供っぽいから無理なような気が・・・

ともかく到着が楽しみです

CentOS7でルータのログを受け取るrsyslog設定


ここ1ヶ月、長らく使っていたWiFiルータの一部プロセスが良く死んでいた。

具体的には固定IP割り当てしているやつらは問題ないのだが、DHCPによるIP割り当てがうまく行かず、またルーター管理画面にアクセスしようとしても途中で接続が切断される、という状態になっていた。

復帰方法は電源off/onしかないのだが、まぁ、最近のWiFiに対応するやつにするかと4千円程度のものに交換した。

ルータ交換後の様子を継続的に見るためにCentOS7サーバにログを飛ばしておくか、と設定してみた。

その1 firewallの穴開け

標準ではsyslogポート(514)は開いていないので、開ける。

まず、firewalldが持っている規定のサービス名を確認

[root@blog ~]# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql munin-node murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius redis rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server
[root@blog ~]#

「syslog」が使えそう。あと、今回は不要だけど「syslog-tls」も入れておくか、ということで以下を実行

[root@niselog ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp14s0
  sources:
  services: dhcpv6-client http https ssh
  ports: 
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@niselog ~]# firewall-cmd --permanent --zone=public --add-service=syslog
success
[root@niselog ~]# firewall-cmd --permanent --zone=public --add-service=syslog-tls
success
[root@niselog ~]# firewall-cmd --reload
success
[root@niselog ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp14s0
  sources:
  services: dhcpv6-client http https ssh syslog syslog-tls
  ports: 
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@niselog ~]#

また、「22.5. ロギングサーバーでの RSYSLOG の設定」によればSELinuxによりポート制限をしている事もあるので「semanage port -l」でsyslogに許可されているポートを確認しろ、とのこと。

[root@niselog ~]# semanage port -l | grep syslog
syslog_tls_port_t              tcp      6514, 10514
syslog_tls_port_t              udp      6514, 10514
syslogd_port_t                 tcp      601, 20514
syslogd_port_t                 udp      514, 601, 20514
[root@niselog ~]#

その2 rsyslogにポート514での受信許可

標準の/etc/rsyslog.conf ではポート514の使用について下記の様にコメントアウトされています。

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

これのコメントを外します。

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

設定後、rsyslogの再起動で/var/log/messagesにログがたまる。

[root@niselog rsyslog.d]# systemctl restart rsyslog
[root@niselog rsyslog.d]# systemctl status -l rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since 金 2019-11-01 11:04:53 JST; 1s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 2872 (rsyslogd)
   CGroup: /system.slice/rsyslog.service
           mq2872 /usr/sbin/rsyslogd -n

11月 01 11:04:53 niselog systemd[1]: Starting System Logging Service...
11月 01 11:04:53 niselog rsyslogd[2872]:  [origin software="rsyslogd" swVersion="8.24.0-41.el7_7.2" x-pid="2872" x-info="http://www.rsyslog.com"] start
11月 01 11:04:53 niselog systemd[1]: Started System Logging Service.
[root@niselog rsyslog.d]#

その3 ログを分ける

標準だと/var/log/messagesにまとめられてしまうため、ログを分離する。

/etc/rsyslog.d/remote.conf というファイルを新規作成し、下記を書いた。(「gateway」はルータについているホスト名)

if $fromhost == 'gateway' then {
  -/var/log/remote/gateway.log
  stop
}

これを設定したあと、「systemctl restart rsyslog」で/var/log/remote/gateway.log にログが保存されるようになった。

なお、最初、上記の「-/var/log/remote/gateway.log」ところは「-/var/log/remote/%fromhost%.log」として%fromhost%がホスト名に置き換わることを期待したのですが、実際に作られたログファイル名は「 /var/log/remote/%fromhost%.log 」とそのままでした・・・