Linuxの危機対応ツール

 (brendangregg.com)
2 ポイント 投稿者 GN⁺ 2024-03-25 | 1件のコメント | WhatsAppで共有
  • パフォーマンス障害が起きてから診断ツールの導入を始めると、復旧よりも準備作業に時間を取られるため、Linuxサーバーのイメージには危機対応ツールをあらかじめ入れておくべき
  • 推奨リストは procps、util-linux、sysstat、iproute2、tcpdump、perf、bcc/bpftrace、trace-cmd、ethtool などで、CPU・ディスク・ネットワーク・カーネルトレースをすぐ確認するための最小パッケージ
  • bcc と bpftrace には重複するツールが多いが、bcc は CLI オプションが豊富で、bpftrace は現場で編集しやすく、実行時には同じBPFバイトコードを出力する
  • 障害中のインストールは、遅い SSH、壊れた apt 設定、リポジトリ遮断、ファイアウォール、不変ファイルシステム、権限エラーといった要因により、数十分の損失につながる可能性がある
  • コストは主にディスク容量とイメージ配布時間だが、推奨パッケージの大半は小さく、エンタープライズ Linux ディストリビューションに標準搭載すれば、パフォーマンス障害への対応をより早く始められる

障害前にそろえておくべき最小ツール

  • パフォーマンス障害が発生すると、原因診断に必要なツールをインストールする時間そのものが損失になるため、Linuxサーバーには危機対応ツールを標準で導入しておくほうが安全
  • リストは Systems Performance 2nd Edition の「Linux Crisis Tools」表をもとにしている
  • Ubuntu パッケージ基準の推奨ツールは以下のとおり
    • procps: ps, vmstat, uptime, top
      • 基本統計の確認
    • util-linux: dmesg, lsblk, lscpu
      • システムログとデバイス情報の確認
    • sysstat: iostat, mpstat, pidstat, sar
      • デバイスおよびシステム統計の確認
    • iproute2: ip, ss, nstat, tc
      • 推奨されるネットワークツール
    • numactl: numastat
      • NUMA 統計の確認
    • tcpdump: tcpdump
      • ネットワークスニッフィング
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • プロファイラと PMU 統計の確認
    • bpfcc-tools または bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile など
      • あらかじめ用意されたeBPF ツール
    • bpftrace: bpftrace, 標準版の opensnoop, execsnoop, runqlat, biosnoop など
      • eBPF スクリプティング
    • trace-cmd: trace-cmd
      • Ftrace CLI
    • nicstat: nicstat
      • ネットワークデバイス統計
    • ethtool: ethtool
      • ネットワークデバイス情報
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • CPU 詳細情報
    • msr-tools: rdmsr, wrmsr
      • CPU の詳細調査

bcc と bpftrace をどう使い分けるか

  • bcc と bpftrace には重複するツールが多いが、使いやすい場面は異なる
  • bcc ツールは CLI オプションなどの機能が多く、完成されたツールとして使いやすい
  • bpftrace ツールは現場でその場で編集できるため、状況に応じた確認がしやすい
  • どちらか一方がより高速という意味ではない
    • 両ツールは同じ BPF バイトコードを出力する
    • 実行中の速度は同等に速い
  • bcc は Python ベースのツールを libbpf C に移行する方向で進化している
    • CO-RE と BTF を使用する
    • まだパッケージは再構成されていない
    • 将来的には bpfcc-tools はツールのバイナリだけを含む、より小さな libbpf-tools パッケージに置き換えられるべき

サーバー種別ごとに追加で必要なツール

  • 上記の一覧はあくまで最小構成
  • アクセラレータを搭載したサーバーなら、その機器を分析するツールも含めるべき
    • Intel GPU サーバー: intel-gpu-tools
    • NVIDIA サーバー: nvidia-smi
  • gdb のようなデバッグツールも、危機時にすぐ使えるよう事前に入れておける
  • 必須の分析ツールは頻繁には変わらないため、この一覧は数年に一度程度の更新でも足りる可能性がある

標準インストールの実際のコスト

  • パッケージ追加で最初に目につく欠点はディスク使用量
  • クラウドインスタンスでは、標準サーバーイメージが数 MB 増えるだけでも、インスタンス配備時間が数秒、あるいは数分の1秒伸びる可能性がある
  • 推奨パッケージの大半は小さく、bcc も今後さらに小さくなる見込みのため、容量と時間のコストは大きくないはず
  • debuginfo は合計で約1GBに達し、標準同梱をためらわせる容量面の懸念が実際にあった

障害中にインストールが詰まる流れ

  • 障害発生後にツールを導入しようとすると、診断よりもインストール問題の解決に時間を奪われることがある
  • 例としては次のような流れ
    • 4:00pm: 会社のサイトがダウン、または極端に遅くなり利用不能になる
    • 4:01pm: 監視ダッシュボードでバックエンドサーバー群に異常が見つかり、高いディスク I/O が疑われる
    • 4:02pm: サーバーへ SSH 接続しようとするが、ログインが非常に遅い
    • 4:03pm: iostat -xz 1 を実行しようとするが iostat がなく、sysstat のインストール案内が表示される
    • 4:07pm: パッケージインストールがリポジトリ解決に失敗し、/etc/apt の設定問題が判明する
    • 4:10pm: 修正した設定で apt-get update を実行する必要があるが、これも非常に遅い
    • 4:13pm: 接続タイムアウトが発生し、リポジトリ接続かパフォーマンス問題が疑われる
    • 4:17pm: ネットワークセキュリティチームが予期しないトラフィックとして HTTP/HTTPS/FTP の outbound apt リクエストを遮断していたことが判明する
    • 4:20pm: ファイアウォールを無効化したあと apt-get update は通るが、インストールで権限エラーが発生する
    • 4:24pm: プラットフォームセキュリティチームが、実行バイナリ領域など一部ファイルシステムへの書き込みが禁止された不変システムだと説明する
    • 4:27pm: SRE チームが大規模障害を告知し、経営陣は状況更新と復旧 ETA を求めるが、実際の診断はほとんど進んでいない
    • 4:30pm: cat /proc/diskstats で粗い iostat の代替を試みるが、Linux のドキュメントを読む必要があり、ディスクが忙しいという既知の事実しか確認できない
    • 4:55pm: 書き込み可能なファイルシステムを持つ新しいサーバーイメージが立ち上がり sysstat をインストールできるようになるが、サーバー再起動でサイトが復旧しただけで、原因は修正されていない
    • 12:50am: ファイアウォールとファイルシステム保護を無効化した影響で、サイトがハッキングされるという例に続く
  • 12:50am の出来事は実体験ではないが、それ以外は実体験に基づく例
  • 以前の勤務先では、約 15 分時点で “traffic team” がクラウドリージョンのフェイルオーバーを開始することがあり、iostat のインストールが終わる頃には対象システムがすでにアイドル状態になっていることもあった

標準イメージに入れておくべき理由

  • 上記シナリオは、本番障害の最中に後からツールを導入する方式がどれほど脆弱かを示している
  • 一部の企業では、必要なツールを含めたカスタムサーバーイメージを OS チームが作成して利用している
  • それでも標準の Linux をそのまま運用しているサイトは多く、その場合は障害を経験して初めて必要性に気づくことが多い
  • エンタープライズ Linux ディストリビューションがこうした危機対応ツールを標準搭載すれば、大小さまざまな企業がパフォーマンス障害発生時にすぐ診断を始められる

関連記事

1件のコメント

 
GN⁺ 2024-03-25
Hacker Newsのコメント

  • この一覧は役に立つ。apt リポジトリの解決失敗のように、サーバー自体が壊れている状況では、クラウドがうまくはまることが多い
    修復しようとして抱え込むより、マシンを落とすかプールから外して新しいマシンを立ち上げれば、新しいマシンとアプリがきれいな状態で起動し、障害は終わる。問題のあるマシンはホットパスの外で別途調べればよい

    • 問題を「解決」したあとには、誰もそのマシンを掘り下げる時間も許可もなく、時間がたつと 最初から再ビルド 方式は実際の問題解決能力と蓄積された知識を失わせることになる
      物理世界の「部品交換しかできない人」のソフトウェア版になる
    • 「午後4時10分、新しいマシンでも同じ 性能問題 が続いている」
    • それはクラウド固有の利点というより、仮想化され交換可能なサーバー（cattle） 運用の利点に近い
    • マシンを消すと 証拠 まで消えることがある。外部にすべてのログが残っているかもしれないが、たいていは何かが欠けている

  • すべてのサーバーがコンテナ化されているわけではないが、かなりの数はコンテナであり、それ自体の難しさがある
    Dockerイメージ内のデバッグツールは、自動セキュリティスキャナで「攻撃者がシステムの動作を観察・改変するのに役立つ不要なツール」として検出されることが多い。gdb のようにもっともな懸念もあるが、そうでないものも多い
    そのため一部のツールは別ボリュームに、できれば 静的バイナリ として置くか、マウントパスをインストールプレフィックスとしてコンパイル・インストールする。デバッグが必要なら、運用チームに読み取り専用で一時マウントしてもらうよう依頼する
    また、あるデバッグツールが特定のカーネル機能の有効化を要求すると、同じホスト上のほかのコンテナにどんな影響があるのかという質問や懸念がよく出る

    • 攻撃者がファイルシステム上でファイルを実行できて、実行に足りないのがそのファイルの存在だけなら、単に自分でそのファイルを書き込めばいいのではと思う
      このポリシーに意味があるシナリオは、「組織が セキュリティスキャナを誤用している」以外にはあまり思いつかない
    • より良い方法は、デバッグツールと root ユーザー を含む2つ目のイメージを作り、本番コンテナのPID名前空間とネットワーク名前空間に接続して実行することだ
      デバッガを使うには SYS_PTRACE 権限、ユーザー0、--privileged のようなフラグが多く必要になるので、2つ目のコンテナを起動するほうがたいていはよい
      この方法なら本番コンテナを再起動せずに済み、再現の証拠を失う可能性も減る
      ただし障害時にこの手順を思い出すのは簡単ではないので、事前に試し、ランブック に手順を段階ごとに書いておくべきだ

  • 関連して、FreeBSD 5.2、つまり2004年以降、すべてのFreeBSDシステムには /rescue/* がある
    約150個の中核ツールを1つにまとめた 静的リンクバイナリ が通常の名前でハードリンクされており、サイズは約17MBだ
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • 15年間それを使う必要はなかった。ここ4〜5年は精神衛生のため、できるものを *BSD に移植してきた

  • Netflixにいたとき、Brendanと彼のチームが bpftrace、bcc、ちゃんと動く perf のような デバッグツール をあちこちに入れておいてくれた
    何度も命を救ってくれたツールだった

  • その一覧に strace がないのは驚きだった。たいてい最初に手に取るツールの1つだ
    とくにプログラムが役に立たない、または間違ったエラーメッセージを返すとき、strace は本当に有用だ

  • SRE系の職種の面接では、こうしたツールはいつも話題になる
    候補者が特定のコマンドをどれだけ暗記しているかが重要なのではなく、新しいツールを知っていれば印象的ではあるが、何が可能で、どんなツールがあり、どう使うかを見る
    ネットワークトラフィック、システムコール、実行プロファイルをキャプチャ・分析し、OSとハードウェアの状態を調べられるという感覚が重要だ

  • こうした危機的状況でツールをインストールできないなら、Dockerでさまざまなユーティリティを実行できる
    たとえばコンテナをワンライナーでビルドしたり、ホストネットワークに接続して netstat 系のツールを実行したり、/proc をマウントし、--privileged、--net host、--pid host で iostat、sar、vmstat、mpstat、pidstat のような システムツール を動かせる
    もちろん yum install のほうがよいが、Dockerが使えて必要なマッピングを許容できるなら代替になる。rootless や Podman の構成ではたぶんうまくいかないだろう

    • apt がパッケージをダウンロードしてインストールできないのに、Dockerは新しいコンテナを取得できるという状況はあるのか？
      apt のライブラリが壊れている、といった場合だろうか？
    • ネットワーク分離 の状況なら例外だ。「Ubuntu」イメージを引っ張ってくるには幸運を祈るしかない
    • そういう文脈では、busybox にこうしたツールがもっと多く入っているとよい
      サーバーにアップロードしてすぐ実行できる1MBくらいのファイルがあれば、とても助かる

  • みんな root アクセス権をもらえるのか？ 自分は何をするにも システム管理者チケット を起票しなければならない

    • 今はコンサルタントで、数か月ごとに新しい会社へ行く。常に良い関係を保つべき人たちがいる
      セキュリティ担当者、建物への入館を通してくれる気まずいジャケット姿の人たちの名前を覚え、Starbucksカードも持っておくとよい
      清掃担当にも礼儀正しく接し、名前を覚えれば、自分の席はきれいになる。たまに遅くまで残ってこうした人たちを知るのも価値がある
      経理部にも友人を作るとよい。コーヒーを飲み、昼食を取り、仕事以外の話もしながら関心を示せば、適切な人たちはレイオフが来るときや会社の資金に余裕が出たときに知らせてくれる
      IT、つまりノートPCを配ってメールを管理している人たちにも良くしておくべきだ。自分のPCからくだらないセキュリティツールをどれだけ早く外してくれるか、アップグレードの列でどれだけ前にしてくれるかが違ってくる
      いちばん重要なのは システム管理者 だ。root のためだけではなく、優れたシステム管理者はコーディングできるのに決して大声では言わないからだ。優れた管理者は、どこか暗い隅に死体があるのか、それが壁一面のクローゼットなのか共同墓地なのかを教えてくれる。彼らのプラットフォームに合わせてビルドする方法を学べば、はるかに大きな裁量が得られる。彼らに頼まれたことは引き受けるべきだ
    • 以前はIT運用を担当していて、ここでいうのはシステム・SRE・セキュリティのことだ
      この記事は、ITが提供したインフラ上でアプリを運用する人たちに向けたものだ。例にあるようなやり取りが必要なら、それは技術的問題ではなく 組織レベルの失敗 だ
      私たちには非常に明確で信頼できるコミュニケーションの線があり、人々はチャットではなく電話、最近なら Teams のような場で、開発・運用・セキュリティ・コンプライアンスと一緒に動いていた
      実際には、すべてのチームに少なくとも連絡担当がいて、通常は開発者が運用チーム提供のリソース上でアプリを動かしていた。コンプライアンスが構成を承認し、サービス信頼性は開発の責務だった。この意味で DevOps をやれば、多くの問題は消える

  • nmap、netstat、nc が見当たらない。これらのツールにも何度も救われた

  • 1つだけ追加するなら nmap だ
    ネットワーク接続の問題は、アプリによっては常に明確に現れるとは限らない

    • screen、tmux、byobu、pv、rsync、そしてもちろん vim も必要だ