[카테고리:] 日本語

MongoDBは単なるドキュメント指向データベースにとどまらず、セッションストア、ログ分析、メッセージングなど幅広い領域で利用されている。安定運用のためには、可用性・性能・リソース・カーソル／接続・ネットワークといった領域の主要指標をバランスよく確認する必要がある。以下は、一般的に必ずチェックすべきコア指標である。 1. 可用性指標 uptime MongoDBプロセスが稼働している累積時間。 uptimeが長いほど安定稼働を示すが、頻繁な再起動は障害や設定問題の兆候となる。運用中は再起動周期とログを併せて確認することが重要。 2. 性能指標 operation latency（total） 各種操作（insert, update, query, delete, commandなど）に要した平均処理時間（ms）。 低値が正常であり、急激な上昇はインデックス不足、ディスクボトルネック、ロック競合などの可能性がある。 operation throughput（rate） 1秒あたりの実行操作数（ops/sec）。 アプリケーション負荷パターンを読み取るのに有用であり、急激な変動はトラフィック異常やアプリケーションエラーの兆候である。 3. リソース指標 connections MongoDBに接続しているクライアント数。 コネクションプールの閾値に近づくと新規接続が失敗するため、継続的な監視が必要。 memory usage（resident memory） プロセスが占有する実メモリ量。 MongoDBはworking setをメモリに保持することで性能を確保する。メモリ不足になるとpage faultやスワップが発生し、レイテンシが急上昇する。 WiredTiger cache MongoDBのデフォルトストレージエンジンであるWiredTigerが内部で利用するキャッシュ。 よく利用されるデータページをメモリに保持し、ディスクアクセスを削減する。 動作フロー：文書 → メモリキャッシュ → ディスク同期キャッシュが満杯になると eviction が発生し、古いページをディスクに書き出して新しいデータを載せる。 キャッシュ使用率が高止まりすると eviction が増加し、ディスクI/Oが膨らんで性能低下につながる。したがって、キャッシュ容量と使用率はMongoDB運用における最重要指標のひとつである。 4. カーソルおよびクライアント指標 active clients 現在read/write操作を実行中のクライアント数。瞬間的な増加はバッチ処理や特定クエリの集中実行を示す。 cursors MongoDBでクエリを実行すると、結果セットを走査するためのカーソルが作成される。 動作フロー：クエリ実行 →…

Elasticsearchは単なる検索エンジンに留まらず、ログ・メトリクス・アプリケーションデータまで処理する分散データプラットフォームとして活用される。そのため安定運用のためには、クラスタ状態・リソース使用量・性能・インデックス処理といった領域ごとの主要指標を定期的に確認する必要がある。 1. クラスタ状態指標 cluster_health クラスタ全体の状態。Green = 正常、Yellow = レプリカ不整合、Red = データ消失リスク。 unassigned_shards 割り当てられていないShardの数。0が正常。ディスク不足・ノード障害・Shard再配置の遅延などで増加。 2. リソース指標 Total size of all file stores / Total available size to JVM in all file stores 全ファイルストアの総ディスク容量、およびJVMプロセスが実際に使用できる可用領域の合計。新規Shardが追加可能かどうかを最も早く判断できる指標。 問題が発生するパターン：Availableが急速に減少するケース ディスク使用量に応じた挙動： まとめ： jvm heap usage percent JVM Heap使用率。 node uptime ノード稼働時間。再起動が頻発する場合は障害前兆。 3. 性能指標 query latency 検索クエリ応答遅延。ミリ秒単位で増加するとアプリケーション体感性能が低下。 service response_time REST APIリクエストの応答速度。継続的な増加はバックエンドリソースのボトルネックを示唆。 4. インデックス処理および接続指標…

運用環境において Redis は単なるキャッシュにとどまらず、セッションストア・キュー・Pub/Sub などの基盤サービスとして活用される。そのため、性能劣化や障害を未然に防ぐには、メモリ・ネットワーク・コネクション・永続化といった領域ごとの主要指標を定期的に確認する必要がある。 1. メモリ指標 used_memory Redis プロセスが実際に使用しているメモリ量。物理メモリに対する使用率が急激に増加すると OOM のリスクが高い。maxmemory 設定と eviction ポリシーの確認が必須。 mem_fragmentation_ratio メモリ断片化の比率。1.0 に近いほど正常。1.5 以上なら断片化が深刻 → 再起動または RDB/AOF リライトを検討。 evicted_keys maxmemory を超えたため強制削除されたキーの数。増加するとキャッシュミス率が上昇する可能性。eviction ポリシー（noeviction, allkeys-lru など）の確認が必要。 2. パフォーマンス指標 instantaneous_ops_per_sec 1 秒あたりに処理されるコマンド数（QPS）。トラフィックスパイクの確認に使用。ベースラインと比較して急増・急減するパターンに注意。 slowlog 1 秒間に Redis に記録されたスロークエリ項目数。0 に近い値が正常。一定以上の値が継続して大きい場合、アプリケーション側でブロッキングコマンドまたは大容量データ処理パターンが存在することを意味する。 3. 接続指標 blocked_clients ブロッキングコマンド（BRPOP, BLPOP など）待ちのクライアント数。急増する場合、アプリケーションのキュー処理にボトルネックがある可能性。 connected_clients 現在接続されているクライアント数。アプリケーションの接続プール設定と比較して確認。maxclients に近づくと新規接続が失敗するリスク。 rejected_connections 同時接続数超過により拒否された接続数。急増時はクライアントプールの調整が必要。 4. ネットワーク指標 total_net_input_bytes / total_net_output_bytes…

前回の記事では MySQL の指標を扱ったが、今回は Kafka を取り上げる。運用環境において Kafka は単なるメッセージキューではなく、データストリーミングプラットフォームとして重要な役割を担う。そのため Kafka ブローカーおよびクラスタ状態を細かく監視することは、障害予防や性能保証に不可欠である。 本稿では Grafana ダッシュボード（Zabbix データベース連携） に表示される主要な Kafka 指標について、その意味と読み解き方を整理する。 1. Offline Partitions Count 意味：クラスタ内でリーダーを失い、アクセス不能になったパーティション数。正常値：0異常時：ブローカー障害、ネットワーク断、ディスク I/O 不全などで発生。 👉 運用ポイント：Offline Partition が 1 つでも出ればデータロスの可能性が高く、即時原因調査が必要。 2. Under Replicated Partitions（URP） 意味：リーダーパーティションの最新データをフォロワーが同期できていない状態。正常値：0異常時：ブローカー過負荷、ネットワーク遅延、ISR 縮小など。 👉 運用ポイント：URP は Kafka 運用で最重要警告指標。瞬間的でも危険信号、継続するならリソース増強または障害対応が必要。 3. GC Pause 意味：Kafka ブローカー JVM の Garbage Collection 実行時にアプリケーションが停止する時間。 👉 運用ポイント：平均 pause time が増えるとメッセージ処理遅延につながる。Heap…

運用環境における MySQL は、単なるリレーショナルデータベースにとどまらず、多数のアプリケーションにとって中核的な永続ストアであり、サービス安定性の基盤そのものだ。したがって、MySQL サーバーおよびクエリ処理状態を細かく監視することは、障害予防や性能最適化に欠かせない。 Zabbix で読む MySQL パフォーマンス （要約） 1) InnoDB が現在開いているファイル数 意味：InnoDB がオープンしているファイルハンドル数（テーブルスペースなど）。正常範囲：数十〜数百程度。innodb_open_files の上限内なら問題なし。異常の兆候：急増 + エラー発生 → OS のファイルハンドル制限／ulimit を確認。 チェック 2) 接続状況（Aborted / Connections per sec など） 意味 判断基準（推奨） 実務的ポイント クイック確認 3) クエリ状況（Queries/s vs Questions/s） 意味MySQL バージョンにより微妙に定義が異なるが、概ね「実行された命令数/秒」と見てよい。 パターン読み取り 問題シグナル チューニング 4) MySQL ネットワークトラフィック（Bytes sent/received） 意味：DB とアプリ間 I/O の量。DML/SELECT の補助指標。 自然な相関：DML・Queries のスパイクと同時に増える。異常：ネットワークだけ急増 → ダンプ/バックアップ/レプリケーション/ヘルスチェックツール等を確認。…

— Grafana 連携による Pod CPU・Memory 使用量の動的ダッシュボード実装 📘 概要 以前にも関連内容を扱った記事があるが、より深いレベルでガイドをまとめる必要があると感じ、本記事を作成した。参考になれば幸いだ。 Zabbix で Kubernetes を監視するために Kubernetes Kubelet by HTTP テンプレートを適用すると、マクロ {$KUBE.API.URL} に設定された IP を基準として、次のようなホストグループが自動生成される。 本記事では、そのデータをもとに Pod CPU と Pod Memory 使用量を Grafana で可視化する方法を解説する。ダッシュボード作成や変数（variable）の基本操作は、以前のシリーズ🧭 「Zabbixサーバー指標をGrafanaで可視化する」 を参照してほしい。 🧩 Pod Memory の可視化 対象グループ このクエリから Pod Memory 使用量（Working set） を可視化できる。これを変数として扱い、動的ダッシュボードとして構成する。 🧮 変数作成 1️⃣ Group フィルタリング 項目 値 Name Group Hide Variable…

📘 概要 第3編で CPU・メモリ・ディスクなどの静的ダッシュボードを完成させたら、今回は Grafana の 変数（Variables） を使って、ダッシュボードを “探索型の監視画面” に拡張する方法を解説する。 変数を活用すると、次のような操作が 1 つの画面で可能になる。 1. 変数（Variable）概要 Grafana の変数は、ダッシュボード内で動的に値をクエリへ渡すための仕組みだ。Zabbix プラグインは Group / Host / Item などのクエリタイプをサポートしており、これを利用することで 同じパネルを複数ホストや複数指標に再利用できる。 つまり 「CPU 使用率パネル 1 つで全サーバーを見る」といった構造を実現できる。 2. Group 変数の設定 2.1 設定パス Dashboard → Settings(⚙️) → Variables → Add variable ※ 右上に Settings が表示されない場合：Edit をクリック 2.2 主な項目 項目 設定値 説明 Name Group…

📘 概要 Zabbix との連携が完了したら、次はダッシュボード設計の段階に進む。本記事では、単にテンプレートを読み込むだけではなく、運用担当者が CPU・メモリ・ディスク・ネットワークなど主要指標をまとめて解釈できる、実務向け Grafana ダッシュボードを構築する。 ダッシュボードとは、ただのグラフ集ではなく、「障害が発生した際、どこから疑うべきか」 を視覚化する運用マップだ。 1. フォルダとダッシュボードの作成 1.1 フォルダ作成（任意） Grafana では複数のサーバー群や指標群を整理する場合、フォルダを使うとダッシュボードの構造管理が容易になる。 Menu → Dashboards → New → New folder例：example → Create 1.2 ダッシュボード作成 フォルダ内で新規ダッシュボードを作成する。 Menu → Dashboards → example → New dashboard → Add visualization 2. 最初のパネル：CPU 使用率 2.1 基本クエリ設定 項目 値 Data source Zabbix Query Type Metrics Group 任意選択（例：Example Group）…

📘 概要 第1回で Grafana のインストールとサービス設定が完了したら、今回は Zabbix のデータを Grafana に接続する手順に進む。 本記事では Grafana 公式プラグインの一つであるzabbix plugin（alexanderzobnin-zabbix-app） を導入し、Zabbix API を通じてリアルタイムメトリクスを取得する方法を解説する。 このプラグインは単なるグラフ描画用ではなく、Zabbix の Host / Item / Trigger を直接クエリできる 強力な拡張機能で、Zabbix を Grafana の Data Source に変換する中核となるコンポーネントだ。 1. Zabbix プラグインのインストール Grafana は grafana-cli コマンドでプラグインを管理する。Zabbix プラグインをインストールするには以下を実行する： インストール後、Grafana を再起動する： ✅ 確認コマンド リストに alexanderzobnin-zabbix-app が表示されれば正常。 2. プラグインの有効化 ブラウザから Grafana にログインし： Administration → Plugins and…

📘 概要 Zabbixでデータを収集し、Grafanaで可視化することで、運用者は単なるモニタリング画面ではなく、**「指標の意味が見えるダッシュボード」**を構築できる。 このシリーズでは Zabbix–Grafana の実務連携をテーマとし、第1回では Ubuntu 22.04 + Grafana 12.2.1 のインストールと基本設定手順を扱う。 本ガイドは公式ドキュメントを基にしつつ、エンジニアの実務観点で“本当に必要なコマンドと検証ステップだけ”に絞った最小構成でまとめている。 インストール関連のドキュメントは似た内容が多く、やや退屈かもしれないが、シリーズが進むにつれ、より有用な内容を届けられると思う。 1. Grafanaのインストールと起動 1.1 必要パッケージのインストール Grafanaインストール前に、HTTPSリポジトリへアクセスするためのユーティリティをインストールする。 1.2 GPGキー登録 Grafana公式リポジトリの認証に必要なGPGキーを登録する。 1.3 リポジトリの追加（stable または beta を選択） 以下のどちらか一つだけを適用する。本番環境では stable、テストや最新機能の検証環境では beta を推奨。 Stable版: Beta版: 1.4 パッケージリスト更新 1.5 Grafanaインストール 1.6 サービス起動と自動起動設定 次のコマンドで「起動 + 自動起動登録」を同時に設定できる。 1.7 サービス状態確認 出力例: active (running) であればインストール完了だ。 2. Grafanaログイン ブラウザからアクセス: 初期アカウント: 初回ログイン後、パスワード変更画面が表示されるので新しいパスワードを設定する。 ⚠️ セキュリティ上、adminパスワードは必ず即変更すること。運用環境ではローカルアカウントではなく…