メインコンテンツまでスキップ

現場事例集

「こうしてください」ではなく「こうなって、こう解決した」の記録です。 2026年2月から9月まで実際の現場で経験し解決したものだけをまとめました。

この文書の読み方

一般的な手順や基本的な使い方はここにはありません。それは トラブルシューティング と 技術トラブルシューティング が正本です。

ここにあるのは症状 → 原因 → 対処の三行です。今の症状と似たものを探して 原因候補として使ってください。残っている数字はプロトコル標準やライブラリのデフォルト値のような知識そのもの であるものだけで、IP・ホスト名・顧客名は除いています。

1. 現場設置・ネットワーク​

PLC に ping が通らずデータをやり取りできない​

  • 症状 現場設置後 PLC と通信不可。ping 無応答。
  • 原因 PLC IP とエッジ PC に割り当てる IP を区別していませんでした。
  • 対処 エッジ PC IP をPLC と同じ帯域・異なるホスト・同一マスクに設定します。出張前に表に両方の IP を記入し、異なる値であることを確認してから出発しましょう。
  • 確認 両方の通信が同時に切れる場合は IP 衝突をまず疑います。ping → ポート → read の順に絞り込みます。

三菱のポートが分からずエンジニア待機だけで終わる​

  • 症状 MC プロトコルのポートが分からず作業が止まる。
  • 原因 三菱には公式固定ポートがありません。 GX Works の「オープン設定」で指定する値です。
  • 対処 エンジニアには次の4点だけを指定して依頼します — ① オープン設定画面 ② プロトコル・オープン方式・自局ポート ③ MC プロトコル用設定の有無 ④ 接続許可 IP 制限。「通信設定はどうすればいいですか」と漠然と聞きません。
  • 参考 慣行値は内蔵イーサネット 1025・モジュール 2001 で、5001・5002 は予約です。5007 はライブラリのデフォルト値であり、三菱のデフォルト値ではありません。

ping・ポートは通るのに値が読めない​

  • 症状 接続はできるのにメモリ値が入ってこない。
  • 原因 PLC DB ブロックのメモリアドレス値の問題。
  • 対処 PLC エンジニアにDB ブロックアドレス値の確認を依頼します。アドレスが正しく接続オプションに問題がなければ、エッジ側のスキャン問題はないことが現場データで証明されています。その先は PLC 側の対応です。

盤の扉を閉めると通信が不安定になる​

  • 症状 盤の扉を閉めるとネットワークが非常に不安定になり、開けておくと良好。
  • 原因 厚い盤の内部にエッジ PC・LTE ルーター・アンテナまで全部収めた構成。
  • 対処 アンテナを盤の外部に設置します。穴あけ位置は電気室担当が指定します。外部設置時は接合部のシリコン処理が必須です — 固定不良を防ぎます。

実査で確認項目を見落とし現場で詰まる​

  • 症状 準備したつもりが現場で変数が次々に出てくる。
  • 対処 実査の6項目を固定します — 盤の構造・筐体の種類 / PLC モデル・状態 / ネットワーク通信方式 / AP 区域の ping 状態 / エッジ PC 設置位置 / アンテナ位置。筐体はエッジミニ PC + LTE ルーター + 2口電源タップ構成で、電源アダプターの位置を必ず考慮します。

エッジ PC の設置台数を確定できなかった​

  • 症状 実査を終えたのに機器台数が決まらない。
  • 原因 収集タグ数が確保されていませんでした。 タグ数と収集周期がないと機器あたりの負荷が分からず台数を決められないのに一覧がなく、設置位置も限られていて追加設置が難しい状況でした。1:1 マッピングを前提にしていましたが、顧客側は 1:N を要求していました。
  • 対処 実査前に ① 事業所別 PLC タグ一覧・数 ② 設置情報フォーマット(PLC/SCADA・IP/PORT・プロトコル) ③ 新規区間ネットワーク構成案を先に受け取ります。

PLC にイーサネットポートがない、または SCADA PC 経由を要求された​

  • 症状 イーサネット TCP 直結前提が成立しない。「PLC に接続された PC から取ればいいのでは」という要求、または複数の PLC が SCADA PC の DB にのみ記録される構造。
  • 対処 実査時にPLC イーサネットポートの有無 / SCADA 経由の有無 / SCADA DB の種類・記録方式を必ず確認し、収集方式を事前に決めます。

テストツールを接続したら収集が壊れた​

  • 症状 検証ツール接続後、既存の収集が拒否されたり乱れたりする。
  • 原因 MELSEC のような単一接続スロット機器に2つ目の TCP 接続を開いてしまいました。
  • 対処 次の3つを禁止します。
    1. 収集中の PLC への2つ目の接続禁止 — 該当 OPC を先に停止します。
    2. write 禁止 — ツールの引数一つで write になってしまいます。
    3. プローブタイムアウト1秒禁止 — 機器の accept 遅延実測は約2.6秒です。3〜5秒に設定します。

2. 起動​

起動後、全エンドポイント無応答 + ping retry ログが氾濫​

  • 症状 リクエストがすべて timeout(code=000)。
  • 原因 dev.mode=EDGE ですが、外部プラットフォームの Web ポートが死んでいて起動がブロックされていました。
  • 対処 dev.mode=STANDALONE に変えて再起動し、外部が復旧したら元に戻します。server.host も合わせて確認します。

Web 画面が3〜4分ごとに固まる​

  • 症状 周期的に Web が死んで復活する。
  • 原因 プラットフォーム未接続。 接続できないと Web コンテキストが3〜4分ごとにリロードループに陥ります。接続されると止まります。Web 自体の問題ではありません。
  • 対処 プラットフォーム接続の復旧が根本対策です。

認証キーを変更した後 NPE が無限に発生​

  • 症状 ログにdm is null NPE が延々と積み上がり、DB 関連機能が全て死ぬ。
  • 原因 キーが間違っていると API client の初期化が403 で hard-failし、その結果DatalakeManager が初期化されず DB 層が崩壊します。正常なキーの場合はフォールバックで立ち上がります。
  • 対処 元のキーに戻して再起動します。起動ログの**DataSource initialized — ready**行で確認します。

3. プラットフォーム上り(送信)途絶​

エッジの Web・収集は正常なのにプラットフォームにデータが上がらない​

最も頻繁に遭遇する形です。

  • 症状 現場収集と Web は問題ないのに上りだけが止まります。Web ポートの TIME-WAIT が100個以上急増します。

  • 原因 回線瞬断後、MQTT 再接続の CONNECT に認証情報が欠落してプラットフォームが拒否し、無限再接続に陥ります。最初の起動経路には認証情報が入るため、一度切れるとアプリは自力で復旧できません。

  • 対処 Web アプリの再起動でセッションが復旧します。再発防止は下記の watchdog です。

  • 確認 特徴は「プラットフォームの Web ポートは開いているのに MQTT セッションがない」です。

    nc -z -w2 <플랫폼IP> <웹포트> && echo ROUTE_OK
    ss -tan | grep -c "ESTAB.*<플랫폼IP>:<MQTT포트>"   # 1 정상 / 0 끊김

瞬断は数秒なのに数日間上り中断​

  • 症状 7秒瞬断後3時間中断、瞬断1回で11日中断。
  • 原因 上記と同じです。Web・PLC 収集・回線が全て正常だったため誰も気づけませんでした。
  • 対処 自動復旧(watchdog)を配備します。瞬断の長さと中断の長さは無関係なので、監視者のいない機器を優先的に対処します。

プラットフォームに蓄積されないのにエッジばかり調べ続けていた​

  • 症状 上りはできているのにプラットフォームにデータが残らない。
  • 原因 エッジではなくプラットフォームの保存経路でした。ブローカー前のトピックキャプチャでエッジの発行は正常であることを確認し、真の遮断点はプラットフォームの保存初期化が DB クエリタイムアウトで永久に未初期化のままだったことでした。
  • 対処 プラットフォームサーバーを再起動します。最終的な復旧は複数の原因を同時に解消したものでした — ブローカー認証ファイル欠落 + タグ description null + プラットフォーム保存バッファ停止。
  • 確認 蓄積成功は SSTable 生成ではなく対象タグの実在で判定します。生成だけを見て合格と誤判定した履歴があります。

watchdog 自動復旧構成​

  • 症状 上り途絶を人が発見しないと復旧できませんでした。
  • 対処 watchdog 3種をそれぞれ独立したサービスとして配備します — 回線(ログのみ)・設備網(ログのみ)・プラットフォームセッション(Web アプリ再起動)。一つが死んでも残りが生きている必要があるため一つに統合しません。
  • 判定 30秒間隔で4回連続(約2分)特徴確定 → 再起動 → 15分間再発動禁止。
  • 結果 6台配備で誤検知0件。実戦復旧は瞬断05:27 → 発動05:39 → 復旧05:40でした。

watchdog を導入したのに自動復旧しない​

  • 症状 11日間中断されたのに watchdog が何の動作もしない。
  • 原因 **観察専用(DRY_RUN=1)**状態でした。would restart が1,013回記録されただけでした。判定自体は正確で、失敗箇所はこれ一つでした。
  • 対処 観察配備 → 1台で実際の再起動検証 → 正常状態で実行モードに切り替えます。切断状態で切り替えると即座に再起動が発動します。

手動再起動コマンドが自分のシェルを殺す​

  • 症状 再起動コマンド実行後シェルが即死し、Web アプリが3分34秒間ダウン。
  • 原因 pkill -9 -ef tomcat のコマンドラインに「tomcat」が含まれていて自分自身にマッチしました。後に繋いだ startup が実行されませんでした。
  • 対処 kill と startup を別々の実行に分離します。状態確認はpgrep -f 'catalina[.]startup' のように大括弧で自己マッチを回避します。
  • 注意 restart.sh は末尾にログ tail があるため自動化から呼び出すと止まります。

PLC は正常なのに watchdog がサービス DOWN と判定する​

  • 症状 セッションは生きているのに誤検知1,422件。
  • 原因 ① 判定パターンがIPv6-mapped 表記([::ffff:<PLC_IP>]:<PLC포트>)を見落としていました。② フォールバックに使ったnc が単一セッション機器で拒否されました。
  • 対処 ① パターンを大括弧の有無両方を受け付けるよう修正します。② 判定順序を**ss ESTAB パッシブ優先、無い時のみnc**に変更します。

watchdog を再起動したら収集が2分中断​

  • 症状 watchdog 設定を変更すると Web アプリも一緒に終了する。
  • 原因 watchdog が起動した Web アプリはwatchdog サービスの cgroup に組み込まれ一緒に死にます。
  • 対処 90秒後の再検知・再起動で自己修復しますが2分間の中断が生じます。watchdog 設定変更は操業に影響のない時間帯に行います。

診断チャネル401が繰り返し記録される​

  • 症状 診断ポートが慢性的に SYN-SENT、ログに診断認証401が2〜3秒ごとに記録される。
  • 原因 プラットフォーム側の事案であり、401 は診断送信機がキーを乗せない世代差のため正常動作の組み合わせでも同様に発生します。
  • 対処 エッジ再起動では解決しないためwatchdog トリガーから除外します。連携の正常可否は60秒以内に実際のタグデータが入ってくるかで判定します。

4. PLC 収集安定性​

通信が少し揺らぐたびに収集が停止・再起動を繰り返す​

  • 症状 一時的な通信変動で収集が止まり、また繋がることを繰り返す。

  • 原因 ping 1回失敗で即座に収集機を止めていました。

  • 対処 猶予を停止と復旧の側に置きました。NOT_COLLECT の判定自体には猶予がありません。

    項目値
    ping 周期 · ICMP タイムアウト5秒 · 800ms
    ping 連続何回失敗で収集機を止めるか(成功すればリセット)3回
    直近の読み取りが成功して新鮮なら ping を省略する窓15秒 または収集周期 ×3 の長い方
    NOT_COLLECT に落ちる条件猶予なし — 1周期にエラーが1件でもあるか、値を1つも受け取れなければその周期ですぐに
    NOT_COLLECT がどれだけ続けば復旧(再接続)を要求するか60秒超
    設定では変更できません

    ping 3回 · 復旧60秒をはじめ、上記の値はすべてコードに埋め込まれた定数です。app.properties に該当キーはありません — 変更するには製品の変更が必要です。以前の資料に設定キーのように 書かれているものがありますが事実ではありません。

    同時にタグ別の再試行をなくしました。 接続が切れると全タグが同時に失敗するため、再試行はスキャンを遅延させるだけです。代わりにタグ別の読み取りタイムアウトを設け、1タグの遅延が全体スキャンを縛らないようにしました。

    接続失敗には接続ごとの再接続バックオフがかかります(2026-10-01)。1秒から2倍ずつ、最大60秒まで 待ってから再接続します。接続に成功するか IP・ポートを変えると、待たずにすぐ再試行します。

  • 結果 一時的な揺らぎは画面に NOT_COLLECT として一時的に表示されることがあります。 それでも収集機を 止めたり再接続を起こしたりはしません — ping が3回連続で失敗するまでは止まらず、復旧は NOT_COLLECT が60秒を超えて続くときにだけ要求します。

監視層の ICMP 誤検知で正常な収集が停止する​

  • 症状 収集はできているのに監視が収集機を止める。
  • 原因 監視層が ping 結果だけで判断していました。
  • 対処 監視基準を**「トラフィックこそが生存の証拠」**に変更します。直近の read が成功していて新鮮であればプローブを省略します。

ソケットリークで PLC が50分間全面拒否​

  • 症状 収集・プローブ・復旧の全ての接続が拒否される。
  • 原因 ドライバを破棄する際にclose なしで捨ててソケットがリークし、単一スロット機器のためそのソケットがスロットを永久占有しました。connected=false は論理フラグに過ぎず TCP ソケットとは別物です。
  • 対処 ドライバを除去・交換するコードにclose を必ず伴わせます。

プローブタイムアウトのせいで復旧が永遠に開かない​

  • 症状 スロットが空いているのに復旧しない。
  • 原因 機器の accept 遅延が約2.6秒なのにプローブタイムアウトが1秒のため永久失敗と判定していました。
  • 対処 タイムアウトを4秒に上げます。新しい機器を接続する際は接続所要時間をログで実測し余裕を検証します。
一度の検証通過を信じないでください

すぐ上の3つの事例は同じ症状に原因が三重でした。一つを直すたびに「解決した」と 判断しましたが、次の原因が残っていました。

事故はほとんど起動後1分以内に現れます。最初の3分間を集中して観察し、通過判定は 起動判定区間 + 15分無停止 + ログ0件を全て満たした時だけ下します。

通信不安定の原因が回線かどうか確認できない​

  • 症状 断続的な収集失敗の原因区間を特定できない。
  • 観測 実事例で**接続遅延が平均の6倍(6,125ms)**まで跳ね上がった後、数日にわたってリンクが切れ、無対処で自動復旧し収集が再開されました。遅延急増が前兆です。
  • 対処 常時品質監視を設けます。1秒 ping を10分単位で要約(損失率・RTT 最小・平均・最大)し、損失率5%以上であればインターフェースエラーカウンタとルーティングをスナップショットで同時記録します。判定は正常/注意5%/危険10%で、ログは15日保存します。

パケットロス状況を再現できなかった​

  • 症状 現場症状を社内で再現できず検証が止まる。

  • 対処 tc/netemで特定の PLC IP 通信にのみ損失をかけます。SSH や他の通信には影響がありません。

    tc qdisc del dev <NIC> root 2>/dev/null            # 항상 먼저 제거
    tc qdisc add dev <NIC> root handle 1: htb default 30
    tc class add dev <NIC> parent 1: classid 1:1 htb rate 100mbit
    tc class add dev <NIC> parent 1:1 classid 1:10 htb rate 100mbit
    tc qdisc add dev <NIC> parent 1:10 handle 10: netem loss 5%
    tc filter add dev <NIC> protocol ip parent 1:0 prio 1 u32 match ip dst <PLC_IP> flowid 1:10
    tc qdisc del dev <NIC> root                        # 종료

watchdog ログの読み方​

状態が変化した時だけイベントブロックが残ります。grep "EVENT" で事件だけを見ます。

系統信号意味
LTECABLE_DISCONNECTED物理リンク
LTEROUTER_DOWNルーター ping 失敗
LTELTE_NO_RETURN_TRAFFIC送信はあるが受信0 — 上り断絶
LTELTE_SIGNAL_LOST外部 ping 失敗
PLCLINK_DOWN・ARP_L2_ISSUEリンク・L2
PLCPHYSICAL_LAYER_ISSUECRC 増加 — ケーブル・ポート物理
PLCPLC_NO_RESPONSE・PLC_SERVICE_DOWN無応答・ポート閉鎖

⚠ 一部の NIC はrx_crc_errors をサポートしません。CRC:+0 はフォールバック値なので物理判定には使わないでください。

5. 値が出ない、または異常​

HMI 画面の値とエッジ収集値が異なる​

  • 原因 HMI の値はすでにロジックが適用された値の可能性があります。
  • 対処 3段階で絞り込みます — PLC メモリ原本 → HMI パネル(ロジック適用) → エッジ(データ型・収集周期・計算式)。まず PLC 原本と比較し、次にエッジの型・周期・計算式を確認して最終比較します。

カウンタに間欠的に異常な中間値が混ざる​

  • 原因 PLC スキャン周期中にカウンタ更新タイミングと読み取り時点が重なると上位・下位ワードの整合性が崩れた中間値が読まれます。障害ではなくタイミング特性です。

タグアドレスを入れたのにずっと空値​

  • 原因 JSON 系アドレスでPATH モード表記($.)を欠かして KEY モードに落ちていました。KEY モードはパスを辿らず最上位キー名そのままで検索します。該当するのはKafka・MQTT・WebSocketで、HTTP ではありません。

  • 対処 3点を確認します。

    • 配列インデックスはドットと数字(.0.)で、大括弧表記はサポートされません。
    • フィールド名は大文字小文字まで正確である必要があります(agvid 失敗 / agvId 成功)。
    • ワイルドカードと配列全体展開はサポートされません。
    TOPIC:$.body.list.0.battery     ✅
    TOPIC:body.list[0].battery      ❌

特定のタグだけずっと空値​

  • 原因 送信側ペイロードのフィールド名が誤記でした(status → stutaus)。正しいスペルで登録するとエラーなく空値だけが出ます。
  • 対処 登録前に実際のペイロードのフィールド名原文を目視確認します。
  • 併せて知っておくこと 空文字列はそもそも蓄積されません(アラームのない時間帯にデータの空白が生じます)。JSON null は文字列"null" として蓄積されるため、数値型で登録するとパースに失敗します。

発行件数より収集件数がはるかに少ない​

  • 原因 設計上正常です。 ドライバがメッセージを最後の値で上書きし、読み取りはキュー消費ではなく最後の値のポーリングサンプルです。ブローカー LAG が0であれば全て受信できています。
  • 対処 全収集が必要であればキューベースの再設計が必要です。契約変更事項です。

登録直後に古いデータが溢れる、または逆に入ってこない​

  • 原因 Kafka のauto-offset の方向です(デフォルトlatest)。latest はコンシューマグループ生成後に発行されたものだけが拾われ、earliest は登録瞬間に溜まっている既存メッセージを一括消費します。この2つの値以外は静かにlatest に落ちます。
  • 注意 これはKafka のみ該当します。MQTT には offset の概念がありません — 似た位置はclean-sessionです。
  • 対処 検証はリアルタイム発行で行います。

データ抽出が0件なのにエラーログもない​

  • 原因 jar 衝突 — 再パッケージされた JSON ライブラリが標準ライブラリと衝突し、必要なコンストラクタがありませんでした。
  • 対処 標準 jar に差し替え、衝突 jar をバックアップ移動した上でキャッシュを整理し再起動します。
  • 確認 正常は静かな成功です。ポーリングスレッドが生きていて LAG が0で、VALUE_NULL ログが止まれば正常です。成功ログは出ません。

型例外が発生する​

  • 症状 NumberFormatException または Invalid tag data type。
  • 原因 登録時に型を一律 Integer で入れていました。
  • 対処 値の性質に合わせて分け直します — Double は電流・温度・電圧・重量・速度・座標、String はアラーム・状態・区域・方向・色、Integer はバッテリー・エラーコードです。エッジタグの型とプラットフォームの型が一致している必要があります。値が文字列で来ても宣言型さえ合っていれば正確にパースされます。

メタデータを変更したのに反映されない​

  • 原因 キャッシュ reload をしていませんでした。
  • 対処 3箇所すべてを再読込します — プラットフォームサーバー、OPC-UA プラグイン、エッジ。一つでも抜けると整合性が崩れます。OPC を再登録してタグ ID が再発行された場合はプラットフォームのタグ残滓を削除し、OPC を一度停止してから起動して再同期します。

REST で登録したらドライバがブローカーへの接続すらしない​

  • 症状 「PLC 接続 timeout」のように見えるが TCP は正常で、コンシューマグループすら作られない。
  • 原因 OPC 生成リクエスト本文に必須フィールドが欠落して内部で例外が発生し、アドレスマップスキャンが失敗しました。画面で登録すると画面が埋めてくれるためREST 経路でのみ起こります。
  • 対処 必須フィールド8つをすべて埋めます — opc_id・opc_name・opc_type・site_id・opc_agent_ip・opc_agent_port・timecycle・async。アドレス表記と offset の方向も合わせて確認します。
  • 変わった点 以前はPUT が未指定フィールドを空にしてしまうため「削除後再生成」が安全でした。2026-07-20に部分マージで修正されました — 今は送られたフィールドのみが変更されます。ただしそのためフィールドをnull で消すことはできません。

ping は通るのに収集が0​

  • 原因 ping は通り ARP も正常なのに TCP ポートだけが閉じていました。 読み取りエラーカウンタが480万なのに成功は0でした。
  • 対処 PLC 側の通信ポート・モジュールの対応対象であり watchdog では解決しません。設備担当に引き継ぎます。

最新値を照会したのに古いデータが出る​

  • 原因 SELECT * ... LIMIT 5 はパーティション順序であるため古いデータが先に出ます。リアルタイム蓄積自体は正常でした。
  • 対処 WHERE tag_id=... ORDER BY timestamp DESC で確認します。

6. リソース枯渇・ログ​

30日ごとにあらゆるエラーが同時に発生​

  • 症状 30日稼働後、全方位エラー爆発。

  • 原因 監視タイマーが10秒ごとに docker ping を試みますが、docker が無いと失敗経路でファイルディスクリプタが2個回収されません。 例外をログに残さないため無症状のまま蓄積します。計算が一致します — 30.3日を10秒で割ると261,700回、2倍すると523,400で実測は523,690でした。

  • 対処 正常対照機器と同一バージョンの docker を固定インストールします。再起動だけすると30日後に再発します。

  • 確認

    P=$(pgrep -f catalina.startup.Bootstrap | head -1)
    ls /proc/$P/fd | wc -l      # 정상 ~600, 누수 시 50만+
    wc -l < /proc/net/unix      # 정상 ~200, 누수 시 50만+
    ls /var/run/docker.sock     # 없으면 누수 진행 확정
二次症状を個別のバグと誤診しないでください

/proc/stat 失敗、Mount point not found、JMX NPE、「開いているファイルが多すぎます」、キュー WAL 例外 (収集データ欠落区間)、ログの急増は全てファイルディスクリプタ枯渇から派生したものです。 枯渇以前のログには ERROR が0件でした。

スレッド・FD が増え続け OOM が発生​

  • 原因 死んだ対象への無限再接続。 対象がping は通るがプロトコルポートは死んでいる状態で OPC 数十種が1秒周期で再接続し、試行のたびにクライアントを作成していました。実測秒あたり2.25個純増で、常駐スレッドの76%がそれでした。別の機器ではドライバスレッドが40,900個まで増えて OOM が発生し、収集が3日間停止したのに終了ログすらなく気づけませんでした。
  • 対処 使わない OPC は必ず停止します。PLC がダウンすると同じリークが再現するため長期稼働機器で特に注意します。

同じログが数万件積み上がる​

  • 原因 ポーリング周期がハードコーディングされていて無効化する設定がありません。
  • 対処 クラスにパッチを当てず、ロギング設定に該当パッケージの WARN ロガーを追加して抑制します。

7. 配備・初期化​

顧客設備に設置の痕跡を残してはいけなかった​

  • 対処 ファイルをアップロードする代わりに標準入力でスクリプトを投入します。

    ssh <호스트> 'bash -s' < install.sh

    サーバーに設置本体ファイルが一切生成されません。

  • 確認 一時ディレクトリに残滓がなく、バックアップファイルも生成されていないこと、24時間以内の新規ファイルが意図した成果物のみであることを確認します。バックアップ原本はローカルレポートに保存します。

ワンライン設置コマンドが404​

  • 原因 配備経路が改編され、ドメインの最上位が異なっていました。
  • 同時に引っかかったこと
    • シンボリックリンクは404になります — ポインタはハードリンクで張ります。
    • curl | bash で実行するとスクリプト内のread が EOF に遭遇し全体が中断します。端末を接続して解決します。
    • 一段階の失敗がその後のファイアウォール・チューニング・SSL・サービス登録を全てスキップさせてしまうため、該当ステップを非必須に変更しました。

ボックスを OS だけ残して初期化​

  • 対処手順 コンテナ削除をエンジン削除より先に行います。再セットアップ用ソースがあるかを0番目の安全装置として置き、無ければ中断します。
ファイアウォールには絶対に触れないでください

リモート接続中にファイアウォールをリセットするとSSH が切れてコンソールなしでは復旧できません。 再セットアップスクリプトは必要なポートを再度開くだけで閉じません。

  • 意図的に触れないもの ホスト名・ロケール・タイムゾーン・付随パッケージです。再セットアップが再設定します。

server.host を変更したのにデータの方向が変わらない​

  • 原因 その機器はpull 方式でした。プラットフォームがエッジのタグ値 API を直接読みに行きます。エッジの push 先を変えても方向は変わりません。
  • 対処 別のプラットフォームで受けるにはそちら側にエッジアドレスとキーで pull 設定をします。

エッジ・プラットフォームの世代が異なり連携不可​

  • 症状 API server is not responding が無限に繰り返される。ポートは全て開いているためネットワークは無罪。
  • 原因 新規プラットフォームが新しい API のみを開くのに、旧式のエッジが古い経路をハードコーディングで呼び出していました。ハンドシェイクが先行しなければ発行が始まりません。
  • 対処 エッジをプラットフォームと同じリリースにアップグレードします。設定では対応できません — ハンドシェイクがコンパイルされています。
  • トークンの罠 保存と配備は別です(画面で「配備」を押す必要があります)。許可 IP の指定が必要で、公開 ping の200は認証の証拠ではありません。