第10章: システム監視とパフォーマンスチューニング
10.1 この章で解説する主要な技術・概念
AlmaLinux9 のシステム監視とパフォーマンスチューニングを体系的に理解するために、本章で扱う主要技術と概念を詳細に解説します。
10.1.1 システム監視の基本的な考え方
システム監視は、サーバーやサービスの健全性を継続的に把握し、異常兆候を早期に検知するプロセスです。主に以下の３つの要素で構成されます：
- 可用性監視：サービスやポートが稼働中か（生死判定）
- パフォーマンス監視：CPU／メモリ使用率、レスポンスタイム、スループットなど
- キャパシティプランニング：将来のリソース需要を予測し、適切に拡張計画を立てる
これらを組み合わせることで、障害の未然防止、迅速な原因特定、効率的なリソース配分が可能になります。
10.1.2 プロセス・リソース監視ツール
リアルタイムおよび履歴的にシステムリソースを可視化する主要ツール：
- top / htop：プロセス単位のCPU・メモリ使用率を動的に表示
- vmstat：プロセス状態、メモリ、I/O、システム、CPU統計を定期レポート
- iostat：ブロックデバイスごとのI/O統計と待ち行列を詳細レポート
- free：物理メモリとスワップ領域のリアルタイム残量表示
これらを組み合わせることで、どのレイヤーでリソース不足が発生しているかを迅速に特定できます。
10.1.3 ログ監視と集中管理
ログは事象の履歴を記録する重要データです。監視では以下を押さえます：
- ローカルログ：
/var/logやjournalctlで直接参照 - rsyslog：各ホストからリモートログサーバーへの転送設定
- ELK Stack：Logstash/Beats → Elasticsearch → Kibana のパイプラインで集中化・可視化
集中管理により横断的な検索やアラート設定が可能となり、障害対応速度が飛躍的に向上します。
10.1.4 メトリクス収集ツールとアラート
時系列メトリクスを収集・保管し、しきい値や異常検知に基づく通知を行う構成：
- Prometheus：プルモデルでエクスポーターからメトリクスを収集、PromQL でクエリ可能
- Grafana：各種データソースを統合し、ダッシュボードで可視化、アラート管理
- Alertmanager：Prometheus と連携し、通知ルールに基づくメールやSlack通知を実現
運用監視では、リアルタイム可視化と自動アラートがサービス品質維持の鍵となります。
10.1.5 パフォーマンスボトルネックの分析
ボトルネックの主な種類と指標：
- CPUボトルネック：load average が CPUコア数を超過、コンテキストスイッチ増加
- メモリボトルネック：スワップ使用増加、キャッシュ不足
- ディスクI/O：高い
iowait、I/O待ち行列の長大化 - ネットワーク：帯域飽和、遅延増大、パケットロス
分析手順は、ベースライン取得 → 監視データ比較 → プロファイリング → 改善策適用 → 再検証のサイクルで行います。
10.1.6 カーネルパラメータとチューニング事例
sysctlで操作可能なパラメータ例：
net.core.somaxconn：SYNキュー長の調整vm.swappiness：スワップ開始閾値の制御fs.file-max：同時オープンファイル数上限
各種数値はメトリクスと運用要件に基づき、検証環境で逐次最適値を導出します。
10.1.7 エンタープライズ監視ソリューション
大規模環境向けの包括的プラットフォーム：
- Zabbix：エージェント／サーバー構成でテンプレート管理や自動登録を実現
- Nagios／Icinga：プラグインベースで柔軟に監視項目をカスタマイズ可能
- SaaS型：Datadog／New Relic 等、エージェント導入のみでクラウド上に可視化ダッシュボードを構築
各製品はスケーラビリティ、コスト、運用負荷のバランスで選定します。
10.2 システム監視の基本的な考え方
システム監視は、サーバーやサービスの「健全性」を継続的に把握し、異常を早期に検知・対応するための基本原則です。本節では「なぜ監視が重要か」「監視対象の分類」「監視設計の原則」という３つの視点で解説します。
10.2.1 なぜ監視が重要か
監視が欠如すると、以下のリスクが生じます：
- ダウンタイムの長期化：障害発生後に気づくまでに時間を要し、サービス停止時間が増大
- 原因特定の困難化：障害発生前後の状況を把握できず、根本原因分析が困難
- 容量計画の誤算：リソースの使用傾向が見えず、過剰投資または不足投資を招く
💡 補足：可用性の維持だけでなく、パフォーマンス品質の維持にも監視は不可欠です。遅延の微増やリソース競合は、ユーザー体験の低下に直結します。
10.2.2 監視対象の分類
監視対象は大きく以下の３階層に分けられ、それぞれ異なるツールや指標を用いて可視化します。
- ホストレベル（インフラ）：CPU、メモリ、ディスクI/O、ネットワーク帯域など、物理／仮想マシン単位の資源
- サービスレベル（ミドルウェア）：Webサーバー応答時間、データベース接続数、キュー長など、プロセスやサービス単位の動作
- アプリケーションレベル（ビジネスロジック）：リクエストレイテンシ、トランザクション成功率、カスタムメトリクス（例：ECサイトの注文数）
💡 補足：例えば、CPU使用率が正常でもアプリケーションレベルで異常が発生しているケースがあります。多層的な監視設計が鍵です。
10.2.3 監視設計の原則
効果的な監視を実現するには、次の設計原則を遵守します：
- 計測可能性：すべての重要指標（KPI）を定量的に取得できる
- 観測可能性（Observability）：メトリクス・ログ・トレースを組み合わせ、内部状態を外部から把握可能にする
- しきい値とアラート：正常範囲を定義し、逸脱時に自動通知を行う
- フィードバックループ：監視結果をもとに設定を見直し、監視対象や閾値を継続的に最適化
- 冗長化とフォールトトレランス：監視システム自身に耐障害性を持たせ、一部の監視障害が全体に影響しないよう設計
10.2.4 監視の自動化とコード例
以下はシンプルなシェルスクリプトによる CPU 使用率監視例です。全行に日本語コメントを付与し、何をしているか明確化しています。
# 実行シェルを指定
#!/bin/bash # Bashスクリプトとして実行
# CPU使用率のしきい値を設定
THRESHOLD=80 # 80% を警告閾値とする
# 現在のCPU使用率を取得（ユーザ利用率+システム利用率）
USAGE=$(top -b -n1 | grep "Cpu(s)" | awk '{print $2+$4}') # topコマンドの出力から計算
# 整数部分のみ抽出（比較用）
USAGE_INT=${USAGE%.*} # 小数点以下を切り捨て
# しきい値超過を判定し、超過時に通知
if [ "$USAGE_INT" -gt "$THRESHOLD" ]; then # 閾値と現在値を比較
mail -s "【警告】CPU使用率が高いです" admin@example.com <<< \
"現在のCPU使用率は${USAGE}%です。" # 管理者へメール送信
fi # if文の終わり
10.3 プロセス・リソース監視ツール
AlmaLinux9 におけるシステム監視では、プロセス単位やリソース単位で稼働状況を可視化し、リアルタイムおよび履歴的なデータ分析を行います。本節では代表的なツールを徹底解説し、それぞれの出力フィールドの意味や応用テクニックを紹介します。
10.3.1 top / htop の活用
概要：プロセスごとの CPU・メモリ使用率をインタラクティブに表示し、動的にソート・フィルタリングできます。
利点：標準インストール済みの top、カラフル＆操作性に優れる htop の２種を使い分け。
💡 補足：
htop では F2 キーで表示フィールドのカスタマイズ、F3/F4 でプロセス名フィルタ、F9 ですみやかなプロセス終了が可能です。実行ユーザー：root または sudo ユーザー
# top をインタラクティブで起動して全プロセスのCPU・メモリ使用率を確認
sudo top # CPU使用率(us, sy)、メモリ(total, used, free)などをリアルタイム表示
# htop をインストールして視覚的にプロセスを監視
sudo dnf install -y htop # htopパッケージをインストール
# htop を起動し、ツリー表示や色分けでプロセス状況を把握
sudo htop # プロセス名やPID、CPU%, MEM%などをグラフィカルに表示
10.3.2 vmstat によるシステム統計
概要：システム全体のプロセス状態、CPU、メモリ、I/O、スワップ統計を定期的にレポートします。
主な項目：r（実行待ちプロセス数）、b（ブロック中プロセス数）、us（ユーザ空間CPU%）、sy（カーネル空間CPU%）、wa（I/O待ち%）など。
💡 補足：1行目は起動後からの平均値を示すため、2行目以降を監視対象にすると実態に即したデータを取得できます。
実行ユーザー：root または sudo ユーザー
# sysstat パッケージをインストールし、vmstat を利用可能に
sudo dnf install -y sysstat # vmstat や iostat を提供する sysstat を導入
# 2秒間隔で5回、システム統計を出力
vmstat 2 5 # r, b, us, sy, id, wa, st, free, buff, cache などを5セット表示
10.3.3 iostat でディスクI/Oを詳細分析
概要：ブロックデバイスごとのI/O統計を取得し、読み書きのレートや待ち行列長を可視化します。
主な項目：r/s（秒間読み込み数）、w/s（秒間書き込み数）、await（平均I/O待ち時間）、%util（デバイス利用率）など。
実行ユーザー：root または sudo ユーザー
# iostat を含む sysstat をインストール
sudo dnf install -y sysstat # iostat を利用可能にする
# 拡張統計とゼロ行省略モードで2秒間隔に5回出力
iostat -xz 2 5 # -x:詳細統計, -z:ゼロ値行を非表示, 2秒×5回出力
10.3.4 free コマンドでメモリ状況を把握
概要：物理メモリとスワップの使用状況を簡潔に表示し、buff/cache と available の違いを理解できます。
💡 補足：
available は実際に新規プロセスを起動可能なメモリ量を示し、free より信頼性が高い指標です。実行ユーザー：任意
# メモリとスワップの使用状況を人間可読形式で表示
free -h # total, used, free, shared, buff/cache, available を確認
10.4 ログ監視と集中管理
システム障害の解析やセキュリティ監査のため、ログは重要な証跡です。本節では、AlmaLinux9 におけるログ収集から集中管理まで、詳細な手法と設定を解説します。
10.4.1 journalctl と /var/log 配下
概要：systemd-journald によるジャーナルログ管理と、従来の /var/log ディレクトリに保存されるテキストログの両面を解説します。
実行ユーザー：root
目的：ログの保管方式を理解し、解析や転送の基盤を整備する
期待結果：永続化されたジャーナルと /var/log のテキストログを効率的に活用可能
# 永続的なジャーナル保存ディレクトリを作成
sudo mkdir -p /var/log/journal # persistentStorage用ディレクトリを作成
# journald設定を編集して永続化を有効化
sudo sed -i 's/#Storage=.*/Storage=persistent/' /etc/systemd/journald.conf # Storage設定をpersistentに変更
# 設定を反映
sudo systemctl restart systemd-journald # journaldサービスを再起動
ジャーナルログは以下のコマンドで操作できます：
# ブート単位でログを表示
sudo journalctl -b # 現在の起動以降のログを出力
# 特定サービスのログをフィルタ
sudo journalctl -u sshd.service # sshdサービスのログ
# 優先度警告以上のログを表示
sudo journalctl -p warning # priority warning以上を抽出
# リアルタイム追跡（tail -f 相当）
sudo journalctl -f # 新規ログを継続表示
# JSON形式でログを出力
sudo journalctl -o json-pretty # JSONで整形出力
❗ 注意：
/var/log/journal ディスク使用量は増加するため、logrotateやディスク容量監視を併用してください。10.4.2 ELK Stack (Elasticsearch, Logstash, Kibana)
概要：ELK Stack でログの収集・検索・可視化を一元化します。Elastic社が提供する Elasticsearch、Logstash、Kibana を導入し、大規模ログを効率的に管理します。
前提：Java 11 以上がインストール済み
期待結果：ログを Elasticsearch に蓄積し、Kibana でダッシュボード表示可能
# Elastic リポジトリを追加
sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch # GPGキーをインポート
sudo tee /etc/yum.repos.d/elastic.repo << 'EOF' # リポジトリ定義を作成
[elastic-7.x] # Elastic 7.x リポジトリセクション
name=Elastic repository for 7.x packages # リポジトリ名
baseurl=https://artifacts.elastic.co/packages/7.x/yum # パッケージURL
gpgcheck=1 # GPGチェックを有効化
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch # キーURL
enabled=1 # 有効化
autorefresh=1 # 自動更新
type=rpm-md # メタデータ形式
EOF # リポジトリ定義終了
# Elasticsearchをインストール＆起動
sudo dnf install -y elasticsearch # Elasticsearchパッケージをインストール
sudo systemctl enable elasticsearch.service # 自動起動を有効化
sudo systemctl start elasticsearch.service # Elasticsearchを起動
# Logstashをインストール＆起動
sudo dnf install -y logstash # Logstashパッケージをインストール
sudo systemctl enable logstash.service # 自動起動を有効化
sudo systemctl start logstash.service # Logstashを起動
# Kibanaをインストール＆起動
sudo dnf install -y kibana # Kibanaパッケージをインストール
sudo systemctl enable kibana.service # 自動起動を有効化
sudo systemctl start kibana.service # Kibanaを起動
Logstash設定例 (/etc/logstash/conf.d/10-syslog.conf)：
# syslog入力設定
input { # 入力プラグイン開始
tcp { # TCP受信を設定
port => 10514 # ポート10514でリッスン
type => "syslog" # エントリタイプをsyslogに設定
} # TCP設定終了
udp { # UDP受信を設定
port => 10514 # ポート10514でリッスン
type => "syslog" # エントリタイプをsyslogに設定
} # UDP設定終了
} # 入力プラグイン終了
filter { # フィルタプラグイン開始
if [type] == "syslog" { # typeがsyslogの場合
grok { # grokでパーシング
match => { "message" => "%{SYSLOGLINE}" } # syslogフォーマットを解析
} # grok終了
date { # 日付整形
match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ] # syslog形式の日付
} # date終了
} # 条件終了
} # フィルタプラグイン終了
output { # 出力プラグイン開始
elasticsearch { # Elasticsearch出力設定
hosts => ["localhost:9200"] # Elasticsearchホスト指定
index => "syslog-%{+YYYY.MM.dd}" # 日付パターンでインデックス作成
} # Elasticsearch出力終了
stdout { # デバッグ用標準出力
codec => rubydebug # デバッグ形式で出力
} # stdout出力終了
} # 出力プラグイン終了
💡 補足：Kibanaダッシュボード作成時は、Index Pattern に
syslog-* を指定し、タイムフィルターを設定すると効率的です。10.4.3 rsyslog のリモート転送
概要：rsyslog を使い、ローカルテキストログを別ホストへ転送して集中管理します。TLS を用いた暗号化転送例も紹介します。
実行ユーザー：root
目的：syslog メッセージを中央サーバーで一元管理
期待結果：リモートログサーバーにログが確実に転送される
# rsyslog設定ディレクトリにリモート転送設定を作成
sudo tee /etc/rsyslog.d/50-remote.conf << 'EOF' # 設定ファイル作成開始
*.* @@logserver.example.com:514 # TCPで全ログをポート514に転送（@@はTCP）
EOF # 設定ファイル作成終了
# 設定を反映
sudo systemctl restart rsyslog.service # rsyslogサービスを再起動
💡 補足：UDP転送（
*.* @server:514）よりTCP転送（*.* @@server:514）のほうが信頼性が高いです。# TLS用モジュールをロード
module(load="imtcp") # TCP入力モジュールをロード
module(load="gtls") # GnuTLSモジュールをロード
# グローバルTLS設定
global( # グローバル設定開始
DefaultNetstreamDriver="gtls" # TLSをデフォルトドライバに設定
DefaultNetstreamDriverCAFile="/etc/pki/tls/certs/ca-bundle.crt" # CA証明書パス
DefaultNetstreamDriverCertFile="/etc/rsyslog.d/rsyslog-client.crt" # クライアント証明書パス
DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/rsyslog-client.key" # クライアント秘密鍵パス
) # グローバル設定終了
# リモートホストへTLS転送
*.* @@(o)logserver.example.com:6514 # TLSポート6514で全ログを暗号化送信
❗ 注意：TLS環境は証明書管理が必須です。証明書の有効期限切れや権限設定に注意してください。
10.5 メトリクス収集ツール
システム稼働状況の長期的な分析やアラートの自動化には、時系列メトリクスを専門に扱うツールが必要です。本節では AlmaLinux9 上での Prometheus と Grafana の導入から、Alertmanager や Exporter の活用、ベストプラクティスまでを解説します。
10.5.1 Prometheus の概要と導入
Prometheus はオープンソースの時系列データベースと監視システムで、プルモデルによるメトリクス収集、柔軟なクエリ言語 PromQL、アラートルール機能を備えています。以下では主要コンポーネントとインストール手順、設定例を示します。
主要コンポーネント
- Server：メトリクスをスクレイプし TSDB に格納
- Exporter：アプリケーションや OS からメトリクスを公開（例：node_exporter）
- Pushgateway：プッシュモデルが必要なジョブ用
- Alertmanager：アラートルール評価後の通知管理
- Web UI：PromQL 実行やステータス確認
インストールとサービス設定
実行ユーザー：root または sudo
前提：AlmaLinux9
# Prometheus をインストール # prometheus パッケージを追加
sudo dnf install -y prometheus # AlmaLinux9 標準リポジトリからインストール
# Node Exporter をインストール # システムメトリクス公開用エクスポーター
sudo dnf install -y node_exporter # node_exporter パッケージを追加
# Pushgateway をインストール # ジョブ用プッシュモデル受信
sudo dnf install -y prometheus-pushgateway # pushgateway パッケージを追加
# Prometheus サービスを有効化・起動 # システム起動時に自動起動設定
sudo systemctl enable prometheus.service # enable で自動起動を設定
sudo systemctl start prometheus.service # サービスを開始
# Node Exporter サービスを有効化・起動 # エクスポーターサービス起動設定
sudo systemctl enable node_exporter.service # enable で自動起動を設定
sudo systemctl start node_exporter.service # サービスを開始
# Pushgateway サービスを有効化・起動 # pushgatewayサービス起動設定
sudo systemctl enable prometheus-pushgateway.service # enable で自動起動を設定
sudo systemctl start prometheus-pushgateway.service # サービスを開始
設定ファイル例（/etc/prometheus/prometheus.yml）
# グローバル設定 # スクレイプ設定のデフォルト
global:
scrape_interval: 15s # 15秒ごとにメトリクスをスクレイプ
evaluation_interval: 15s # 15秒ごとにアラートルールを評価
# スクレイプ対象定義 # 監視ジョブを指定
scrape_configs:
- job_name: 'prometheus' # self-scrape ジョブ
static_configs:
- targets: ['localhost:9090'] # Prometheus 自身のエンドポイント
- job_name: 'node_exporter' # OSメトリクス収集ジョブ
static_configs:
- targets: ['localhost:9100'] # node_exporter のエンドポイント
- job_name: 'pushgateway' # Pushgateway ジョブ
honor_labels: true # プッシュされたラベルを優先
static_configs:
- targets: ['localhost:9091'] # pushgateway のエンドポイント
# アラートルールファイル読み込み # 外部ルールの配置先を指定
rule_files:
- '/etc/prometheus/rules/*.rules' # アラートルールディレクトリ
💡 補足：Prometheus のメトリクスエンドポイントは HTTP で公開されます。FirewallD でポート9090, 9100, 9091 を許可してください。
アラートルール例（/etc/prometheus/rules/node.rules）
# CPU使用率が90%を超えたら発報 # High CPU アラート
groups:
- name: node_alerts # ルールグループ名
rules:
- alert: NodeHighCPU # アラート識別子
expr: avg by(instance) # PromQL: 5分間の平均CPU使用率
(rate(node_cpu_seconds_total{mode!='idle'}[5m])) * 100 > 90
for: 5m # 条件継続時間
labels:
severity: warning # アラートの重要度
annotations:
summary: "高CPU使用率を検知 ({{ $labels.instance }})" # 概要
description: "CPU負荷が90%を超えています。" # 詳細
10.5.2 Alertmanager の設定と通知
Alertmanager は Prometheus からのアラートを受信し、グループ化・抑制・ルーティング後、メールやSlackなどで通知します。以下ではインストール手順と設定例を示します。
インストールとサービス設定
# Alertmanager をインストール # alertmanager パッケージを追加
sudo dnf install -y prometheus-alertmanager # AlmaLinux9 リポジトリからインストール
# Alertmanager サービスを有効化・起動 # システム起動時に自動起動設定
sudo systemctl enable alertmanager.service # enable で自動起動を設定
sudo systemctl start alertmanager.service # サービスを開始
設定ファイル例（/etc/alertmanager/config.yml）
# グローバル設定 # 通知共通設定
global:
resolve_timeout: 5m # アラート解決のタイムアウト
# ルーティング設定 # アラートルート定義
route:
receiver: 'team-email' # デフォルト受信者
group_wait: 30s # 初回通知待機時間
group_interval: 5m # 同一グループ内の再通知間隔
repeat_interval: 1h # 解決前の再通知間隔
# 通知受信者設定 # メール・Slack等
receivers:
- name: 'team-email' # メール通知用
email_configs:
- to: 'team@example.com' # 送信先メールアドレス
from: 'alertmanager@example.com' # 送信元メールアドレス
smarthost: 'smtp.example.com:587' # SMTPサーバとポート
auth_username: 'alertmanager' # SMTP認証ユーザー
auth_password: 'password' # SMTP認証パスワード
require_tls: true # TLS必須
- name: 'slack-notify' # Slack通知用
slack_configs:
- api_url: 'https://hooks.slack.com/services/XXX/YYY/ZZZ' # Webhook URL
channel: '#alerts' # 投稿先チャンネル
title: '{{ .CommonAnnotations.summary }}' # メッセージタイトル
text: '{{ .CommonAnnotations.description }}' # メッセージ本文
💡 補足：SMTP サーバが対応していない場合、Postfix 経由でローカル配送に切り替えることも可能です。
10.5.3 Grafana の概要と導入
Grafana は多種多様なデータソースを統合し、ダッシュボードやアラートを提供する可視化プラットフォームです。Prometheus のメトリクスを直感的にグラフ化し、運用効率を向上させます。
インストールとサービス設定
# Grafana をインストール # grafana パッケージを追加
sudo dnf install -y grafana # AlmaLinux9 リポジトリからインストール
# Grafana サービスを有効化・起動 # システム起動時に自動起動設定
sudo systemctl enable grafana-server.service # enable で自動起動を設定
sudo systemctl start grafana-server.service # サービスを開始
データソースとダッシュボードのプロビジョニング
コード管理可能な YAML ファイルで設定を自動化します。
# /etc/grafana/provisioning/datasources/datasource.yml # データソース定義
apiVersion: 1 # プロビジョニング API バージョン
datasources:
- name: Prometheus # データソース名
type: prometheus # タイプを Prometheus に指定
access: proxy # プロキシモード
url: http://localhost:9090 # Prometheus エンドポイント
isDefault: true # デフォルトに設定
editable: false # UIから編集不可
# /etc/grafana/provisioning/dashboards/dashboard.yml # ダッシュボード定義
apiVersion: 1 # プロビジョニング API バージョン
providers:
- name: 'default' # プロバイダ名
orgId: 1 # 組織ID
folder: '' # フォルダ未指定
type: file # ファイルベース
options:
path: /var/lib/grafana/dashboards # JSON配置ディレクトリ
# /var/lib/grafana/dashboards/node_overview.json # ダッシュボードJSON例
{
"dashboard": {
"id": null,
"title": "Node Exporter Overview", # ダッシュボードタイトル
"panels": [
{
"type": "graph", # 折れ線グラフ
"title": "CPU Usage", # パネルタイトル
"targets": [
{
"expr": "100 - (avg by(instance) (rate(node_cpu_seconds_total{mode='idle'}[5m])) * 100)", # idle率から算出
"legendFormat": "{{instance}} CPU", # 凡例フォーマット
"refId": "A" # クエリ識別子
}
]
}
]
},
"overwrite": true # 既存を上書き
}
💡 補足：プロビジョニング機能を使うと、コード管理や自動化が容易になり、再現性の高い構成が実現できます。
10.6 パフォーマンスボトルネックの分析
システム監視で得られたデータをもとに、実際にどこがリソースの制限点（ボトルネック）になっているかを特定し、最適化につなげる手法を詳述します。CPU、メモリ、ディスクI/O、ネットワークといった主要リソースごとに検出方法とツールを解説し、さらにプロファイリングによる深掘り手法も紹介します。
10.6.1 分析の基本手順
ボトルネック分析は大まかに以下のサイクルで行います：
- 1. ベースライン取得：通常時のリソース使用量を定期的に記録
- 2. 異常検出：しきい値超過や傾向変化をアラートで把握
- 3. 局所化：CPU／メモリ／I/O／ネットワークのどこに起因するか切り分け
- 4. プロファイリング：関数レベル、システムコールレベルで詳細に追跡
- 5. 改善と再検証：設定変更やコード最適化後に再度データを取得し効果確認
💡 補足：分析は必ず検証環境でまず実施し、本番へ適用する前に影響範囲を確認してください。
10.6.2 CPU ボトルネック分析
CPU過負荷はシステム全体のレスポンス低下を招きます。以下の手法で検出と詳細分析を行います。
実行ユーザー：root または sudo ユーザー
目的：CPU使用率のピークやホットコードパスを特定
期待結果：高負荷プロセスや関数を絞り込み、改善対象を明確化
# top でリアルタイムに CPU 使用率とロードアベレージを確認
sudo top # us/sy/id/wa% や load average を動的に表示
# sar で長期的な CPU 使用率を収集
sudo dnf install -y sysstat # sar を提供する sysstat をインストール
sar -u 60 10 # -u:CPU統計を 60秒間隔で 10回収集
# perf で関数レベルの CPU プロファイリング
sudo dnf install -y perf # perf ツールをインストール
sudo perf record -F 99 -p $(pidof myapp) -g -- sleep 60 # 指定プロセスを60秒間サンプリング
sudo perf report --stdio # サンプリング結果を標準出力でレポート表示
10.6.3 メモリボトルネック分析
メモリ不足はスワップや OOM（Out-Of-Memory）を引き起こし得ます。物理／キャッシュ領域の状況やカーネルメモリを可視化します。
実行ユーザー：任意（root 推奨）
目的：物理メモリとスワップの利用状況、カーネルオブジェクト消費を把握
期待結果：メモリ圧迫やスワップ発生の原因を特定
# free で物理メモリ＆スワップ使用状況を人間可読形式で表示
free -h # total, used, free, buff/cache, available を確認
# vmstat でメモリ統計を定期取得
vmstat 60 5 # 60秒間隔で 5回、プロセス/メモリ/I/O統計を表示
# slabtop でカーネルメモリ使用をリアルタイム表示
sudo slabtop # オブジェクト別メモリ使用量を監視
10.6.4 ディスクI/Oボトルネック分析
I/O待ち時間の増大はアプリケーション全体のスループットを低下させます。レイテンシやスループットを計測し、原因デバイスを特定します。
実行ユーザー：root または sudo ユーザー
目的：ディスクレイテンシと待ち行列の長さを把握
期待結果：I/Oが集中しているデバイスや操作を特定
# iostat でデバイスごとの I/O 統計を詳細表示
sudo dnf install -y sysstat # iostat を提供する sysstat をインストール
iostat -xz 60 5 # -x:拡張統計, -z:ゼロ行非表示, 60秒×5回
# ioping でファイルシステムのレイテンシを計測
sudo dnf install -y ioping # ioping ツールをインストール
ioping -c 10 / # ルートFSの I/O レイテンシを 10回計測
# iotop で I/O 使用中のプロセスを動的に監視
sudo dnf install -y iotop # iotop ツールをインストール
sudo iotop -o # 実際に I/O を行うプロセスのみ表示
10.6.5 ネットワークボトルネック分析
ネットワーク帯域やレイテンシの問題は分散アプリケーションで顕著になります。接続状況やスループットを計測し、パケットロスを監視します。
実行ユーザー：root または sudo ユーザー
目的：帯域飽和や高遅延、パケットロスを検出
期待結果：ネットワーク経路やホスト間通信の問題箇所を特定
# ss で TCP/UDP ソケット状態を一覧表示
ss -tuna # -t:TCP, -u:UDP, -n:数値表示, -a:全ソケット
# iperf3 で帯域とレイテンシを測定（サーバー側起動）
iperf3 -s # サーバーモードで待機（デフォルトポート5201）
# iperf3 でクライアント測定（30秒間）
iperf3 -c -t 30 # -c:サーバー指定, -t:測定秒数
# ping でパケットロスと往復時間を確認
ping -c 5 # -c:送信回数を 5 回に設定
10.6.6 プロファイリングと深掘りツール
システムコールや関数呼び出しレベルでの詳細分析には、strace、bcc/bpftrace などの eBPF ベースツールが有効です。
実行ユーザー：root または sudo ユーザー
目的：ホットパスや頻出システムコールを特定
期待結果：処理時間やオーバーヘッドが大きい部分を絞り込み
# strace でシステムコールの頻度と時間を集計
sudo strace -c -p $(pidof myapp) # -c:システムコール統計を表示, -p:プロセス指定
# bcc-tools を使った execsnoop によるプロセス起動監視
sudo dnf install -y bcc-tools # bcc およびツール群をインストール
sudo /usr/share/bcc/tools/execsnoop # プロセス exec イベントをリアルタイム表示
# bpftrace で TCP 受信量を 5 秒ごとに集計
sudo dnf install -y bpftrace # bpftrace をインストール
sudo bpftrace -e 'interval:s:5 { @bytes = sum(args->count); }' # 5sごとに受信バイト合計を表示
10.7 カーネルパラメータ (sysctl) とチューニング事例
sysctl は Linux カーネルのパラメータを動的に参照・設定するためのインターフェースです。本節では sysctl の基本的な使い方から、ネットワーク・メモリ・ファイル・I/O 周りの代表的パラメータを解説し、実運用で効果の高いチューニング事例をご紹介します。
10.7.1 sysctl の概要と使用方法
sysctl コマンドを用いることで、現在のカーネルパラメータを一覧表示したり、動的に値を変更したりできます。永続化する場合は /etc/sysctl.d/ 以下に設定ファイルを配置します。
# 全カーネルパラメータを一覧表示する
sudo sysctl -a # -a オプションで全パラメータを出力
# 単一パラメータの値を確認する
sudo sysctl net.core.somaxconn # net.core.somaxconn の現在値を表示
# 動的にパラメータを設定する
sudo sysctl -w vm.swappiness=10 # vm.swappiness を 10 に設定
# 永続化用設定ファイルを作成して書き込む
echo "fs.file-max = 524288" | sudo tee /etc/sysctl.d/99-file-max.conf # 最大同時オープンファイル数を永続設定
# 永続化設定をすべて読み込んで反映する
sudo sysctl --system # /etc/sysctl.d/*.conf を含む全設定を再読み込み
10.7.2 主要カーネルパラメータ解説
システム用途別によく調整されるパラメータをカテゴリごとに解説します。
ネットワーク関連
net.core.somaxconn：TCP 同時キュー最大長（バックログ）net.ipv4.ip_local_port_range：クライアント側で使用可能なエフェメラルポート範囲net.ipv4.tcp_tw_reuse：TIME-WAIT 状態ソケットの再利用許可net.ipv4.tcp_fin_timeout：FIN-WAIT-2 の保持時間（秒）
メモリ関連
vm.swappiness：スワップ利用の積極度（0～100）vm.dirty_ratio：システム全体メモリに対する未書き込みデータ割合の上限vm.dirty_background_ratio：バックグラウンド書き込みを開始するしきい値
ファイル・I/O 関連
fs.file-max：同時に開けるファイル記述子数の上限vm.max_map_count：1 プロセスあたりのマッピング可能領域数
💡 補足：各パラメータの適切な値は、ハードウェアスペックやワークロード、同時接続数などの要件に依存するため、必ず検証環境で負荷テストを行ってから本番適用してください。
10.7.3 チューニング事例
ここでは典型的な運用シナリオに合わせたパラメータセットと、その効果・リスクについて詳述します。
A. 高同時接続 HTTP サーバー向け
大量の TCP 接続をさばく Web サーバーでは、ソケットのバックログと TIME-WAIT を適切に設定するとスループットが向上します。
# ソケットバックログを 1024 に拡張
echo "net.core.somaxconn = 1024" | sudo tee /etc/sysctl.d/99-net.conf # 同時待ち行列を増加
# クライアント側エフェメラルポート範囲を拡大
echo "net.ipv4.ip_local_port_range = 1024 65535" | sudo tee -a /etc/sysctl.d/99-net.conf # ポート範囲を設定
# TIME-WAIT ソケットの再利用を許可
echo "net.ipv4.tcp_tw_reuse = 1" | sudo tee -a /etc/sysctl.d/99-net.conf # TIME-WAIT 再利用有効化
# 設定を反映
sudo sysctl --system # すべての sysctl 設定を再読み込み
B. データベースサーバー向けメモリ最適化
ディスク書き込み遅延を軽減しつつ、スワップ介入を抑える設定例です。
# スワップ利用を抑制（物理メモリ優先）
echo "vm.swappiness = 5" | sudo tee /etc/sysctl.d/99-db.conf # スワップ積極度を低く設定
# 未書き込みデータの上限を 10% に設定
echo "vm.dirty_ratio = 10" | sudo tee -a /etc/sysctl.d/99-db.conf # 書き込みバッファ上限を設定
# バックグラウンド書き込み開始を 5% に設定
echo "vm.dirty_background_ratio = 5" | sudo tee -a /etc/sysctl.d/99-db.conf # バックグラウンド flush しきい値
# 設定を反映
sudo sysctl --system # すべての sysctl 設定を再適用
C. 大規模ファイルサーバー向けファイル記述子調整
数万スレッドや大量ファイルアクセスがある環境では、ファイルディスクリプタ制限を引き上げます。
# システム全体のファイル記述子数上限を 1M に設定
echo "fs.file-max = 1048576" | sudo tee /etc/sysctl.d/99-fd.conf # ファイル上限を設定
# プロセスあたりのマッピング数上限を引き上げ
echo "vm.max_map_count = 262144" | sudo tee -a /etc/sysctl.d/99-fd.conf # マップ数上限を設定
# 設定を反映
sudo sysctl --system # sysctl 設定を一括読み込み
❗ 注意：カーネルパラメータの設定ミスはシステム不安定やクラッシュを招く恐れがあります。設定変更前後で必ず性能・安定性テストを行ってください。
10.8 エンタープライズ監視ソリューション
大規模環境での運用効率化、拡張性、そして高可用性を実現するための監視プラットフォームを紹介します。本節では、オープンソースの Zabbix、Nagios/Icinga の構成例と、SaaS 型監視サービス（Datadog）の導入手順を解説します。
10.8.1 Zabbix の導入と基本構成
Zabbix はエージェント・サーバー方式の監視システムで、大規模環境ではプロキシを挟むアーキテクチャを採用できます。以下は AlmaLinux9 上での最小構成例です。
# Zabbix リポジトリパッケージをインストール
sudo rpm -ivh https://repo.zabbix.com/zabbix/5.4/rhel/9/x86_64/zabbix-release-5.4-1.el9.noarch.rpm # Zabbix公式リポジトリを登録
# リポジトリキャッシュを更新
sudo dnf clean all # 既存キャッシュをクリア
sudo dnf makecache # 新しいリポジトリデータを取得
# Zabbix Server と Agent をインストール
sudo dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-agent # MySQLバックエンド＋ウェブUI＋エージェント
# MariaDB をインストール（Zabbix のデータベース用）
sudo dnf install -y mariadb-server # MariaDBサーバを追加
# MariaDB を起動・有効化
sudo systemctl enable mariadb.service # ブート時自動起動を設定
sudo systemctl start mariadb.service # MariaDBを起動
# データベース作成とユーザー設定
sudo mysql -uroot << 'EOF' # MySQLコマンドをヒアドキュメントで実行
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; # zabbix DBを作成
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY 'zabbix_pass'; # zabbixユーザーを作成
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; # 権限を付与
FLUSH PRIVILEGES; # 権限テーブルをリロード
EOF # ヒアドキュメント終了
# Zabbix 初期スキーマをインポート
sudo zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -pzabbix_pass zabbix # スキーマと初期データをロード
# Zabbix Server の設定（DB接続情報を指定）
sudo sed -i 's/^# DBPassword=.*/DBPassword=zabbix_pass/' /etc/zabbix/zabbix_server.conf # DBパスワードを設定
# Apache と PHP を設定してウェブUIを有効化
sudo sed -i 's/^# php_value date.timezone.*/php_value date.timezone Europe\/Tokyo/' /etc/php-fpm.d/zabbix.conf # タイムゾーンを設定
# サービスを有効化・起動
sudo systemctl enable zabbix-server zabbix-agent httpd php-fpm # Zabbixとウェブサーバをブート時自動起動
sudo systemctl start zabbix-server zabbix-agent httpd php-fpm # サービスを起動
💡 補足：大規模環境では
zabbix_proxy を追加し、各地域やネットワークセグメントごとにプロキシを配置すると負荷分散と可用性向上が図れます。10.8.2 Nagios / Icinga の導入とカスタマイズ
Nagios およびそのフォークである Icinga はプラグインベースで柔軟に監視項目を拡張可能です。以下は Icinga2 を AlmaLinux9 にインストールする例です。
# EPEL リポジトリを有効化
sudo dnf install -y epel-release # EPELパッケージを追加
# Icinga2 およびプラグインをインストール
sudo dnf install -y icinga2 icinga2-ido-mysql monitoring-plugins-all # 本体＋IDO＋標準プラグイン
# MariaDB に Icinga 用データベースを作成
sudo mysql -uroot << 'EOF' # MySQLコマンドを実行
CREATE DATABASE icinga2 CHARACTER SET utf8 COLLATE utf8_general_ci; # データベース作成
CREATE USER 'icinga'@'localhost' IDENTIFIED BY 'icinga_pass'; # ユーザー作成
GRANT ALL ON icinga2.* TO 'icinga'@'localhost'; # 権限付与
FLUSH PRIVILEGES; # 権限を反映
EOF # ヒアドキュメント終了
# Icinga2 IDO モジュールを有効化
sudo icinga2 feature enable ido-mysql # MySQLバックエンドを有効化
# IDO設定ファイルに DB接続情報を記述
sudo tee /etc/icinga2/features-available/ido-mysql.conf << 'EOF' # 設定ファイル作成
library "db_ido_mysql" # モジュールロード
object IdoMysqlConnection "ido-mysql" { # 接続オブジェクト定義
user = "icinga", # DBユーザー名
password = "icinga_pass", # DBパスワード
host = "localhost", # DBホスト
database = "icinga2" # DB名
}
EOF # ダイアログ終了
# Icinga2 を再起動して設定を反映
sudo systemctl enable icinga2 # 自動起動を設定
sudo systemctl start icinga2 # サービスを起動
💡 補足：Icinga Director モジュールを導入すると、GUI ベースでホスト・サービス定義の管理が可能になり、運用負荷を大幅に削減できます。
10.8.3 SaaS 型監視サービス（Datadog）の活用
Datadog はクラウドベースの監視プラットフォームで、エージェント導入のみでインフラ、アプリケーション、ログ、セキュリティ等を統合可視化します。以下は Agent7.x のインストール例です。
# Datadog Agent インストールスクリプトを実行
DD_AGENT_MAJOR_VERSION=7 \ # エージェントバージョンを指定
DD_API_KEY=YOUR_API_KEY \ # Datadog APIキーを設定
bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)" # リモートスクリプトをダウンロード＆実行
# Agent 設定ファイルを編集して追加モジュールを有効化
sudo sed -i 's/# logs_enabled: false/logs_enabled: true/' /etc/datadog-agent/datadog.yaml # ログ収集を有効化
# Agent を再起動して設定を反映
sudo systemctl enable datadog-agent.service # 自動起動を設定
sudo systemctl restart datadog-agent.service # サービスを再起動
❗ 注意：SaaS 型監視はデータが外部クラウドに送信されるため、企業ポリシーに合わせて暗号化やリージョン設定を必ず確認してください。
10.9 学習のまとめ
本章では、AlmaLinux9 上でのシステム監視とパフォーマンスチューニングを網羅的に学びました。単なるツールの使い方だけでなく、監視設計の原則から実運用でのベストプラクティス、組織的な運用プロセスまでを解説しました。以下に主要ポイントと高度な考察をまとめます。
- 多層的な可観測性の構築：ホスト、ミドルウェア、アプリケーション各レイヤーで可用性・パフォーマンス・ビジネスロジックを統合的に観測し、相関分析を行うことで異常の早期発見と根本原因分析を効率化します。
- ツールの組み合わせとデータ品質：標準ツール（top/htop、vmstat、iostat、free）と専門ツール（Prometheus、ELK Stack、Grafana）を併用し、リアルタイムデータと長期履歴データを最適化。サンプリング間隔やRetentionポリシーの設計がシステム負荷とコストに直結します。
- ログ集中管理とインテリジェント検索：ジャーナルログの永続化、rsyslog/Fluentdでの暗号化転送、Elasticsearchのインデックス設計、Kibana/Grafanaによる可視化で、横断的な検索とアラートを実現。ログレベル、TTL、シャーディング戦略の最適化がパフォーマンスに大きく影響します。
- Prometheusとアラート設計：PromQLを活用した高精度なアラートルール設計、Alertmanagerによるグルーピング・抑制設定でノイズを排除。group_wait、repeat_interval、severityラベルを適切に設定し、オンコールの負荷を低減します。
- パフォーマンスボトルネックのプロファイリング：perf、strace、eBPF（bcc/bpftrace）によるCPU・システムコール・ネットワーク層の詳細プロファイリングでホットパスを可視化。Cgroupを用いたQoS制御やリソース制限との組み合わせで効果的にボトルネックを解消します。
- カーネルパラメータチューニングとリスク管理：sysctlによるネットワークバックログ、スワップ閾値、ファイルディスクリプタ上限などの調整事例を紹介。設定変更前後は必ず検証環境で負荷テストを実施し、TLSやRBACによる変更権限管理も併せて行います。
- エンタープライズ向けアーキテクチャ：Zabbix/Zabbix ProxyやIcinga2 Director、DatadogのSaaS型監視など、大規模環境でのスケーラビリティ、冗長化、セキュアなデータ収集を実現する設計パターンを解説しました。
- 継続的改善と運用文化：フィードバックループを確立し、RunbookやPlaybookのコード管理、CI/CDパイプラインでの監視テスト自動化、オンコール体制のトレーニング、KPI/SLIの定義・見直しを継続的に実施することで、組織全体の信頼性を向上させます。
💡 補足：監視基盤は導入して終わりではなく、定期的な閾値調整、クエリ最適化、Retentionポリシーの見直しが不可欠です。運用チームと協働し、継続的に改善サイクルを回しましょう。
