AlmaLinux 9 総合ガイド 第１０章

2025.01.25

第10章: システム監視とパフォーマンスチューニング

10.1 この章で解説する主要な技術・概念

サーバー運用において、システム監視とパフォーマンスチューニングは、障害の早期発見やリソース不足の回避、そして安定稼働と高いサービス品質を維持するために不可欠です。本章では、AlmaLinux 9サーバーで役立つ監視ツールやモニタリング手法、ボトルネック分析の方法とチューニングの具体例を深掘りします。

  1. システム監視の基本的な考え方
  2. プロセス・リソース監視ツール (top, htop, vmstat, iostat, free など)
  3. ログ監視と集中管理 (journalctl, /var/log, rsyslog, ELK Stack など)
  4. メトリクス収集ツール (Prometheus, Grafana) とアラート
  5. パフォーマンスボトルネックの分析手法 (CPU, メモリ, ディスクI/O, ネットワーク)
  6. カーネルパラメータ (sysctl) とチューニング事例
  7. エンタープライズ監視ソリューション (Zabbix, Nagios, etc.) 概要

10.2 システム監視の基本的な考え方

10.2.1 なぜ監視が重要か

  1. 障害予兆の早期発見: リソース使用率が高騰している、ディスクI/Oが頻繁に発生しているなどの兆候を捉え、事前に対策を打てる。
  2. 迅速なトラブルシューティング: 問題発生時に、どの部分が原因かを素早く切り分けるためには、通常時のメトリクスを把握しておくことが大切。
  3. サービスレベルの維持: SLA (Service Level Agreement) を守るために、稼働状況や性能の可視化が不可欠。

10.2.2 監視対象の分類

  • ホストレベル: CPU、メモリ、ディスク、ネットワークI/Fなど
  • サービスレベル: Webサーバー(HTTP応答), DBサーバー(クエリ遅延), メールサーバー(SMTP応答)
  • アプリケーションレベル: JavaやPHPのスレッド数、GC時間、カスタムメトリクス

ポイント: 監視結果はログやグラフとして可視化し、アラート（メール、Slack、PagerDutyなど）を設定すると運用効率が高まる。

10.3 プロセス・リソース監視ツール

10.3.1 top / htop の活用

  • top: リアルタイムのプロセス一覧を表示し、CPU/メモリ使用率を把握
  • Shift + p でCPU使用率ソート、Shift + m でメモリ使用率ソート
  • htop: 拡張版top。マウス操作やカラー表示に対応し、並列コアごとのCPU負荷が一目で分かる
sudo dnf install htop
htop

コマンド操作例: F5(ツリー表示), F6(並べ替え), F3(検索)

10.3.2 vmstat と iostat

vmstat

vmstat 2
  • 2秒ごとにCPU、メモリ、I/O待ち行列、スワップ使用状況などを表示
  • r（ランキュー）の値がCPUコア数を大きく超えていると、CPUが飽和している可能性
  • b（ブロックドプロセス）が高いと、I/Oウェイトが発生中

iostat

sudo dnf install sysstat
iostat -xz 2
  • -x で詳細表示、-z で0行を非表示
  • await (I/Oリクエストの平均待ち時間) が長い場合はディスクI/Oがボトルネック
  • svctm (サービス時間) や util (%) も要注目

10.3.3 free コマンドとメモリ使用状況

free -h
  • total, used, free, shared, buff/cache, available を人間可読形式で表示
  • available はアプリケーションが使用できるメモリの目安。free 単体の値よりも重要。

10.4 ログ監視と集中管理

10.4.1 journalctl と /var/log 配下

  • journalctl: systemdのジャーナルログを検索・表示
  • journalctl -b : 今回のブート以降のみ
  • journalctl -u httpd.service : 特定ユニットだけ
  • journalctl --since "2025-01-01 00:00:00" --until "2025-01-01 12:00:00" : 時間範囲指定
  • /var/log/messages や /var/log/secure: rsyslogが出力する従来型ログ。重要なシステム通知や認証関連などはここに集約される。

10.4.2 ELK Stack (Elasticsearch, Logstash, Kibana)

  • Logstash: 各サーバーやアプリケーションからログを収集し、Elasticsearchへ送信
  • Elasticsearch: 分散ドキュメントストアとしてログを保存・検索
  • Kibana: Elasticsearchに蓄積されたログをGUIで可視化し、ダッシュボードや検索が可能

運用上のポイント

  • メモリ消費が多いため、リソースを多めに確保
  • フィールド解析を行い、ログイン試行失敗の傾向や特定エラーの増加をダッシュボードで監視

10.4.3 rsyslog のリモート転送

  • /etc/rsyslog.conf で *.* @@logserver.example.com:514 のように設定すれば、Syslogを集中収集サーバーに送信可能
  • 大規模環境では1台のSyslogサーバーに集めて解析・可視化する

10.5 メトリクス収集ツール (Prometheus, Grafana)

10.5.1 Prometheus

  • Prometheus: 時系列データベース（TSDB）を内蔵した監視ツール
  • Pullモデル: 各ホストがエクスポーターを起動し、Prometheusがスクレイプによりメトリクスを取得
  • PromQL: カスタムクエリ言語でメトリクスを分析

インストール例

sudo dnf install prometheus
sudo systemctl enable prometheus
sudo systemctl start prometheus
  • /etc/prometheus/prometheus.yml でターゲット(エクスポーター)やスクレイプ間隔を定義

10.5.2 Grafana

  • Grafana: Prometheusや他のデータソースから取得したメトリクスをダッシュボード化
  • 組み込みの豊富な可視化パネルやコミュニティプラグイン
  • アラートルールを設定し、メール/Slack通知も可能

セットアップ例

sudo dnf install grafana
sudo systemctl enable grafana-server
sudo systemctl start grafana-server
  • Webブラウザで http://<server>:3000 にアクセス
  • DataSourceとしてPrometheusを設定し、ダッシュボードを作成

10.6 パフォーマンスボトルネックの分析

10.6.1 CPUのボトルネック

  • load average がコア数を継続的に超えている場合、CPUが不足気味
  • シングルスレッドがネックの場合はCPUクロックの高いサーバーが有利
  • マルチスレッドワークロードならコア数（vCPU）を増やす、または水平スケール(コンテナなど)

10.6.2 メモリ不足

  • スワップ量(vmstat, free で確認)が常に高い場合、メモリ不足
  • 余分なサービスを停止、あるいはメモリを増設
  • swappinessパラメータ (/proc/sys/vm/swappiness) を下げるとスワップ使用を控えめにする

10.6.3 ディスクI/Oとストレージ

  • iostatのawaitやutil が高い場合ディスク性能が追いついていない
  • SSDへの換装やRAID0/RAID10による分散、LVMストライピングなどでI/O改善
  • キャッシュ機構（ミドルウェアレベル）やデータ分散設計（シャーディングなど）も検討

10.6.4 ネットワークボトルネック

  • iperfで帯域幅を測定し、物理回線やルーティングに問題がないか確認
  • ファイアウォールやVPNの暗号化オーバーヘッドが原因の場合もあり
  • NICのボンディングやルート最適化でスループット向上

10.7 カーネルパラメータ (sysctl) とチューニング事例

10.7.1 sysctlコマンド概要

sysctl -a             # すべてのパラメータを表示
sysctl net.core.somaxconn=1024  # 一時的に設定
  • 永続化は /etc/sysctl.d/*.conf に記述し、sysctl -p で読み込み

10.7.2 主なカーネルパラメータ例

  1. net.core.somaxconn: SYNキューの最大長。高負荷Webサーバーで接続待ちが多い場合に上げる。
  2. net.ipv4.ip_forward: IPフォワード有効化（ルータやNAT用途）。
  3. vm.swappiness: スワップへの積極度。デフォルトは60程度。低めに調整すると物理メモリを優先して使う。
  4. fs.file-max: システム全体で同時に開けるファイル記述子数の上限。大量接続を扱うサーバーで上げるケース。
# /etc/sysctl.d/99-custom.conf の例
net.core.somaxconn = 1024
vm.swappiness = 10
fs.file-max = 2097152

注意: カーネルパラメータは間違って設定するとパフォーマンス劣化やサービス不可に陥るリスクもある。検証環境でテストしてから本番に反映するのが理想。

10.8 エンタープライズ監視ソリューション

10.8.1 Zabbix

  • オールインワンの監視ツール。エージェントを各ホストに導入し、Zabbixサーバーにデータを送信
  • 豊富なテンプレート（Linux, MySQL, Apacheなど）を使うとすぐに監視開始
  • WebUIでトリガー設定・グラフ表示を管理

10.8.2 Nagios / Icinga

  • Nagios: 歴史が長く、プラグインが豊富
  • Icinga: Nagiosのフォークであり、UIや拡張機能が充実
  • 設定ファイルやプラグインを自作して柔軟に監視をカスタマイズ可能

10.8.3 SaaS型監視

  • Datadog, New Relic, Dynatrace, etc.
  • インストールは軽量エージェントのみで済む
  • クラウドダッシュボードと高度な解析機能が提供されるが、利用コストがかかる

10.9 学習のまとめ

  1. システム監視の重要性: リソース利用状況やサービス稼働を可視化し、障害や性能問題を予防・迅速解決する基盤となる。
  2. プロセス・リソース監視: top, htop, vmstat, iostat, free, ss などを使い、CPU/メモリ/I/O/ネットワーク状況をリアルタイム把握。
  3. ログ監視: journalctl や /var/log を日常的にチェックし、必要に応じてELK Stackやrsyslogリモート転送で集中管理。
  4. メトリクス可視化: PrometheusとGrafanaを組み合わせ、長期的なトレンド分析やアラートを実装し、DevOps的運用を強化。
  5. パフォーマンスボトルネック分析: CPU・メモリ・ディスク・ネットワーク各要素を切り分け、適切なスケールアップ/アウトやチューニングを検討。
  6. カーネルパラメータ (sysctl): net.core.somaxconn、vm.swappiness、fs.file-maxなどを調整し、高負荷環境への最適化を図る。
  7. エンタープライズ監視: Zabbix、Nagios、SaaS型ツールなどで包括的に監視を行い、大規模運用に対応。

次章へのつながり

次の章（第11章）では、システム障害や災害に備えるためのバックアップとリカバリ戦略をより深く取り上げます。rsyncやtarを使った手動バックアップからBacula/Amandaなどの専用ソフトウェア、クラウドバックアップの活用、ディザスタリカバリ計画などを学習し、サーバー運用の信頼性をさらに高めていきましょう。