【AristaTIPS】ディレクトリ圧迫事象について
こんにちは。Arista Networks ヘルプデスク担当のNoryです。
レイヤー1障害と予期せぬ再起動事象に続き、
今回はディレクトリが圧迫してしまう事象について、
パターン毎の確認方法、原因、対処について書いていきたいと思います。
この事象は幾つかの理由により一部のディレクトリが圧迫される(使用率が100%になる)ことで、
必要なデータの保存ができない、エラーメッセージが出続けてしまうなど、
様々な影響を与えてしまうものとなります。
この記事では以下3種類の事象に焦点をあてて説明します。
①/var/core、/var/log/agentsディレクトリの使用率が100%になる ②/var/core、/var/log/agentsディレクトリの使用率が100%になる ③/var/logディレクトリの使用率が100%になる |
●調査に必要なログ
基本的にはshow tech-supportをもとに後述のような確認をします。
show tech-supportの調査結果から、更に過去に遡る必要がある、
または事象発生時にデバッグ系のログでは
何が出力されているかを追求していくこともあり、以下のログを追加で頂くこともあります。
・bash sudo tar -cvf – /mnt/flash/schedule/tech-support/* > /mnt/flash/history-tech-$HOSTNAME-$(date +%d_%m.%H%M).tar ※通称「history-tech」と呼ぶ、flash配下に定期保存される過去のshow tech-support。 ただし「no schedule tech-support」設定があると保存されません。 ・show logging system ・show agent logs ・show agent qtrace |
まずはshow tech-supportから調査を進めていきますが、
いつから圧迫しだしたかを追うためにshow tech-supportでは難しい場合などに、
過去情報やデバッグログが含まれる上記の追加ログを使って追求していきます。
●ログ確認
ここではshow tech-supportに含まれるものについて、
最初の①②③事象それぞれのログ例を記載します。
show logging
・SuperServer Agentが初期化される(①②)
SuperServer: %AGENT-6-INITIALIZED: Agent ‘SuperServer’ initialized; pid=11111 SuperServer: %AGENT-6-INITIALIZED: Agent ‘SuperServer’ initialized; pid=22222 SuperServer: %AGENT-6-INITIALIZED: Agent ‘SuperServer’ initialized; pid=33333 |
※pid(Process ID)の値が異なる同様のログが延々と出力され続けます
+上記に加え、スイッチへのログイン時に以下メッセージが出力され、
記載のディレクトリの空き容量を増やすよう促されています
Warning: the following filesystems have less than 10% free space left: tmpfs (on /var/core) 0% (0 Available) tmpfs (on /var/log) 0% (0 Available) Please remove configuration such as tracing and clean up the space. |
・プロセスが頻繁に再起動を要求する(①②)
ProcMgr-worker: %PROCMGR-3-PROCESS_DELAYRESTART: ‘Strata-Fabric0-0’ (PID=1234) restarted too often! Delaying restart for 120.0 (until 2022-03-01 01:00:00.12345 |
※上記1点目のログの他、様々なAgentからの初期化ログがセットで出力されるほか、
ProcMgrのWARMSTART、PROCESS_STARTED、PROCESS_TERMINATED、
などの関連性のあるログが多数出力されます。
・EventMonデータベースへの書き込みができない(③)
EventMon: %EVENTMON-3-DB_WRITE_FAILED: A sqlite database or disk is full exception occurred when writing to the EventMon database |
bash ls -ltr /var/log/agents
・SuperServerログが大量にある(①②)
-rw-rw-rw- 1 root root 210112 Aug 28 20:30 SuperServer-2259 -rw-rw-rw- 1 root root 206664 Aug 28 20:30 SuperServer-11380 -rw-rw-rw- 1 root root 208172 Aug 28 20:30 SuperServer-11417 |
※③事象では/var/log/agents配下に大量にログが出力されることはありません
bash ls -ltr /var/core
・SuperServerログが大量にある(①②)
-rw-rw-rw- 1 root root 18885446 Aug 28 20:30 core.11380.1630150223.SuperServer.gz -rw-rw-rw- 1 root root 18938206 Aug 28 20:30 core.11417.1630150233.SuperServer.gz -rw-rw-rw- 1 root root 18875262 Aug 28 20:30 core.11453.1630150243.SuperServer.gz |
※③事象では/var/core配下に大量にログが出力されることはありません
bash df -h
・/var/coreが100%(①②)
tmpfs 388M 388M 0 100% /var/core |
・/var/logが100%(①②③)
tmpfs 388M 388M 0 100% /var/log |
・その他のディレクトリが100%(①②)
/dev/loop0 908M 908M 0 100% /rootfs-i386 |
①②については後述する原因によってSuperServer Agentのクラッシュが頻発し、
その度に上記ディレクトリにクラッシュログが大量に生成されるために
関連ディレクトリが圧迫されてしまう、という仕組みとなります。
show agent logs crash
・SplunkForwarderによるSuperServerのクラッシュログ(②)
Error: Stat missing: ‘/ar/Sysdb/cell/1/agent/sync/config/SplunkForwarder’ Error: Stat missing: ‘/ar/Sysdb/cell/1/agent/pingResponse/SplunkForwarder’ Error: Stat missing: ‘/ar/Sysdb/cell/1/agent/config/SplunkForwarder’ Error: Stat missing: ‘/ar/Sysdb/cell/1/agent/sync/configSysdb/SplunkForwarder’ Error: Stat missing: ‘/ar/Sysdb/cell/1/agent/status/SplunkForwarder’ |
・/var/logの使用率が100%のログ(①②)
Error: Could not create new tracefile 2021-09-11 06:45:05.384290 29414 Log 0 %AGENT-6-INITIALIZED: Agent ‘SuperServer’ initialized; pid=29414 2021-09-11 06:45:06.514888 29414 SuperServer 3 service DhclientManager is warm 2021-09-11 06:45:06.515049 29414 SuperServer 3 service Timezone is not warm Handler for Tac.ClockNotifiee raised an uncaught exception! |
※③事象ではクラッシュログが出力されることはありません
bash dmesg -r | grep -v ‘^<7>’ | tail -n 1000
・SuperServer Agentが中断されたことを示すI/Oエラー(①)
<3>[95570939.477514] end_request: critical target error, dev sda, sector 1609487 <4>[95570939.496481] Pid: 3289, comm: SuperServer Tainted: P O 3.4.43.Ar-7226076.4186M #1 <4>[95570939.701821] lost page write due to I/O error on sda1 |
※②③事象では原因を示すデバッグログが出力されることはありません
●調査後の流れ
原因によって対処も異なり、②③のように対処後に再発が見られないケースもありますが、
①のように一時的な場合、初回はスイッチの再起動をご実施いただき、
経過観察をご案内しております。
再発した場合、これは初回と全く同じ原因要因だった場合に限りますが、
メーカー調査のもと本体故障と見なされた場合には良品との交換対応へ移る可能性もあります。
ご契約内容によりますが、お客様へ良品をお届けするのとは別に、
私たちは裏でメーカー(Arista社)へここまでの状況を伝え、メーカー側でも詳細調査が行われた後、
RMA(Return Merchandise Authorization)処理を依頼し、故障品と良品を交換する対応をしていたりします。
●最後に
今回はディレクトリが圧迫する事象について幾つかのパターンに分けて書いてみました。
少しは参考になったでしょうか?
Aristaヘルプデスクからは基礎的な情報を、このブログを通してお届けしていきますので、
今更な情報も多いかもしれませんが、参考になれば幸いです。
これからもArista Networks製品と私たちヘルプデスクをよろしくお願いいたします。