【ご意見伺い】サーバ性能毎のトリガーについてどうしてますか?

いつもお世話になっております。

表題の件について、皆さんどうしているのかな?と思い記載させて頂きました。

Apacheのプロセス 数監視とか。
MySQLのConnection 数監視とか。
※ サーバ性能に左右されて上限値が異なる監視対象です。

AWSで言いますと、large と、8xlarge では最大値が異なる、異なりますよね?
インスタンスタイプ統一が出来ればと思いますが・・・

気軽にスケールアップした時(クラウド環境でやりがち)や、
統合監視環境で、各案件毎にはZabbixProxyを配置しZabbixServerはクラスタ1セットの時は
各案件の予算や、規模、AWS以外のクラウド環境によって同じフロントAPIサーバであっても性能が異なる事で
トリガ閾値が変わる場合です。

下記のようにならないよう、ミドルウェア単位でまとめたいです・・・。
 案件名1_Apache_Template
 案件名2_Apache_Template ・・・ etc

①そもそも複数案件をみるような統合監視環境にしない。ミドルウェアテンプレートはexport,inportで頑張る。(商用、検証も分けて検証で動作確認後に商用に反映)

②せいぜいまとめるのは、商用、検証、開発の案件セット。(商用にServer, 検証にProxy的な)

③アイテムテンプレートは共通、トリガテンプレートは個別

④小規模、中規模、大規模毎に統合監視のセットを準備して似た規模をどうにかまとめる。

⑤くっくっく、実はトリガの数値を自動で決めるスクリプトがあるんだぜ?(是非教えて下さい)

⑨スペックによって左右されるようなトリガをそもそも入れないで、アイテムのみ。(port接続監視だけでいいのでは?)

何か良い方法はないかと模索している所なので、アドバイス等頂けると嬉しいです。

コメント表示オプション

お好みのコメント表示方法を選び「設定の保存」をクリックすると変更が反映されます。
ユーザー TNK の写真

ユーザーマクロを利用して、マクロを利用したテンプレートを作成
し、テンプレートとは異なる閾値にしたい場合は、ホストごとに、
そのマクロの値を設定することで、ホストのスペックの違いでの閾
値変更を実現することは可能だと思います。

基本的な監視項目が同じで閾値が異なるだけであれば、上記のよう
なマクロを含むテンプレートにしています。

ただ、色々なスペックのサーバが混在したり台数が多くなってくる
と管理が大変ですね。
同じスペックのインスタンスを、同じホストグループにも所属させ
て一括置換を活用するとか、APIを利用して自動化するとかも合わ
せて検討してみてください。

ご参考:
https://www.zabbix.com/documentation/2.2/jp/manual/config/macros/usermacros

ユーザー tomopa2 の写真

参考にならないかもしれませんが。。。

私の環境では、テンプレートを作成してそこにアイテムとトリガーをまず入れます(A:ベーステンプレート)
Aをサーバに配って、おおまかな監視ができあがります。
つぎにサーバ毎で変更が必要な箇所(トリガー)だけホスト毎に設定しなおします。

下記③と④の中間ぐらいでしょうか。
>③アイテムテンプレートは共通、トリガテンプレートは個別
>④小規模、中規模、大規模毎に統合監視のセットを準備して似た規模をどうにかまとめる。

これは私の個人的なポリシーなのですが、不必要にトリガーを作成するのではなく
本当に対応が必要なものだけトリガーを作るようにしています。

たとえば、CPU使用率75%でアラート
→あと25%も余力がある!(と、自分に言い聞かせる)ので、
わたしは95%以上(しかも15分以上継続とか)でトリガーさせます。

そうすると、少々スペックが違っても閾値が統一できるので運用も楽です。

ユーザー s.shibano の写真

すみません、遅くなりました。

>TNKさん
返信ありがとうございます。

> 基本的な監視項目が同じで閾値が異なるだけであれば、上記のよう
> なマクロを含むテンプレートにしています。
参考にさせて頂きます。

> 同じスペックのインスタンスを、同じホストグループにも所属させ
> て一括置換を活用するとか、APIを利用して自動化するとかも合わ
> せて検討してみてください。
現在、グループを案件毎に設定している為、スペックごとにするのが・・・。
グループ+役割としてサブグループがあると幸せになれるんですけど、
それはそれで複雑化しそうで、ホストの自動登録も合わせて実施すると
後からはいじれない事になりそうなレベルですよね。。。

と、いうところで ② ぐらいを目標にまとめるべきなのかなという方向も検討してみます。

>tomopa2さん
返信ありがとうございます。

> これは私の個人的なポリシーなのですが、不必要にトリガーを作成するのではなく
> 本当に対応が必要なものだけトリガーを作るようにしています。
これは本当にそうですね。
障害予兆的なレベルまで含めると結構涙目な量のアラートになっているので、
サービス影響有無を閾値にしたいですね。

> たとえば、CPU使用率75%でアラート
> →あと25%も余力がある!(と、自分に言い聞かせる)ので、
> わたしは95%以上(しかも15分以上継続とか)でトリガーさせます。
CPU、 Mem、Disk、Networkについてはそれぞれ%でとれるような状況になってきたので、
インスタンスサイズを気にする事はなくなってきましたね。
※ CPUについはLoadAVGが、2.0以降 per coreになったのでコア違いまで吸収されました。

と、いうところで、スペックからくる最大値が変わる固定値について悩んでおりまっす。

> 私の環境では、テンプレートを作成してそこにアイテムとトリガーをまず入れます(A:ベーステンプレート)
> Aをサーバに配って、おおまかな監視ができあがります。
> つぎにサーバ毎で変更が必要な箇所(トリガー)だけホスト毎に設定しなおします。
ホスト毎は・・・心がつきそうなので、やめたぃ。。。
2.0から?アイテムテンプレートとトリガテンプレートを別々に用意できるようになった?気がする?ので、
共通アイテムテンプレートと、案件ミドルウェアトリガテンプレートを用意するのとどちらが
管理、変更するのが容易か引き続き検討していきたいと思います。

ありがとうございました。