[카테고리:] 日本語

Terraform で AWS リソース作成 Terraform で最小コストの実習インフラを作る ⚠️ 事前案内 ㅁ 運用環境ではGSLB + 複数センサー（複数 AZ / 複数インスタンス）構成を推奨する。 Terraform に不慣れな場合は、AWS Console でリソースを手動作成し、本編（第1編）はスキップして、次の編の Suricata / ELK インストールおよびシグネチャテストガイド から直接参照しても問題ない。 インスタンス仕様に関する補足 本実習ではSuricata（NAT Instance） と ターゲットサーバー の両方をt3.medium で構成した。 これは初期構成および性能検証を単純化するための選択である。ただしコストを考慮すると、両インスタンスを同一仕様で維持する必要はない。 1. 目的 📌 Terraform コード適用範囲に関する案内（重要） 本シリーズで提供する Terraform コードは、**Suricata Inline IPS 構成を説明するための 핵심例（コア例）**のみを含む。 実際の運用環境では以下のリソースがすでに別構成・別コードで管理されている可能性が高い。 環境差異により混乱を招く恐れがあるため、本シリーズでは 運用中の Terraform 全コードは公開しない。 代わりに以下の原則で説明する。 本シリーズの Terraform ガイド原則 つまり本シリーズのコードは、コピー＆ペースト用ではなく、構造理解と応用のための基準例である。 2.…

ZabbixでNVIDIA GPUを正しくモニタリングするためには、zabbix-agent2-plugin-nvidia-gpu プラグインが必要になる。 このプラグインは以下の方法で導入できる。 本記事では ソースビルドによるインストール方法 をガイドする。パッケージで問題なく導入できている場合は、本記事の手順を実施する必要はない。 ソースビルドを採用する理由 Tip特定のドライバ／カーネル構成（Ubuntu 22.04 + Driver 55x / 57x + CUDA 12.x など）では、Zabbix Agent2 が NVIDIA プラグインのロード直後に終了してしまう既知の不具合が存在する。 以下は、実際に報告されている公式イシュートラッカーの一例である。（ZBX-25821 — agent2 がプラグインロード中にクラッシュ） https://support.zabbix.com/browse/ZBX-25821 TipOSの種類によってコマンドやパスが若干異なる場合があるため、必要に応じて環境に合わせて調整すること。 （第1回）NVIDIA GPU プラグインのソースインストール インストール環境 1. Go 1.23 のインストール（未導入、または 1.23 未満の場合は必須） 2. ビルドツールのインストール 3. NVIDIA GPU プラグインソースのダウンロード 4. プラグインのビルド 5. プラグインのインストール 6. プラグイン設定ファイルの配置 ⚠ 注意サーバ環境によってプラグインディレクトリのパスが異なる場合があるため、/etc/zabbix/zabbix_agent2.d/plugins.d のパスは必ず自身の環境で確認すること。 7.…

環境: Zabbix 7.4.3 / Ubuntu 22.04 / Apache2 Zabbix Web UI を社内向けモニタリングポータルのように見せたい場合に必要になるのが Branding（ブランディング）設定だ。問題は、公式ドキュメントが非常に簡略で、バージョンによって UI のルート構造も異なるため、そのまま操作すると正常に動かないケースが多いことだ。 本稿は、以下の環境で動作検証済みの方法をまとめたものである。 つまり、Web フロントエンドのルートは /usr/share/zabbix/ui である。 1. 一般的なレファレンスがそのまま使えない理由 Zabbix 7.x をインストールすると、通常は以下のようなディレクトリ構成になる。 そのため find / -type f -name “index.php” | grep zabbix を実行すると、両方に index.php が存在するのが正常だ。 問題は Apache が実際に /zabbix としてどのパスを参照しているかで、これは設定を確認しなければわからない。 今回の環境では Web UI のルートは /usr/share/zabbix/ui である。したがって、ブランディング用ファイルやロゴのパスもすべてこの基準で扱う必要がある。 2. Zabbix Branding の概要 Zabbix 6.x…

関連記事 : （ベアメタル / Kubernetes Pod 環境フル対応、Agent2 プラグイン基盤） Zabbix 7.4 では、MongoDB モニタリングのためにユーザー独自スクリプトを追加する必要はない。Zabbix Agent2 に内蔵された MongoDB プラグインだけで、WiredTiger、Replication、Connection など主要な指標を自動取得できる。ただし実際の運用環境は次の2つに分かれる。 ① MongoDB がベアメタル（物理 / VM）サーバーで稼働② MongoDB が Kubernetes Pod 内で動作し、Service で公開されている環境 この2つはネットワーク構造が大きく異なるため、Agent2 の設定方式も変わる。本稿は Zabbix 7.4 を基準とした実務ガイドである。 1. 対応バージョン Zabbix MongoDB エンジン ReplicaSet モニタリング（Node セッション基盤） ReplicaSet を正確に監視するには、以下2つの要素が必須となる。 しかし、この2つを単一ホストに統合することは不可能である。そのため ReplicaSet = 各ノードを独立したホストとして登録し、個別に性能指標を収集する方式が正解となる。 ※ 注意点Zabbix は ReplicaSet 専用の「Cluster テンプレート」を提供していない。（MongoDB cluster by…

関連記事 : （ベアメタル / Kubernetes Pod 環境フル対応、Agent2 プラグイン基盤） Zabbix での MySQL 監視は、以前のように UserParameter スクリプトを載せる方式ではない。Zabbix Agent2 + MySQL プラグインさえあれば、InnoDB、スロークエリ、レプリケーション、バッファ関連の指標を収集できる。 しかし、実際の運用環境は次の 2 つに分かれる。 ① MySQL がベアメタル（物理 / VM）サーバで稼働② MySQL が Kubernetes Pod 内で動作し、Service External IP によって公開されている 両環境はネットワーク構造が完全に異なるため、Agent2 の設定方式も異なる。本記事は、それらの違いを Zabbix 7.4 基準で完全に整理した実務ガイドである。 1. 対応バージョン Zabbix Zabbix Server/Proxy 7.4 以上※ Zabbix 公式サイトの説明では 5.0 以上も利用可能とされている。 MySQL エンジン 2. MySQL 監視アカウント作成（共通）…

単に「サイトが開くか？」だけを確認する監視では不十分だ。ログインページ自体が開いても、実際のログイン処理で問題が起きればユーザーはサービスを利用できない。 Zabbix の Web シナリオ（Web Scenario）機能を使えば、ログインリクエストを実際に送信し、レスポンスを検証してログイン成功の可否を監視できる。単純な HTTP 死活監視 は設定も難しくなく、検索すればガイドも多い。しかし、ログインを含む機能監視となると参考資料はほとんど見つからない。 ここでは実際の環境で適用した手順をまとめる。 1. ログイン URL と Payload の確認 まず、ログインリクエストがどの URL に送信され、どの値が送られているかを確認する必要がある。これは Chrome 開発者ツール（F12） で簡単に確認できる。 例（任意値） 👉 重要ポイント 2. curl で動作テスト Zabbix に設定する前に、curl でログイン成功の可否を確認する。 200 OK → 正常401 / 403 / 500 → URL または payload・header が誤っている可能性あり Tip. もしうまく動作しない場合は、boundary の不整合を防ぐため -H オプション（Content-Type）を削除し、curl の自動処理に任せて試してみてください。 3. Zabbix Web シナリオの設定 (1)…

サーバ運用では、CPU・メモリ・ディスク状態と同じくらい重要な指標がある。それが 電力消費量（Power Consumption） だ。データセンターは電力で動く。電力消費を把握できなければ、電気料金の算定、ラック単位の電力容量計画、過負荷防止、障害予防のすべてが成り立たない。 Lenovo サーバの XClarity Controller2（XCC2）は BMC（Baseboard Management Controller）であり、リモート管理だけでなく、SNMP（Simple Network Management Protocol）を通じて電力・温度・ファン速度などのハードウェア情報を提供する。Zabbix では Template Server Lenovo XCC SNMPv3 テンプレートで XCC2 を連携できるが、このテンプレートは Polling ベースであり、電力アイテムは標準では含まれていない。そのため、OID を調べてカスタムアイテムを追加する必要がある。 以下では、UTP ケーブル接続 → 管理ポート初期 IP 設定 → SNMPv3 有効化 → Zabbix 連携 → 電力 OID 追加までの全手順を説明する。 1. 管理イーサネットポートの初期設定 BMC（XCC2）はサーバ本体とは別の専用管理 LAN ポートを持つ。このポートは OS と独立して動作し、電源が OFF の状態でもリモート接続とモニタリングが可能だ。 物理接続 初期 IP アクセス…

参考ドキュメント:https://github.com/greatcare/pm2-zabbix 公式リポジトリの手順でもインストールは可能だが、Node のバージョン・パス・権限周りで失敗するケースが多い。以下の内容は実運用環境で検証済みの実務向けバージョンである。テンプレート（XML）は GitHub の install/zabbix-server/ からダウンロードし、Zabbix UI で Import すればよい。 1. 概要 pm2-zabbix は、PM2 プロセス状態を Zabbix に送信する Node.js ベースのモジュールである。Zabbix の LLD（Low-Level Discovery）を利用して PM2 プロセスを自動登録し、各プロセスの状態・CPU・メモリ・再起動回数、さらに PM2 God Daemon 自体の状態まで監視する。 2. 事前準備 3. root ユーザーでの基本設定 A. /etc/zabbix/zabbix_agentd.conf B. systemd サービスのアカウント確認 4. PM2 実行ユーザーへの切り替え（例: app） ⚠️ 重要: ここでの app は PM2 を実際に動かしているユーザーへ置き換えること。環境により deploy、service、node などが使われている場合がある。 A. pm2-zabbix のインストール…

背景 私が担当するチームは 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…