Postfix 監視
設定不要で、Postfixのメールキューのサイズ、配信率、バウンスの追跡、および接続メトリクスをリアルタイムで監視できます。
なぜ監視するのか Postfix?
Postfixは、最も広く導入されているメール転送エージェントです。メールキューの状態、配信成功率、バウンス率を把握し、通信に支障をきたす前に配信上の問題を検知するためには、Postfixの監視が不可欠です。
Postfix 監視を、 解説
Postfix 監視は、deferred キューの蓄積、バウンス率の急増（送信者レピュテーションの損害）、postscreen DNSBL の枯渇、TLS ハンドシェイクの失敗、受信トラフィックの異常パターンを、メールの停滞、ブロックリストへの追加、スプールによるディスク満杯になる前に捉えます。送信中継（トランザクションメールを送信する SaaS アプリ）、Mailcow / iRedMail セルフホストアプライアンス、メーリングリストホストでは、キュー + 拒否の可視性が、ダウンストリーム MX のダウンに対する 60 秒のアラートと、翌日 10 万件の deferred メッセージを発見することの違いを生みます。Xitoring は Postfix を自動検出し、キュー + ログを読み取り、Slack、PagerDuty、Telegram、または既存のオンコールにアラートをルーティングします。
私たちが 監視するもの
キューサイズ
active、deferred、holdキュー内のメッセージ。
配信レート
1分あたりの正常配信メッセージ数。
バウンス率
ハードバウンスとソフトバウンスのカウント。
拒否率
拒否された受信接続。
SMTP接続
アクティブなSMTP接続。
TLS接続
TLS暗号化された配信の割合。
SMTP Connections
`smtpd` へのアクティブな SMTP 接続と、1 分あたりの接続レート。急増 = トラフィックスパイク、スキャン、または DoS の試み。
TLS Encryption Rate
TLS で保護された受信 + 送信の配信の割合。現代の目標値は 95% 超 — それ未満に下がる場合は、ピアの設定ミスまたはダウングレード攻撃を示します。
SMTP AUTH Failure Rate
サブミッションポート（587）での AUTH 試行の失敗。スパイク = 認証情報のブルートフォース。fail2ban ルールと組み合わせて自動ブロックしてください。
Header / Body Check Hits
`header_checks` および `body_checks` のルールヒット率。上昇傾向は新しいスパムパターンを示します。下降傾向はもはやマッチしないルールを示している可能性があります。
Queue Age Distribution
`qshape deferred` から — 年齢バケット（5 分、10、20、40、80、160、320、640+）別のメッセージ。古い塊 = 調査が必要な滞留した配信。
qmgr / cleanup / smtpd Status
Postfix のマスターデーモンの子プロセス別の正常性。ここでの再起動やクラッシュは、設定エラーまたはリソース枯渇を示します。
設定可能 アラートのトリガー
ダッシュボードでカスタムトリガーを設定し、Postfixのメトリクスが定義した閾値を超えた瞬間に通知を受け取れるようにします。
キューサイズ
重要なメールキューが閾値を超えたときに発動。
バウンス率
警告バウンス率が高いときにアラート。
配信失敗
重要な配信失敗の急増で発動。
拒否率
警告接続拒否率が高いときに発動。
の重要性： Postfix監視
Postfixは重要なメール配信を処理します。キュー蓄積、バウンス、配信失敗は通信損失と送信者レピュテーション損傷につながります。
- 配信が影響を受ける前にキュー蓄積を検出
- 送信者レピュテーション維持のためにバウンス率を追跡
- 配信成功率を監視
- 接続問題を早期に特定
なぜ選ぶべきか： Xitoring
包括的なキューと配信メトリクスを備えたゼロコンフィグメールサーバー監視。
- ワンコマンドインストール
- 15以上のグローバルノード
- 統合ダッシュボード
- マルチチャネルアラート
- 履歴保持
Postfix 監視の一般的な シナリオ
Postfixが今日一般的に実行されている場所 — そして誰も監視していない場合に何が問題になる可能性があるか。
SaaSアプリからのトランザクションメールの送信
パスワードのリセット、領収書、通知は迅速かつ確実に届く必要があります。送信メール層が詰まると、これらの重要なメッセージが滞留し、顧客はあなたからの連絡を受け取ることができません。私たちは問題が発生した瞬間にそれを検知し、メールが流れ続けるようにします。
セルフホスト型ビジネスメールサーバー
企業がプロバイダーを使用せずに独自のメールを運用している場合、障害が発生するたびにスタッフはメッセージを送受信できなくなります。私たちはキューとスパム防御を一緒に監視し、「またメールがダウンしたのか？」と誰かが尋ねるずっと前に問題を検知します。
ニュースレターと大量送信者
大量のメールを送信する企業は、送信者評価によって成否が決まります。一度損なわれると、回復には数週間かかります。私たちは配信可能性のシグナルを追跡し、異常なアクティビティをフラグ付けすることで、修正する時間があるうちに問題を特定します。
Postfix の 前提条件
これらが揃っていることを確認してください — 揃っていれば、ほとんどの導入は 60 秒で完了します。
- Postfix MTA がインストール済みで稼働していること
- /var/log/mail.log（または設定済みの maillog）への読み取りアクセス
- postqueue バイナリがシステム PATH 上にあること
はじめに 議事録
メールサーバーに Xitogent をインストール
Postfix が稼働しているホストに軽量な Xitogent 監視エージェントをインストールしてください。
curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEYログとキューへのアクセスを確認
Postfix はメールフローを mail ログで追跡します（Debian/Ubuntu では `/var/log/mail.log`、RHEL では `/var/log/maillog`）。ログが書き込まれていること、そしてキュー検査のために `postqueue` が PATH 上にあることを確認してください。
sudo xitogent integratePostfix 連携を有効化
Xitoring ダッシュボードまたは CLI から Postfix 連携を有効化してください。Xitogent が Postfix の設定を自動検出し、キューおよび配信メトリクスのパースを開始します。
アラートしきい値を設定（オプション）
キューサイズ、バウンス率、配信失敗にカスタムしきい値を設定し、下流の送信者に到達する前にバックプレッシャーやレピュテーション問題を検知できるようにします。
動作確認
サーバー上でこのコマンドを実行して、Xitogent が連携を認識していることを確認してください。約 30 秒以内に新しいメトリクスがダッシュボードに流れ始めます。
sudo xitogent status代替ツールを 検討中ですか？
Postfix 監視の代替ツールと比べて Xitoring がどう優れているかをご覧ください — 定額料金、より深い統合、そしてスタック全体をカバーする 1 つのエージェント。
