[작성자:] black K

背景 私が担当するチームは Cloud Engineer・DevOps・Data Engineer の三つのパートに分かれています。ある日 Data Engineer のメンバーが「Airflow の DAG の成否をアラートで受け取りたい」というニーズを挙げました。Airflow の Web UI では DAG の実行状態を確認できますが、障害を即座にアラートとして受け取る方法はありませんでした。検索してみると Prometheus ベースのダッシュボード例は少し見つかったものの、失敗アラートに焦点を当てたリファレンスは見当たりませんでした。そこで最終的に、ディスカバリルール → アイテムプロトタイプ → トリガープロトタイプまで自分で作成し、実装しました。 この記事ではオンプレミスの Kubernetes 環境で Zabbix を用いて Airflow の DAG 状態を監視した方法を共有します。Airflow REST API と通信できれば、オンプレミスの Kubernetes でもクラウド環境でも同じ方法を応用できます。ここでは Zabbix agent やその他の設定については触れません。 なぜ DAG アラートだけでは不十分なのか？ DAG が失敗することも問題ですが、それ以上に根本的な問題は Airflow 自体が正常に動作していない状況です。Scheduler が停止すると DAG が実行されず、Metadata データベースへの接続が切れるとシステム全体が止まります。Trigger プロセスが死んでいるとイベント駆動の DAG はまったく実行されません。つまり DAG の失敗アラートは“症状”であり、Airflow のヘルスチェックは“原因”に近い警告です。両方を一緒に監視することで、障害を素早く認識し、対処できます。…

一般的に Zabbix の Kubernetes テンプレートは、CPU・メモリ・ディスク・ノード状態・コンテナ状態などの基本指標を中心に提供されている。しかし Pod 単位のネットワークトラフィックは含まれていない。多くの運用環境では Prometheus を併用してこの課題を解決するが、ここでは Zabbix 単体で Pod レベルのネットワークトラフィック収集を完全に実現した構成を共有する。 この設計は参考資料が一切無い状態から独自に構築したもので、実際の運用環境で動作検証済みである。 🔗 関連記事 ■ 設計概要 データソース: Kubelet cAdvisor メトリクス収集構成: HTTP agent → マスターアイテム → Discovery(LDD) → アイテムプロトタイプ → 前処理チェーン最終目的: Pod / Namespace / Interface 単位の RX/TX トラフィック（bps） 1. マスターアイテム Kubernetes Kubelet by HTTP: Get cadvisor metricsをマスターアイテムとして使用する。 すべての Discovery およびアイテムプロトタイプは、このデータを基に動作する。 2. Discovery ルール作成（Prod…

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…