Kodai's Blog

Amazonでfeelersコントローラ、温湿度センサーなど販売してます

2017-10-04T20:49:00.000+09:00

Interop Tokyo 2016、2017と2年間ShowNet環境の温度監視をZabbixから行えるように温度監視のためのセンサーとコントローラを提供してきました。

過去の経緯はZabbix Conference Japan 2015の私の発表でご説明したり、このBlogのInterop 2017 ShowNetの記事でもお伝えしています。

その後、feelersコントローラとセンサー用のサイトを作成し、Interop 2017 ShowNetで20ラック分の温湿度・気圧の監視を行うために、事前にコントローラやセンサーを余分に作成したものをAmazonで販売を始めてみました。

このfeelersコントローラはIP接続が可能でZabbixエージェントのネイティブプロトコルを利用できるため、Zabbixサーバーからは通常のエージェントと同じように監視設定ができます。Zabbixエージェントのアクティブチェックと同じように動作する専用のファームウェアを搭載し、Linuxベースのものとは異なりOS自体の管理などが不要で、設定などはWebインターフェースから行えます。SNMPv1も利用できるためZabbix以外の監視ソフトウェアからも利用可能です。

現在のところコントローラに接続できるセンサーは以下の5種類あります。製品それぞれの情報やAmazonへのリンクは製品一覧のページにあります。

温度・湿度・気圧センサー
温度・湿度センサー
気圧センサー
ケーブルタイプの温度センサー
接点センサー

上のShowNetの時の画像にも写っていますけれど、例えば音湿度気圧のセンサーはボックスタイプで、この中に温度・湿度・気圧のセンサーが入っています。

コントローラとセンサーはRJ45ケーブルで接続してセンサーデータの送受信と電力の供給を行う仕組みになっています(上の写真のRJ45ポート)。無線接続のような配置の自由度はありませんが一般的なLANケーブルを利用でき、電力の供給を考える必要はないため手軽に利用できます(コントローラとセンサー間はLANケーブルで接続しますがIP通信を行っているわけではなく、センサー単体では利用できません)。無線タイプのものは電源供給をどうするかであったり、意外と電波干渉でデータ通信が途切れてしまったりということもあるようですので、屋内のあまり広くない範囲で利用する場合は有線接続の方が良いんじゃないかと思っています。

IP接続できる温度・湿度監視などが行える機器は比較的高価なもが多いように思うのですが、feelersコントローラ・センサーは小規模なサーバールームの温度・湿度、扉の開閉などに比較的安価に利用できます。IoTは言葉が先行している感がありますけれど、とりあえず簡単に温度監視などがしたい、という場合に手頃だと思います。Zabbix Japan社内でもサーバールームはあまり空調設備が整っていないので、このコントローラとセンサーを利用して主に温度の監視を行っています。

そもそもの経緯

もともとこのコントローラとセンサー自体はZabbix Conferenceで会った人が自社のデータセンターや環境監視サービスで利用していたものでした。最初は興味本位から少量をZabbix Japanオフィスの監視用に使ったりしていたところ、その会社ではセンサー事業を行わないことになり製造を委託していた会社を紹介してもらって今に至ります。

温度などの環境監視の話は時々聞くこともあり、面白いとは思うのでZabbix Japanとして販売できないかと本社とも相談してみたのですが、製造自体はZabbix社で行っているものではないですし、結局は個人での販売ということろに落ち着いてます。今年はじめに個人事業主登録をしてfeelersサイトの作成や必要分の少量の製造依頼と輸入を行ってます。

とりあえず販売を行うにしても引っかかったのがコントローラとセンサーを接続するRJ45のスプリッタ(ハブではなく)で、日本国内ではほとんど流通してません。最初はAmazonで2分岐のものをいくつか買ってみたものの、あまり品質が良くなく通信ができなかったり、ケースの接合部が浮いてしまってすぐに使えなくなったりと散々となってしまい、最終的にはAmazonではなくて中国の製造メーカーと直接話してやっと使えるものが見つかりました。

コントローラは24センサーまで接続ができるので2分岐スプリッタだけだと分岐が多くなりすぎるということで、4分岐、8分岐のスプリッタも入手しています。通信自体は問題ないものの外観的にもう少し品質の高いものがないか、引き続きより良いものを探しています。

今後について

とりあえず手持ちで余っていたほとんどはAmazonへ出品してみたので、次の製造依頼をどこかで実施しようと思っています。

今のところセンサーは温度、湿度、気圧、接点のものがあるのですが、クランプタイプの電流センサーの試作品を作ってもらっています。これまでZabbixでは監視ができなかったような領域のデータ収集ができるのはなかなか楽しいですね。Amazonで販売してみるとかも良い経験ではありますけれど本業が忙しいこともあり、ゆるゆるとやってますのでよろしくお願いします。

お問い合わせはこちらから

ご質問などありましたらfeelersサイトのお問い合わせページからご連絡ください。

Interop Tokyo 2017 Shownetの構築

2017-05-27T16:37:00.002+09:00

Zabbix Japanを設立してから毎年参加しているInterop Tokyoが今年も6/7(水)から6/9(金)に開催されます。直近4年はInterop会場内のネットワークを提供するShowNetにも参加して、ShowNet内のシステム全体の監視を行っています。Interopの会場内に設置されている来場者向けのWifiや、出展者向けのネットワークもこのShowNetが提供しています。

ShowNetについての詳細はこちらから:

ShowNetとは? : Interop Tokyo 2017

今年もShowNetの開催が始まりまして、木曜日から作業を開始して今日も幕張メッセで作業中です。

今年は4月に販売を開始したZS-7300アプライアンスをメインで利用してシステム全体の監視を行う予定になっていまして、昨年の実績からは全体で700〜800ホスト程度の監視になる予定です。このシステムの監視をZabbixのパートナーさんの有志と一緒におよそ5日間で構築開始から完了させる予定です。

Zabbix Enterprise Appliance ZS-7300

もう1台、Dell R220サーバーも持ち込んでいるのですが、こちらはZabbix 3.2をインストールして予備として稼働させます。合わせてZabbixのパートナーさんのソリューションのテストや、今後のソリューション/プラグイン開発のためのテストとして利用します。今年はネットワーク機器から送信されたsyslogをZabbixのホストごとに自動振り分けするプラグインを作成してみたので、興味のある方はInteropのZabbixブースでご説明できます。

また、1つ前のブログ投稿で書いたZabbix対応のセンサーを持ち込んで、各ラックの全面1点の温度・湿度・気圧と、背面の上中下3ヶ所の温度監視を全20ラックに対して行います。

下の写真がセンサーを1ラック分を組み立てたところです。四角いボックスが温湿度気圧センサー、赤いケーブルが3つ見えるものが先端が温度センサーになっています。昨日はパートナーさんと一緒にこれを20台分設置する作業を行ってました。

昨年のShowNetのZabbixサーバーが入っているラックはこんな感じでした。今年もZabbixサーバーが搭載されているラック番号は#15、背面も見えるラックになっているので、Interop会場に来られたらぜひZabbixとセンサーの位置も確認してみてください。InteropのZabbixブースでもShowNetの監視をしているZabbixの画面をご覧いただくこともできます。

また、6/7(水)の16:00から、Interop会場内のShowNetステージにて「Zabbixを利用したShowNetシステム環境の監視」プレゼンテーションを行います。どのような機器を監視しているのか、5日間でどうやって数100台の機器の構築を行なったのかを知りたい方はこちらもぜひ！

Zabbix対応の温湿度・気圧、接点センサー購入者の募集

2016-12-17T02:59:00.001+09:00

2015年のZabbix Conference Japanでも簡単にご紹介、今年のInterop Shownetでもラックの温度監視に利用していたZabbix対応のセンサーについて、数名の方から試してみたいとお話をいただいていることもありまして、私(個人)が必要なものを製造依頼するとの合わせて評価用のセットを共同で購入する人はいませんか、というご案内です。

このセンサーはコントローラとセンサーをつなげて利用するようになっていて、1つのコントローラには8個までのセンサーをつなげられます。

コントローラ本体

こちらがコントーローラ本体。USB miniBで給電するようになっていて、10MbpsのLANコネクタをネットワークに、1Wポートからはイーサネットケーブル(RJ45コネクタ)でセンサーにつなげます。

IPアドレスの設定などはWebインターフェースから行うことができます。

このコントローラが特殊なのはファームウェアにSNMPv1とZabbixエージェントのアクティブチェックプロトコルが実装されているところで、Webインターフェースからホスト名、ZabbixサーバーのIPアドレスを設定するとZabbixネイティブな通信でセンサーデータをZabbixサーバーに送付することができます。

センサーの種類

コントローラとセンサーの接続は一般的なLANケーブルが利用できるので特殊なケーブルを購入しなくても済みます。センサーデータをコントローラへ送付することと、センサー自体への電源供給も1本のLANケーブルで行います。

今のところ接続できるセンサーには3種類あります。

温湿度・気圧センサー
1.5メートル温度センサー
接点センサー

温湿度・気圧センサーは3種類のセンサーが1つのボックスに入っているタイプです。

1.5メートルの温度センサーはRJ45端子が付属しているので、そのままコントローラへ接続できます。

接点センサーは見た目は温湿度気圧センサーと見た目はほぼ同一です。ケースを開けるとA/B接点があり、ここにマグネットセンサーなどを接続すればZabbixからは0/1データで状態を監視することができます。

コントローラから複数センサーを接続する場合はスプリッタを間に挟みます(スイッチングハブではなくて単純に線を分岐するだけのものです)。

日本国内ではこのRJ45のスプリッタが入手しづらく、いくつかのルートで比較的安価なものを購入はしてみたものの品質に難がある場合も多く、品質が良いものを探すのが少し難しそうです。引き続き良い購入先を探し中です。

試してみたい方はこちらまで

このセンサーを試してみたいという方は、上記のコントローラ、3種類のセンサーが1つずつ入った評価キットという形で製造してもらおうと思います。スプリッタは品質が良いものが見つかれば良いのですが、そこそこの品質のものでもよければ余ってるものを1個おまけで入れておきます。

とりあえず支払いは実際に私の手元に機器が届いてからで良いので、購入希望の方はセット数と氏名、メールアドレスを以下のフォームからご連絡ください(価格はリンク先にあります)。

Zabbixセンサーキットの購入希望フォーム (締め切りました)

どのくらい興味のある方がいるか分からないこともあり、今年いっぱいまで募集を受け付けようと思います。2017年1月中には送付できるようなスケジュールで考えています。

なお、もともとこのセンサー自体はZabbix Conference(ラトビア本社開催)でお会いした方が実運用で利用されているものにZabbixエージェントプロトコルを実装したファームウェアを載せたもので、機器自体はキワモノではなくて数年の実績があるものです。Zabbix Japan社内でも1年ほどサーバールームと社内の温度・湿度監視に利用していますが特に問題なく継続利用できています。

ご質問などがあればコメントからよろしくお願いします。

追記:

VISA、Master、Amexであれば、PayPalではなくてもクレジットカード決済できるようになりました。領収書の発行も可能です。

追記2:

Amazonでコントローラ/センサーの販売を開始しました。詳細はこちら

Zabbix Conference Japan 2016

2016-11-29T21:45:00.000+09:00

今年もZabbix Conference Japan 2016も無事終了しました。ご来場いただいた方々、登壇いただいた方々、それからスポンサーいただいたパートナー様、どうもありがとうございました。

今年は想定よりもスポンサー企業様が多く、大変ありがたく思っています。とはいえ予定よりもスポンサー登壇が多くなったため技術的な内容が昨年までよりも少なくなってしまい、来場いただいた方々からはもっと技術的な濃い話が聞きたかった、という声が聞こえてきそうな気もしています。

来年は4.0(LTS)リリースというタイミングでもあるため、アジェンダをうまく調整したいと思います。

アジェンダのページに登壇資料も公開したので、他にもいくつかZabbix Conference Japan 2016に関係するリンクとあわせて記載しておきます。

カンファレンス全体の詳細記事も近日中に公開予定です。もう少しかかりそうですが公開されたら追記します。

私のプレゼンテーションの中で実施するとお話ししたZabbix 4.0への新機能追加要望のリクエストについて、現在社内で集計を行っています。今回は早めに集計をしてリクエストを出す予定なのでどの要望を採用したかも公表するようにします。

Zabbix 4.0へ向けた機能要望

2016-08-07T00:36:00.001+09:00

もうだいぶん前の話になってしまいましたが、Zabbix Conference Japan 2015の私のプレゼンテーションで「Zabbix 4.0へ向た日本からの機能要望を出そう」というお話をしました。

来場いただいた方と、懇親会に参加いただいた方に機能要望を募集して、その中から要望が多かった機能について、Zabbix Japanから本社の開発サービスを利用して、具体的にこの機能を実装してほしい！ということを実施してみようという取り組みです。

Zabbix Conference 2015を実施した2015年11月の時点でもZabbix 3.2(ポイントリリース)に対してすでに世界からたくさんの開発サービス利用要望をもらっていたこともあって、次のバージョンへ追加する新機能や改善については、なかなか日本で要望が多い機能のプライオリティを上げることが難しいという状況もあったためです。

開発サービスはZabbix本体への修正や機能追加を直接依頼できるサービスです。自分がZabbixユーザーの立場ならちょっとした機能や実装が不足していることに困っている状況であれば、苦労して回避策を作るよりこのサービスを利用した方が後々苦労せずに済むと思うんですけれど、日本からはあまり利用されていないんですよね。

修正が構築期間ないに終わらないといけないとか、予算の問題とか、そもそもオープンソースに対する修正に費用を出すという感覚がないとか、色々と理由はあるんでしょうけれど。日本国内もまったく使われていなこともなくて、パートナーさんによってはうまく活用されて要件に不足している機能を補われていたりします。

さて、Zabbix 4.0に向けた機能要望について、Zabbix Conference Japan 2015でいただいた要望のうち特に多かった以下の2つを選定して依頼を行っています。

ローレベルディスカバリで作成されたアイテムなどの設定を変更したい
ホストグループの階層化

上記機能が欲しかった！という方は今後のリリースに期待頂ければと思います。

他にも以下のような要望も多かったのですが、これらは今回はZabbix Japanからの機能要望としては見送ることになりました。大きな変更が必要なためにすぐには実装が難しかったり、すでに実装されることが予定されている、などが理由です。

Webインターフェースからのアイテム手動実行
アイテム、トリガー、メンテナンスなど設定ごとや、有効/無効化など機能ごとの権限設定
Webシナリオのインポート/エクスポート

もちろん、上記の機能や開発サービス以外でも新機能の実装や機能改善はどんどん行っていますので、もうすぐリリース予定のZabbix 3.2もご期待ください。

今年のZabbix Conference Japan 2016は11/18(金)開催です。今年は場所を変えてもう少し広い会場を予定していますので、こちらもお楽しみに！

Zabbix 3.0をリリースしました

2016-02-22T00:52:00.001+09:00

予定よりもだいぶん遅くなってしまいましたが、Zabbix 3.0をリリースしました。

LTSリリースでは2013年11月のZabbix 2.2のリリースから2年3ヶ月ほど、ポイントリリースも含めると2014年9月の2.4のリリースから1年半ほど経ってのリリースになりました。

Zabbix 3.0ではWebインターフェースのデザインが一新されたほか、クラウドやリモート環境の監視でセキュアに通信が行える通信の暗号化機能や、既存の収集データから予測検知を行えるトリガー関数などの機能追加を行っています。

ほかにも障害通知に利用するメールサーバーのSMTP認証対応やアイテムの監視タイミングを任意に決めることができる機能、トレンドデータのAPI、XMLインポート/エクスポートに値のマッピング設定が含められるようになっているなど、これまでZabbixを利用されていた方にも魅力的な機能を追加しています。

新機能の詳細はZabbix社サイトのZabbix 3.0の新機能やドキュメントのWhat's new in Zabbix 3.0.0ページを参照してください。(Zabbix 3.0の新機能ページはただいま翻訳中です)

Zabbix 2.2 LTSを利用されている方はZabbix 2.4, 3.0の双方の新機能や機能改善が含まれることになるため、Zabbix 3.0へアップグレードするためには両方のメジャーバージョンのリリースノートを確認してください。

Zabbix 3.0のダウンロード

これまでと同じくZabbix 3.0は以下のページからソース、rpm/debパッケージ、検証用のアプライアンスという形でダウンロードできます。

Zabbixオフィシャル日本語サイト: ダウンロード

検証用のアプライアンスはZabbix 3.0用からベースのOSがUbuntu 14.04になり、公式のdebパッケージをそのまま利用するように変更しています。

Zabbix 3.0系のイベントやセミナー

Zabbix 3.0についてもっと知りたい！という人はぜひ下記のイベントやセミナーに参加ください。

2016年2月26日(金) オープンソースカンファレンス 2016 Tokyo/SpringでZABBIX-JPコミュニティで「Zabbix 3.0でどう変わるか」のセミナーがあります
2016年3月10日(木) Zabbix社のWebセミナーを「Zabbix 3.0の新機能」にリニューアルします。そのあとも毎月1回開催してますので、お時間のあるときにぜひご参加ください。
2016年3月16日(水) Tech-Circleにて「Zabbix3.0リリース記念！世界最速? Zabbix3.0ハンズオン」を開催します。私も冒頭20分ほどZabbix 3.0の新機能についてお話しします。

Zabbix 3.0の注意点

細かな機能についてはサイトやドキュメントでも説明されているためここでは省略して、Zabbix 3.0の利用にあたりいくつかの注意点について説明しておきます。

WebインターフェースのPHPサポートが5.4以上に

Webインターフェースを動作させるためにはPHP 5.4以上が必要になります。Red Hat Enterprise Linux 5と6に含まれているのはPHP 5.3のため動作対象外になりました。RedHat系ディストリビュションではPHP 5.4以上が含まれるRHEL7やCentOS7以上でのみ動作させることができます。

この制限を含めて考えると現在Webインターフェースを動かすことができるディストリビューションは以下です。

Debian 7 (Wheezy)
Debian 8 (Jessie)
Ubuntu 14.04 (Trusty)
Red Hat Enteprise Linux / CentOS 7

SMTP認証のサポート

Zabbix 3.0では障害通知メール送信にSMTP認証を必要とするメールサーバーを利用することができるようになりました。この機能を利用するためにはlibcurlのバージョン7.20以上が必要です。RHEL6ではcurlのバージョンが7.19となるため動作しません。

Zabbix 3.0はRHEL6以下では動作しない?

Zabbix 3.0をインストールまたはアップデートしようとして、あれっ？となった人も多いのではと思います。

標準のRHEL5, 6ではZabbix 3.0の動作要件を満たしていないという点ではWebインターフェースは残念ながら動作しなくなります。RHSCLやサードパーティのリポジトリ(remiなど)を利用して動作させることは可能ですけれど、OS標準構成では動作しなくなるということから今のところZabbix社のリポジトリではZabbixサーバーとWebインターフェースを除くZabbixエージェント、Zabbixプロキシ、Java GatewayのみRPMパッケージを作成しています。

RedHat系のOSはライブラリやミドルウェアのバージョンが低いんですよね。現実問題としてRHEL6系をまだ利用しているユーザーさんもいることは理解しているので、RHEL7系にどうしてもバージョンアップができないというZabbix公式サポート加入ユーザーさん向けには暫定策としてRHEL6系でも利用できるように対策を検討中です。続報をお待ち下さい。

Zabbix 3.2

Zabbix社内ではすでに次のメジャーバージョンとなる3.2の新機能について議論が始まってます。Zabbix Japanからは3.2に限らず次のLTSをターゲットに4.0までに入れて欲しい機能をいくつかリクエストしていく予定にしています。

Zabbix本社からのクリスマスプレゼント2015

2015-12-28T11:26:00.001+09:00

毎年25日前になるとZabbix本社からクリスマスプレゼントが届きます。

今年はお菓子とステンダースというラトビアの石鹸、人形、メッセージカードがモールに包まれて送られてきました。

人形とメッセージカードはZabbix Japanオフィスの入り口前に飾ってあります。

人形が持っているクリスマスカードはZabbix Japanからお送りしているクリスマスカードです。ヨーロッパの企業ですし、年賀状よりクリスマスカードかなということで、設立から毎年送ってます。今年のデザインにはどこかに隠れZマークが入ってるそうなので、届いた方は探してみてください。

オープンソースカンファレンス2015 .Enterpriseに参加してきました

2015-12-21T12:20:00.001+09:00

2015/12/09に渋谷で開催されたオープンソースカンファレンス2015 .Enterpriseに参加してきました。

最近は忙しくなってしまい前回の通常開催のオープンソースカンファレンス Tokyo/Fallには参加ができず、久しぶりのオープンソースカンファレンスへの参加になりました。

Zabbixブースの様子。

13:00から「Zabbixによる監視の自動化とZabbix 3.0の新機能」のセミナーも行っていました。

セミナーやブースにお越しいただいた方々、どうもありがとうございました！

残念ながら予定が重なってしまい次回の東京開催のオープンソースカンファレンス Tokyo/SpringにはZabbix Japanとしては参加が難しそうです。次回予定しているZabbix公式としてのイベント参加は2016年6月のINTEROP Tokyoになるかもしれませんが、少し先なのでその前に何かイベントに参加または企画したいところではあります。

Zabbixグローバルダッシュボードを公開しました

2015-12-09T00:03:00.000+09:00

今年のINTEROP 2015でも参考出展していて、先日のZabbix Conference Japan 2015でも公開しますとお話ししていたグローバルダッシュボードを一部に限定して公開を開始しました。

Zabbix Enterpriseカスタマーポータルにログインして右側のメニューに「グローバルダッシュボード設定」というメニューから設定と起動リンクにアクセスできます。今のところサポート加入ユーザー様、パートナー様と先日Zabbix Conference Japan 2015に出席いただいた方にアクセス権限があります。

グローバルダッシュボードの画面は(現在のところ)こんな感じです。複数のZabbixサーバーに接続できるのですけれど、スクリーンショットの都合で1台のZabbixサーバーのみに接続している状態です。

Webアプリケーションとして開発していて、かつZabbix APIだけを使っているのでアプリケーションのインストーやダウンロードをしなくても良いという点がメリットで、Webからアクセスするだけですぐに試すことができます。その代わりブラウザの動作環境は少し制限されます。

本来であればZabbix社の社員としてZabbix本体のインターフェースの開発に時間を割く方が筋だろうという話もあるわけで、最初にこのダシュボードをZabbix Conference Japan 2014でお話ししてから、世の中に公開すべきかどうか少し迷ってました。が、せっかく作ったこともありINTEROPでは幾つかポジティブなフィードバックを頂いたこともあり公開することにしました。

既にたくさんの機能を持っているZabbixの画面をいきなり大きく変えるのは(開発的な意味でも、既にユーザーさんがUIに慣れているという意味でも)なかなか難しいということもあり、かつ個人的には今のZabbixの画面も多数の機能を細かく設定できるという点でそんなに悪いものでもないと思っています。

このダッシュボードに関しては少し視点変えて、今の状態をシンプルな形で表示することを考えて作成しています。インターフェースAPIを使えばこれぐらいできますよ、という活用の1つとしても参考にしてもらえるんじゃないかと思っています。

現時点ではまだまだ開発途上ですし、仕事の合間に開発していることもありあまり力をかけられないので一部の公開にとどめています。Zabbix Japanが出展するイベントなどではアクセスできるようになる評価キーを配布できますので、興味がある方はブースまでお越しいただければと思います。

今気づいているバグの修正と、まだまだ改善するアイデアがあるのでこれから順次改善していく予定です。ご意見があればTwitterでもお問い合わせフォームからでもイベントなどでお会いした時にでも良いのでぜひフィードバックいただだければと思います。

Zabbix 3.0では、ZabbixのWebインターフェース自体を拡張しやすいようにするために独自の画面拡張機能も追加されていますので、「見たい情報を表示する」という意味ではAPIの活用と合わせてZabbix 3.0にもご期待ください。

明日は渋谷で開催されるオープンソースカンファレンス2015 .Enterpriseに参加する予定です。13:00から「Zabbixによる監視の自動化とZabbix 3.0の新機能」のセミナーも予定しています。

2016/01/04追記

Zabbix Conference Japan 2015へ参加いただいた方で、一部の方にグローバルダッシュボードを閲覧する権限が正しく設定されていなかったようで、アクセスするとサポート契約登録画面に戻されるというご連絡をいただきました。設定を修正していますのでうまくアクセスできなかった方はお手数ですが再度アクセスしてみてください。

Zabbix Conference Japan 2015を開催しました

2015-11-29T17:20:00.000+09:00

11月20日に開催したZabbix Conference Japan 2015も大盛況のうちに無事終了しました。来場いただいた方々、ご登壇いただいた方、スポンサーいただいたパートナー様、どうもありがとうございました。また、開催にあたり忙しいなか作業をしてくれた社員のみなさま、お疲れ様でした。

Zabbix Japanを設立してから3年、毎年11月に開催を行ってきて今年で3年目になります。毎年200名以上の方に参加いただき、関係者の皆様のおかげで無事成し遂げることができました。

200名以上の方にご来場いただき、会場もほぼ満席状態でした。

会場の後ろに設置していたスポンサー企業様のパネルです。

数は少なかったものの今年は本社から持って帰ってきたZabbixグッズの販売も行いました。思っていたよりも好評で午後には完売してしまっていたようで、こちらも来年はもう少し多目に販売できるようにしたいと思います。

会場が200名のキャパシティしかないこともあり毎年満員御礼で参加できなかった方もいらっしゃると思います。来年以降はもう少し大きな会場も検討したいと思っています。Zabbix Conference Japan 2015の登壇資料はアジェンダのページで公開していますので、興味のある方は是非見ていただければと思います。

Zabbix Conference Japan 2015 アジェンダ

その後の懇親会もライトニングトークとプレゼント抽選会で盛り上がりました。参加者の方が写っているものしかなかったため写真は雰囲気だけですが、普段あまり接する機会がない方々ともお話ができ、次の開発につながる意見などもお聞きすることができました。

私のプレゼンテーションでは2つほど直近で実施することをお話ししたのですけれど、アンケートや懇親会出席カードの裏に書いていただいた「Zabbixへの機能追加要望」については現在まとめています。集計でき次第どこかで発表を行いつつ、社内で調整をしてどの機能を実際に開発するかを決めていきたいと思います。

参加いただいた方々にグローバルダッシュボードを公開する件についても準備を進めています。少し遅れていますがもうすぐアクセスできるようになりますので、準備が整い次第このブログでもアナウンスするようにします。

来年も11月第3週目の金曜日11/18日に開催を予定していますので是非ご参加ください。登壇してみたいという方も募集しております！

サーバ/インフラエンジニア養成読本管理/監視編の改訂版が出版されました

2014-04-19T04:01:00.000+09:00

4月11日にサーバ/インフラエンジニア養成読本管理/監視編の改訂版が出版されました。

2012年4月に発売されたムックだったのですが、2年経って改訂されています。改訂にあたり、Zabbixに関するページについてもZabbix 1.8ベースからZabbix 2.2ベースに変更し、最新の情報になるようにアップデートを行いました。

Zabbix 2.2のインストールから基本的なシステムを想定した設定についても解説を行っており、書籍の全体のうち50ページ以上がZabbixの解説になっています。また、Zabbix以外の監視ソフトウェアの解説や、システム監視とは、といった基本的なことも解説を行っています。

はじめてシステム監視の仕事に関わる方や、Zabbixを初めて使う方、Zabbixで何ができるのかを知りたい方にはちょうど良い内容になっています。ぜひご活用ください。

Zabbix 2.2をリリースしました！

2013-11-15T03:03:00.001+09:00

11月12日、Zabbixの新メジャーバージョンとなるZabbix 2.2をリリースしました。このバージョンではVMware仮想環境の監視機能と、Windows WMIサポートなどの新機能が追加されています。

Zabbix 2.2の新機能の一覧はZabbixドキュメントのWhat's New 2.2.0のページに記載されています。

OSC Kyotoで私が講演した「Zabbix 2.2の新機能とオフィシャルサービスの紹介」の資料はSlideShareで公開していますので、こちらもどうぞ。

あとはZabbix認定パートナーのSRA OSSさんがZabbix 2.2の評価レポートを公開されています。新機能を使ううえでポイントとなるところがまとまっています。

Zabbix 2.2では100以上の新機能と機能改善を行っています。新たな監視機能はもちろん、パフォーマンスも一層向上し、1台の監視サーバーから数万オーダーの監視対象を監視できるようになりました。これまで世界中の大規模システムのカスタマーから寄せられた具体的な報告をベースに改善を行ってきているため、そのパフォーマンス改善はすでに実証済みのものがほとんどです。

1つ前のメジャーバージョンとなるZabbix 2.0リリース以降、世界中のカスタマーやパートナー、コミュニティからおよそ3,000にのぼる機能修正、機能追加要望がありました。Zabbix 2.2リリースまでの1年半の間にそのうちおよそ2,000件の修正、コミット数にして12,000コミットを達成することができました。

外からわからない部分でも内部的には大きく作り替えられているところもあり、大小さまざまな点で改善が行われています。Zabbix 2.2のRPMパッケージ、Debパッケージもすでに公開していますので、ぜひ使ってみてください。yum/aptを使って簡単にインストールできます。インストールなどはドキュメントをご参考ください。

Zabbix 2.2のリリースまでの道のり

本来はZabbix 2.0のリリースから1年後の今年5月に2.2をリリース予定だったのですが、いくつか大きな機能の追加があり、今回は1年リリースは達成できませんでした。長い間待っていただいたユーザーの方々、大変お待たせしました。

今回はZabbix Japan設立後初、かつオフィシャルRPM/Debパッケージを公開してからも初のメジャーバージョンのリリースということもあり、いろいろと準備に奔走しました。リリースは予定より半年遅れたものの、私個人やZabbix Japanとしては多少時間的に余裕があって逆に良かったのかもしれません。

9月にはZabbixパートナー会でZabbix 2.2の共同検証を行い、細かな問題点を洗い出すことができましたし、この時点でZabbix認定パートナーとは2.2の細かな改善点や修正点も共有でき、Zabbix 2.2の活用に向けてもパートナー含め準備を整えることができました。

Zabbix 2.2のリリース前にはBug Squashing Eventを開催し、コミュニティユーザーと共同でRC前の1日の間に159コミット、37件のバグ修正を行いました。クオリティもこれまでのリリースに比べて向上しています。イベント前後でWebインターフェースの翻訳も完了させることができ、日本語のインターフェースは翻訳率100%に1番乗りでした。

今回はこのイベント自体も初開催だったためアナウンスが十分ではなかったこともあり、私も参加していた夕方以降(日本時間)で知っている限り、残念ながら日本からの参加や報告はなかったように思います。次回2.4のときも同じようにリリース前のクオリティ向上のためのイベントが開催されると思いますので、ぜひ参加してみてください。英語で海外のエンジニアとコミュニケーションできる絶好のチャンスですし、不安なところがあればサポートしたいと思います。

Bug Squashing Event中、隣の席で参加いただいた@qryuuさん、あとインターフェースの日本語訳などを細かく改善していただいた@atanakaさん、どうもありがとうございました！

次の2.4でも再度、1年後のリリースを目指します。以前よりも社内でのワークフローの流れも良くなり、開発スピードは上がってきているので、次回は達成できるのではないかと思っています。期待して待っていてください！

旧バージョンからのアップグレード

日本ではまだZabbix 1.8を利用されているユーザーも多いのではないかと思います。Zabbix 2.0ではローレベルディスカバリによるアイテム/トリガー/グラフ設定の自動作成や、SNMPトラップの設定方法/パフォーマンスの改善、トリガーのメモリキャッシュによるZabbixサーバーのパフォーマンス改善など、Zabbix 2.2では加えてVMware監視機能、Web監視の改善、WMIサポート、さらなるパフォーマンス改善などさまざまな機能追加と改善が行われています。

Zabbix 2.0/2.2にアップグレードすると監視のパフォーマンスが改善されることによってより多くの監視設定ができるようになり、設定管理の手間も大幅に改善されます。ぜひこれを機会にアップグレードを検討してみてください。

ただ、残念ながら1.8以前のバージョンから2.0以降にアップグレードするためには、Zabbixデータベースの過去の監視データが保存されている領域の変換処理が必要となり、多くのデータが保存されている場合は変換処理に数時間を要します。その間、Zabbixサーバーは停止する必要が出てきてしまいます。(この機能改善はZabbix 1.8の時代にNTTコムテクノロジーさんからの協力で行われたものですので、ZABICOM 1.8を使われている場合はアップグレードの時間はかかりません。)

Zabbix社では世界中の大規模ユーザーのサポートを行う中で、1.8以前から2.0以降へ、監視の停止時間を最大で数分までに抑えてアップグレードするノウハウがあり、Zabbixパートナー会で日本国内のZabbix認定パートナーにはその技術をお伝えしてあります。

Zabbix 2.2リリースにあわせて、Zabbix 2.0/2.2ファストアップグレードサービスも開始しますので、アップグレードしたいけれども不安がある場合はご活用ください。

Zabbix 2.4に向けて

社内でひたすらバグ修正と機能追加を行っている開発チーム、世界中のカスタマーやパートナーからのサポートに答えつつ、コミュニティの対応も行っているサポートチームにひとまずお疲れさまと言いたいところですが、これからZabbix社では次の2.4リリースに向けて議論を行っていきます。

日本国内から要望として多く上がっている機能については、次の2.4リリースに追加すべく私から社内でpushしていきますので、何か要望がある方はイベントなどで私を捕まえていただくとか、twitterで@kodai74もしくは@zabbix_jp宛にメッセージを送るか、公式サポートを利用いただいているユーザー様はパートナー経由でぜひ意見を上げてください。Zabbixはこれまで、ユーザーからの意見を着実に反映して機能強化/改善を行ってきています。

Zabbix 2.4に必ず追加して欲しいという機能があれば、開発サービスも提供しています。2.2で追加されたVMware監視機能、Web監視機能の改善などは、世界中のユーザーから開発サービスを利用して頂いて実現した機能です。Zabbixを個別カスタマイズするくらいなら、開発サービスを利用した方がコミュニティへの還元と、以降のメンテナンスコストの大幅削減を実現できると思います。

最後に

とにもかくにも、Zabbixは世界中の協力的なコミュニティ、ユーザー、カスタマー、パートナーに支えられて日々、順調に開発が進んでいます。引き続き、ご期待＆ご協力をよろしくお願いします！

Zabbixで10,000台のサーバーを監視する

2013-11-03T20:07:00.001+09:00

Zabbixは重い！というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。

Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。

海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していっています。(自分たちである程度修正できるだけの技術力は持ちながらも)そうやって自社での個別ソース修正などを避けることで不要な運用コストを削減しているようです。本社に行ってサポートの仕事をし始めたころ、海外のユーザーはOSSをよく理解し、サポートをうまく活用してるんだなぁと関心したものでした。(バグについても同様です)

そうやってマイナーバージョン、メジャーバージョンごとにパフォーマンスが改善されて今があります。実際にユーザーが大規模環境で使っている以上、パフォーマンスが悪いはずはないと思ってます。

ちなみに、海外のユーザーはZabbixサーバーを複数台に分けることはあまり好まないようです。そもそも複数台に分けると監視設定の管理などの運用コストが高くなるため、それを嫌っているのだろうと思っているのですが実際に聞いたことはないので真相は不明です。

ということで、Zabbixのパフォーマンスはそんなに悪くないよ！ということを自分でも確認するためにも、今回はそこそこのハードウェアで10,000台の監視ができるかどうか？というパフォーマンステストを行ってみました。

利用したサーバーのスペックはこちら。1Uタイプのサーバーを購入したことを想定して、それほど高価にならないスペックで構成してみました。

CPU: Intel Xeon E3-1240 v2 (4C/8T 3.4GHz)
メモリ: DDR3-1600 16GB
RAIDカード: LSI MegaRAID SAS 8708EM2 (3GBps/BBWC付き 128MBキャッシュ)
ディスク: Seagate 3.5inch SATA HDD 64Mキャッシュ x2 RAID 1構成

RAIDカードだけ古いのですが、手元に余っていたのがこれだけだったのでご勘弁を。SATAを利用しているのでそれほどパフォーマンスに影響はないかなと思っています。

パフォーマンスの測定方法

日本ではRHELやCentOSが使われることが多いと思うので、上記サーバーにCentOS 6.4 x86_64をインストルし、MySQL 5.1、Zabbix 2.0.9をインストールしてテストを行います。

さすがに監視対象を数千台も用意できないので、VMware上で3台ほどLinuxサーバーを起動してZabbixエージェントをインストール、Zabbixに同じIPで異なるホストを登録していきます。Zabbixのエージェントは動作が軽量なので、これでも十分耐えられます。

監視にはZabbix 2.0.9に標準で付属するTemplate OS Linuxを利用します。デフォルトでは監視間隔が短めなので、すべての監視項目を5分間隔の監視に変え、過去データの削除処理の負荷を見るためにヒストリの保存期間を7日に変更しています。ローレベルディスカバリも動作するとだいたい1ホストあたり45監視項目になります。

MySQLの初期設定

MySQLには以下の基本的な設定を入れてから起動してます。他にもパフォーマンス改善のためのチューニング設定はありますが、とりあえずはベーシックなチューニングを行っています。

innodb_file_per_table
innodb_buffer_pool_size=12G
innodb_log_file_size=256M
innodb_log_files_in_group=2
innodb_flush_method=O_DIRECT

また、RHEL/CentOSに付属のMySQLはRHEL/CentOS 6.3以降でInnoDB Pluginが利用できるようになっています。InnoDB Pluginを利用することで、内部の書き込みスレッドを複数起動し書き込みパフォーマンスが向上します。

/etc/my.cnfに以下の行を追加するだけでInnoDB Pluginを有効にすることができるので、これを設定しない手はありません。今回は最初からInnoDB Pluginを有効にした状態でテストを行っています。

ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so

RAIDカードの設定

ライトキャッシュの効果を見たかったので、最初はRAIDカードをWrite Throughモードで動かしています。負荷が高くなったときにライトキャッシュをONに設定してみます。

パフォーマンスの見方

パフォーマンステストはCPUロードアベレージ、CPU使用率、Zabbixのプロセスのビジー率、監視アイテムのキューを見ながら、

CPUロードアベレージ、CPU使用率が高くなっていないか
Zabbixプロセスのビジー率が高くなっていないか(70%以下が目安)
アイテムのキューが溜まっていないか

という点を見ていきます。基本的にはアイテムのキューの数が増えなければ遅延なく監視できていると判断できます。

では、パフォーマンステストを行っていきます。

MySQL 5.1、5000監視対象

とりあえず5000ホストを登録。アイテム数が22万、720nvpsほどになってます。

このときのパフォーマンスグラフです。まだロードアベレージやCPU使用率は余裕があります(上の2つのグラフ)。キューも溜まっていません(右下のグラフの赤い線)が、housekeeperプロセスのビジー率が1時間に1回高くなっていることが分かります(右真ん中のグラフの黄色線)。

housekeeperというのは過去のデータを削除するためのプロセスなのですが、大規模になるとデータ数も多くなり、削除するデータを探す->削除するという処理に負荷がかかっていることが分かります。

housekeeperが重くなることは想定済みなので、あとでDBのパーティショニングを行いたいと思います。この時点では他の点ではほとんど負荷がない状況なので、とりあえずこのまま1万台までホストを追加してみます。

MySQL 5.1、10000監視対象

ホストを10000台まで追加してみました。アイテム数45万、1400nvpsほどになっています。

さすがにこのくらいになるとキューが溜まっていて、スムーズに処理ができないようになってきました。ただ、ロードアベレージとCPU使用率はそれほど高くないですが、history syncerのビジー率が100%になっている(右真ん中グラフの赤線)ことと、history write cacheの空き率(左下グラフの青線)がときどき0%になっています。

history syncerは収集したデータをメモリキャッシュからDBに書き込むためのプロセスで、DBへの書き込みがボトルネックになっていることが分かります。

実はこのあとhousekeeperを止めてDBのパーティショニングを行ったのですが、パフォーマンスの改善は見られませんでした。上記のグラフの通り、housekeeperプロセスが1時間に1回動いたとき、housekeeperのビジー率は高いものの、そのときにCPUやI/O負荷に与える影響はそれほど大きくなっていないため、止めてもそれほどシステムへの負荷は変わらなかったようです。(ちなみにこの時点でZabbixのDBはトータル100GBほどありました。)

MySQL 5.1、10000監視対象、ライトキャッシュ有効

ここでRAIDカードのライトキャッシュを有効にしてみたところ、負荷が大幅に下がりました。グラフ真ん中の少し途切れているところがライトキャッシュを有効にするためにサーバーを再起動したところです。

ライトキャッシュを有効にする前のCPUのI/O waitの値はそれほど高くないものの(およそ25%程度)、RAIDカードを搭載してライトキャッシュを有効にすることでパフォーマンスは大幅に改善されることが分かりました。

MySQL 5.1、10000監視対象、ライトキャッシュ有効、より細かなチューニング

上記でもかなりパフォーマンスは改善されたのですが、まだ1時間に1度history syncerのビジー率が高くなっていることが分かります。これはトレンド(グラフ用に収集データをサマリしたもの)の計算を行う処理が1時間に1度動作するためです。

デフォルトのTempate OS Linuxに含まれている監視設定には数値データのものが多いため、トレンドデータの計算にも負荷がかかりやすい状況になっているようです。

キューに溜まっているアイテムは0になっているため監視の処理自体はスムーズに行われているものの、このトレンド計算のための負荷が気になります。もうちょっと負荷を抑えられないかということでOS、MySQL含めいろいろとパラメータ調整を行ってみたところ、ある程度まで負荷を落ち着かせることができました。

ところどころキューが出ていますが(右下グラフの赤線)、多くても2個程度ですし、すぐに0に戻っているためあまり問題にはならなさそうです。

グラフの後ろの方でhistory syncerの負荷が上がっているタイミングがありますが、これは直前にWebインターフェースから長い期間のスクリーンを表示したことによる影響が出ているのだと思われます。I/O負荷などはまだ低いのでもっと監視対象を増やせそうな気もしますが、Webインターフェースからの負荷の影響があることを考えると、このくらいに止めておいた方が良さそうです。

MySQL 5.5、10000監視対象

さて、いろいろなところでMySQL 5.5のパフォーマンスが良いという情報がありますし、海外の大規模Zabbixユーザーの多くはMySQL 5.5(そろそろMySQL 5.6に移行中)です。MySQLを5.5にアップグレードするとパフォーマンスがより改善され、Webインターフェースからのアクセスがあっても安定するのでは、という期待をこめてテストをしてみました。MySQLの設定は上記と同条件で、InnoDB Pluginは5.5でデフォルトとして採用されたためパラメータをコメントアウトしています。

個人的にかなり期待してアップグレードしたのですが...。あまりパフォーマンスが改善された様子はなく、なんだか逆に少し悪くなっているような気もします。5.5で追加されたパラメータなども調整してみたのですがあまり変わらずでした。

history syncerが発行するクエリは単純なinsertですし、InnoDB PluginとMySQL 5.5ではZabbixサーバーが使う部分ではそれほど大きな違いはないのかもしれません。

結論

Zabbix 2.0.9とMySQL 5.1で10,000台、45万アイテム/5分間隔という規模でも監視できることを確認できました。正直、このハードウェアでこれだけ監視できれば十分なのではと思ってます。

また、今回テストした環境ではMySQL 5.1ユーザーは少なくともInnoDB Pluginを利用していれば十分パフォーマンスは得られそうです。苦労してMySQL 5.5にアップグレードしてもあまり効果はないかもしれません。それよりも、適切なハードウェアを選択し、適切なチューニング設定を行う方が大切に見えます。

今回のテストでは主に数値データを収集していますので、ログ、トラップデータ監視が大量にある場合はまた違った結果になるかもしれません。余力があれば、ログやトラップデータを中心に監視した場合のテストと、MySQL 5.6を利用したテストも行ってみたいと思います。

Zabbix Japan 1周年＆Zabbix Conference Japanを開催します

2013-10-30T01:23:00.001+09:00

気づいたらZabbix Japanを設立してから1年が経ちました。ちょうど昨年の10月1日に設立をしたので、今月の1日に1周年でした。

ラトビアから帰ってきてその日に法務局に設立申請を出しに行ったのがつい最近のようなそうでないような。いずれにしても、なんとか1年無事に過ごすことができました。20社まで増えたパートナーさんや関係者の方々にも色々と助けていただき、会社としても順調に成長できています。どうもありがとうございます！

1周年を記念して、というわけではないですが11月22日に日本で初開催となるZabbix Conference Japanを開催します。

予想を超えて申し込み開始後すぐに埋まってしまったので来れない方も多いのではないかと思います。会場の都合上どうしても定員は増やせないものでして、来年はもう少し広いところで開催できないか、早いうちから検討したいと思います。

いろいろな企業の方に登壇いただくことができ、パートナーさんからスポンサー協力もたくさん頂きましてどうもありがとうございます。あとは当日、来場いただく方に満足していただけるよう着々と準備を進めていますので楽しみにしていてください。

カンファレンスのあとは懇親会を行います。今回は初開催ということもあり、ちょっと豪華なレストランでの開催を予定してます。懇親会ではZabbixグッズなど当たるイベントを企画中なのですが、なんと、弊社のアプライアンスのハードウェアをご提供頂いているぷらっとホームさんからZabbix Enterprise Appliance ZS-5200を1年の保守までつけて1等賞としてご提供いただけることになりました！ということで懇親会もお楽しみに！

忙しさにかまけてこの1年はあまりコミュニティ活動や勉強会などに割ける時間がほとんどなかったのですが、次の1年はもう少し自由になる時間が欲しいなぁと思ってます。

Zabbix Conference 2013に参加してきました

2013-10-02T08:51:00.000+09:00

2013年9月6日(金)から7(土)にラトビアで開催されたZabbix Conference 2013に参加してきました。

参加してきましたというよりは主催者側でもあるのですが、今年はラトビアにいたときとは違って準備の手伝いなどはあまりしていないため、参加者側の気分で参加してました。

今年も20カ国から152人の参加と世界各国からたくさんのユーザーに来ていただきました。Zabbix Conferenceは今年で3回目です。どちらかというと技術トピックが多く回を重ねるごとに内容が濃くなってきているように思います。ユーザーが増えてきて、より深いところまで活用している人が増えてきているのだと思います。

2日間あるトピックのうち2つがZabbix社からのセッション、2つがスポンサーからのセッションで、それ以外はユーザーからのセッションでした。今年日本からはZabbixのパートナーでもあるNTTコムテクノロジーさんとSRA-OSSさんがスポンサーになっていただきました。どうもありがとうございました！

セッションの数は非常に多かったので、個人的に面白いと思ったのは以下のセッションです。

Zabby - Zabbix Agent Written in Python : ZabbixエージェントのPython実装 (Evgeniy Petrovさん)
Which Database is Better for Zabbix? PostgreSQL vs. MySQL : ZabbixバックエンドDBとしてのPostgreSQLとMySQLのパフォーマンス測定 (SRA-OSS 盛さん)
Monitoring Outside the Box. External Factors in Your Datacenter : Zabbixから温湿度、振動、光などのセンサーを監視 (Alf Solliさん)
Why on Earth Was I Not Notified!? : Zabbixのアクション実行確認機能 (Volker Fröhlichさん)

あとはZabbixからも以下の2つのセッションがありました。

Zabbix: Where We Are (Alexei)
The Highlights of Zabbix 2.2 (Pavel)

すべてのプレゼンテーションは以下のページから閲覧できます。今後動画の公開も予定されているので、編集が完了次第同じページにアップロードされるはずです。

Zabbix Conference 2013 - Agenda

あとは私が各セッション中にツイートしたものを@snowy_morningさんがまとめてくださったものがあります。

Zabbixカンファレンス2013（Zabbix 2.2の話も） #zabbix_jp

Zabbix Conferenceは毎年開催期間中に参加者も交えたファンスタッフアジェンダという企画があり、今年もボーリングやパーティ、観光など盛りだくさんでした。

いくつか写真を貼っておきます。すべての写真はZabbix社サイトのフォトギャラリーに掲載されているのでこちらもよろしければどうぞ。

Zabbix Conference 2013 - Photo Gallery

Zabbix Conferenceイベントの前夜祭はボーリング

勝ったチームには特大ビールというのは昨年からのお約束ですね

次の日からが本番。今年は開催期間中本当に天気が良かったです。

会場の様子です。

1日目が終わったあとのパーティー

ラトビアでは超有名なバンドらしいのですが…ごめんなさい、知らないです。

パーティーの最中、投票が多い新機能追加要望から1つ選んで2.2に実装しますよ！という企画をやってました。ZBXNEXT-581はローレベルディスカバリに複数のフィルタを追加できる機能です。ただいま絶賛開発中です。

2日目。パーティーの次の日ですけどみなさん真剣に質問してました。

会場ではZabbixグッズも販売してました。このマグカップはいくつか日本に持って帰ってきましたが、大量に持って帰ってこれないので日本国内には20個もないレア物です

最後はAlexeiのクロージングスピーチで終了しました。

これで終わりではなく、そのあと有志をつのってバスに乗り込みルンダーレ宮殿の観光にいきました。

内部はこんな感じ。ベルサイユ宮殿を小さくしたような建築物です。ラトビア観光ではお勧めできる1つです。

そのあとも打ち上げと称した飲み会で結局夜中まで飲んでました。

日本からはちょっと遠いですが、毎年こんな形でZabbix Conferenceは開催されていますので、来年は日本からの参加者をもっと増やしたいですね。Zabbixでもなければラトビアに行く機会もないと思うので、ぜひご参加ください！

第1回Zabbixパートナー会を開催しました

2013-04-04T21:19:00.000+09:00

本日、第1回Zabbixパートナー会を開催しました。

Zabbix Japanの設立時にもパートナー企業の方々に集まっていただいてZabbix Japanの設立目的などの説明を行ったのですが、そのときは11社28名の参加、今回は14社40名の参加とパートナー企業様も増えてきています。

今回はラトビアの本社からCEOのAlexeiにも来てもらって、冒頭の挨拶をしてもらいました。私からはこの会の設立主旨、今後Zabbix Japanから提供するサービスや、今検討しているサービス、Zabbix 2.2の新機能などについて説明を行いました。

ご存知の通りZabbix社はZabbixソフトウェアをオープンソースで公開しているわけですが、開発自体は企業で行っています。当然、自分たち(社員)が生活していくための最低限の収益が必要なわけで、その大部分はテクニカルサポートとトレーニング、開発サービスです。

そういった意味ではZabbixはパートナーとサポートカスタマーからのスポンサーシップで開発が継続できているんだ、という気持ちで日々仕事をしてます。

Zabbix Japanはパートナー経由でのみオフィシャルサポートを提供していますので、日本ではパートナー企業と一緒に成長し、良いサービスを継続的に提供していくことがとても大切だと考えています。「成長」にもいろいろありますが、一番重要なのは技術力ですから、

Zabbixの新バージョンについての情報
既知の問題など
私を含め、Zabbix社が持っている情報やノウハウ

などをパートナーとうまく共有できるような仕組みを作っていきたいと考えています。

一方向の情報発信だけだと長続きしないので、パートナー各社がそれぞれ実施していて、かつ手間を省きたいと考えている部分。例えば新メジャーバージョンの機能検証などは共同で実施できると良いですね。

具体的にどういったことを実施していくかなど決めなければいけないことはたくさんありますが、パートナー支援のために日本に帰ってきて支社を設立したので、今年はパートナーとどうやって密にコミュニケーションを取っていくかを考えて実行に移していく1年にしたいと思っています。

終了後には懇親会も開催しました。各パートナーの方に自己紹介いただいたりして、交流もいただけたようで良かったです。また定期的に開催していきたいと思います。

Zabbixオフィシャルリポジトリを公開しました

2013-03-10T13:35:00.001+09:00

ZabbixオフィシャルRPM/Debリポジトリを公開しました。

以前の記事で事前公開していたものと全く同じ構成で、正式にGPG署名されたものを公開しています。

正式公開にあたってyumやaptによるインストールとアップデートができるようになっていますので、ここではリポジトリの登録方法を紹介します。正式なドキュメントの方もあわせてご参考ください。

RHEL、CentOS用yumリポジトリの登録方法

RHEL、CentOSのバージョンによって以下のようにリポジトリ登録用RPMをインストールしてください。

RHEL5/CentOS5

# rpm -ivh http://repo.zabbix.com/zabbix/2.0/rhel/5/x86_64/zabbix-release-2.0-1.el5.noarch.rpm

RHEL6/CentOS6

# rpm -ivh http://repo.zabbix.com/zabbix/2.0/rhel/6/x86_64/zabbix-release-2.0-1.el6.noarch.rpm

上記パッケージのインストールが完了したら、yumリポジトリを利用できるようになっていますので、以下のコマンドでZabbixサーバーとエージェントをインストールできます。

# yum install zabbix-agent zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese

日本語環境で利用する場合はzabbix-web-japaneseパッケージをインストールしてください。このパッケージをインストールしない場合はグラフで日本語が正しく表示されません。依存関係で必要なものはすべて自動解決されてインストールされます。Zabbixサーバーの動作に必要なfping、iksemel、libssh2パッケージなどもオフィシャルリポジトリで用意していますので、epelなど他のリポジトリを追加で登録する必要はありません。

zabbix_getコマンドとzabbix_senderコマンドは別パッケージに別れていますので、必要に応じてzabbix-getパッケージとzabbix-senderパッケージを指定してインストールしてください。

以降のインストール手順は事前公開の記事の「データベースの設定と初期データのインポート」以降と同様です。

Debian、Ubuntu用aptリポジトリの登録方法

ZabbixオフィシャルリポジトリではDebian 6、Ubuntu 10.04 LTS向けのdebパッケージとリポジトリも公開しています。Ubuntu 12.04 LTS向けのパッケージは現在準備中です。OSによって以下のコマンドでリポジトリ登録用debパッケージをインストールしてください。

Debian 6

# wget http://repo.zabbix.com/zabbix/2.0/debian/pool/main/z/zabbix-release/zabbix-release_2.0-1squeeze_all.deb
# dpkg -i zabbix-release_2.0-1squeeze_all.deb
# apt-get update

Ubuntu 10.04 LTS

# wget http://repo.zabbix.com/zabbix/2.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_2.0-1lucid_all.deb
# dpkg -i zabbix-release_2.0-1lucid_all.deb
# apt-get update

DebianやUbuntuの場合、dbconfigの機能によって自動的にデータベースの作成と初期DBのインポートが行われるようになっているのですが、MySQLの場合データベースのエンコードがlatin1のままになってしまいます(dbconfig側の設定で指定できないためです。PostgreSQLの場合は問題ありませんし、Debian 7もしくはUbuntu 12.04では修正されると思われます)。そのため先にMySQLデータベースのインストールとデフォルトエンコードの設定を行った上でZabbixのパッケージをインストールする必要があります。

以下のコマンドでMySQLサーバーをインストールします。インストール途中にMySQLのrootアカウントのパスワードを聞かれますので設定しておいてください。

# apt-get install mysql-server

/etc/mysql/my.cnfの設定を変更し、デフォルトのキャラクタセットを指定します。

[mysqld]
...

character-set-server=utf8
innodb_file_per_table
innodb_buffer_pool_size=512M # 搭載メモリによって適切な値を設定
innodb_log_file_size=64M  # innodb_buffer_pool_sizeを増やしたらこちらも増やしておく

...
[mysqld_safe]

設定を反映させるためにMySQLを再起動します。

# /etc/init.d/mysql restart

また、日本語環境で利用するためにグラフ用のフォントを先にインストールしておきます。おすすめはvlgothicフォントまたはIPAフォントです。

# apt-get install ttf-vlgothic
または
# apt-get install otf-ipafont-gothic

ここまで設定したらZabbixのパッケージをインストールします。DebianやUbuntuでは日本語ゴシックフォントがインストールされていれば、自動的にそのフォントを利用するようになっています。途中でdbconfigを利用する選択を行うと、MySQLのrootアカウントのパスワードとZabbixの初期DB接続用のパスワードが聞かれますので入力してください。dbconfigがZabbixの初期DB作成とDB接続用の設定を行ってくれます。

# apt-get install zabbix-agent zabbix-server-mysql zabbix-frontend-php

以降のインストール手順は事前公開のときの記事の「Webインターフェースの設定」以降と同様です。

今後のZABBIX-JP配布のRPMパッケージについて

ZabbixからオフィシャルのRPM/Debパッケージが正式公開されましたので、今後はZABBIX-JPではRPMパッケージの作成は行いません。ZABBIX-JPではオフィシャルリポジトリの公開を待っていたためZabbix 2.0のパッケージは作成していませんでした。Zabbix 1.8はすでに古いですし、2.0で解決されている根本的な問題がいくつかあります。

また、Zabbix 1.8からZabbix 2.0のアップグレードは履歴データのテーブルの変換をともなうため、1.6->1.8や2.0->2.2のアップグレードと比較すると時間がかかります。監視を無停止でアップグレードする方法もあるのですが、通常は履歴データの量に応じて数十分から数時間程度かかると考たほうが良いです。そういったことも含め、今後Zabbixをインストールされる場合はオフィシャルのZabbix 2.0パッケージをインストールすることをお勧めします。

Zabbixの日本支社、Zabbx Japanを設立しました

2012-10-09T12:33:00.001+09:00

2012年10月1日にZabbixの日本支社、Zabbix Japanを設立し、代表に就任させて頂くことになりました。

10月3日に記者会見を行い、Zabbix CEOのAlexei、私から支社設立の詳細の説明、ZabbixのパートナーであるNTTコムテクノロジー様、在日ラトビア大使のPeteris Vaivars様から賛同の言葉をいただきました。

記者会見ではたくさんの記者の方に集まっていただき、どうもありがとうございました。いくつかのWebサイトに記事を書いていただきました。

ITPro: OSS統合監視ツールZabbixが日本法人設立、サポートを強化

クラウドWatch: オープンソース統合監視ソフトを開発するZabbixが日本支社を設立

朝日新聞デジタル: オープンソース統合監視ソフトを開発するZabbix社が日本支社を設立〈BCN〉

@IT: Zabbix、Chef……OSSのインフラ運用支援ツールが日本のビジネス強化

設立の経緯や目的などは上記記事を見て頂ければと思います。また、10月10日(水)〜12日(金)に開催されるITPro EXPO 2012でもブース展示とセミナーを行います。より詳細を聞かれたい方はぜひブースにお越し頂ければと思います。(セミナーでもZabbix Japanについて説明予定です。申し訳ないのですが現時点でセミナーは満員御礼とのことでした。)

日本を離れたのが昨年の4月、ちょうど1年半ほどラトビアで生活をしてきたわけですが、Zabbix SIAのとても優秀なエンジニアやセールス／マーケティングの人たちと一緒に仕事ができ、自分自身もかなりスキルアップできたように思います。初海外生活ということもあって、毎日が新しいことだらけでエキサイティングな日々でした。

ラトビアはとても住みやすかったこともあって、後ろ髪引かれる思いで日本に帰ってきたのですが、今後は日本国内、日本時間で活動ができるようになります。インターネットがあれば日本国内のニュースを見たり、Twitter/Facebookでの連絡は簡単ですが、勉強会に参加したりユーザーさんと直接話ができないのは寂しいところがありました。

今後は同じタイムゾーンで技術サポートやコミュニティ活動ができるだけでなく、オフィシャルサービスの質と内容をより向上させるために、パートナー企業様とも連携して尽力して行きたいと考えています。

Zabbix Japanの営業開始は10月16日(火)です。弊社連絡先はプレスリリースを参照ください。また、設立とあわせて協賛いただけるパートナー様と一緒に「Zabbixサポート10%割引キャンペーン」も実施しますので、こちらもぜひご利用ください。

ラトビアの生活についてはまた後日、別エントリを書こうと思います。

Zabbix SIAのオフィシャルRPMパッケージの事前公開

2012-05-31T19:04:00.000+09:00

2013/3/7更新: Zabbix SIAオフィシャルのRPM/Debパッケージリポジトリが公開されました。yumやaptも利用できます。今後はこちらのマニュアルを参考に2.0パッケージのインストールを行ってください。

Zabbix SIAでは現在オフィシャルRPM/Debパッケージを公開するべく作業を進めています。

本当は2.0のリリースにあわせてパッケージを公開できれば良かったのですが、パッケージ公開サーバの準備が遅れているため公開することができませんでした。

とはいえある程度パッケージは完成していますし、できるだけ早めに使い始めてもらいたいということで、会社に許可を得てこのblogで先行してテスト版パッケージを公開できることになりました。

とりあえずRHEL/CentOS向けのRPMのみですが、準備ができ次第Debianパッケージも公開しようと思います。また、テスト版と言っているのはまだGPG署名が入っていないからで、パッケージ構成や基本的な部分はリリース版と変わらないと思います。何か問題や提案があればこのblogにコメントいただくか、Twitterの@kodai74までご連絡ください。

多言語に対応しなければいけないので、これまであったFedora, EPEL, ZABBIX-JPなどのパッケージとは構成が多少異なります。インストールは以下の方法を参考にしてください。

RPMファイル一式のダウンロード

~~こちら~~(Zabbix SIAからオフィシャルリポジトリが公開されました。yum/aptリポジトリを利用する方法はこちらを参照してください。)から適切なOS, アーキテクチャのものをダウンロードしてください。Zabbix関連のパッケージはzabbixディレクトリ以下に、Zabbixの動作に必要な関連パッケージはnon-supportedディレクトリ以下に置いてあります。

Zabbixサーバ, Webインターフェース、Zabbixエージェントのインストール

先に必要となるパッケージをインストールします。まずはOSの標準リポジトリから必要なものをインストール

# yum install mysql-server curl net-snmp unixODBC OpenIPMI-libs httpd php php-bcmath php-gd php-mbstring php-mysql php-xml ipa-pgothic-fonts

※RHEL6系の場合はipa-pgothic-fontsの代わりにvlgothic-p-fontsをインストールしてください

次に上記URLからダウンロードした以下のRPMをインストールします。

# rpm -ivh fping-2.4b2-16xxx.rpm \
           iksemel-1.4-2.xxx.rpm \
           libssh2-1.4.0-2xxx.rpm

最後にZabbix関連のパッケージをインストールします。下記はデータベースとしてMySQLを利用する場合です。

# rpm -ivh zabbix-2.0.0-1.xxx.rpm \
           zabbix-agent-2.0.0-1.xxx.rpm \
           zabbix-server-2.0.0-1.xxx.rpm \
           zabbix-server-mysql-2.0.0-1.xxx.rpm \
           zabbix-web-2.0.0-1.xxx.rpm \
           zabbix-web-mysql-2.0.0-1.xxx.rpm \
           zabbix-web-japanese-2.0.0-1.xxx.rpm

zabbix-web-japaneseパッケージがWebインターフェースの日本語フォント設定を行うようになっているので、日本語環境ではこのパッケージを入れないとグラフやマップなどで文字化けが発生します。

インストールが完了したら、続いて初期設定を行います。

データベースの設定と初期データのインポート

初めてMySQLを起動する場合、起動前に/etc/my.cnfには最低限以下のチューニング設定を行っておきましょう。

[mysqld]
...

innodb_file_per_table
innodb_buffer_pool_size=512M # 搭載メモリによって適切な値を設定
innodb_log_file_size=64M  # innodb_buffer_pool_sizeを増やしたらこちらも増やしておく

...
[mysqld_safe]

データベースがZabbix専用であれば、同じく[mysqld]セクションに以下の設定も入れておくとMySQLサーバ全体でエンコードをUTF-8にできるのでトラブルが少なくなると思います。

default-character-set=utf8

MySQLを起動して、データベースの作成とユーザの作成、初期データの登録を行います。ここではデータベース名は「zabbix」、接続ユーザ名も「zabbix」、パスワードは「zabbixpass」で設定しています。

# service mysqld start
# mysql -uroot
mysql> create database zabbix character set utf8;
mysql> grant all privileges on zabbix.* to zabbix@localhost identified by 'zabbixpass';
mysql> exit
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.0/create/schema.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.0/create/images.sql
# mysql -uroot zabbix < /usr/share/doc/zabbix-server-mysql-2.0.0/create/data.sql

my.cnfでdefault-character-setを設定していない場合は、データベース作成時のcharacter setの指定を忘れないようにしてください。忘れるとWebインターフェース上で一部の日本語が文字化けします。

Zabbixサーバとエージェントの設定

/etc/zabbix/zabbix_server.confの以下の箇所を変更します。

DBPassword=zabbixpass

Zabbixエージェントはデフォルト設定のままで問題ありません。ここまでできたらZabbixサーバとエージェントを起動します。

# service zabbix-server start
# service zabbix-agent start

Webインターフェースの設定

/etc/httpd/conf.d/zabbix.confのdate.timezone設定のコメントアウトを外し、以下のように設定します。

php_value date.timezone Asia/Tokyo

httpdを起動します。すでにhttpdが起動していた場合は、上記設定を反映させるためにhttpdを再起動してください。

# service httpd start

ブラウザからWebインターフェースにアクセスします。サーバのIPが192.168.1.10の場合はhttp://192.168.1.10/zabbixのように/zabbixをつけてアクセスしてください。

インストーラが表示されるので、画面の通りに従っていけば問題なく完了するはずです。途中データベースの設定を入力する必要がありますが、ここは上記のMySQL設定の値を入力します。

ちなみに、2.0はインストーラ画面もカッコ良くなっています。

Webインターフェースへのログインと日本語化

Webインストーラが完了したらログインが面が表示されますので、ユーザ名に「Admin」、パスワードに「zabbix」と入力してログインしてください。

最初の画面は英語ですが、右上の「Profile」をクリックして、

Language設定でJapanese(ja_JP)を選択してSaveボタンを押せば、インターフェースが日本語で表示されるようになります。

ローカルホストの監視

設定に問題がなければ、すでに監視が始められる状態になっています。上部メニューの[設定]-[ホスト]をクリックして、ホストリストの「Zabbix server」の「無効」をクリックして有効化するとローカルホストの監視が開始されます。

収集されたデータはメニューの[監視データ]-[最新データ]から確認することができます。

この画面からリストの右にある「グラフ」をクリックすることでグラフを表示することもできます。インターフェースには色々な画面があるので、Zabbix 2.0でどのようなことができるのか、ぜひ一度インストールして試してみてください。

Zabbix SIAのサイトにはZabbix 2.0のその他のページのスクリーンショットも公開されています。こちらもご参考にどうぞ。

Zabbix 2.0がリリースされました

2012-05-28T18:40:00.000+09:00

2012/05/21、ついにZabbix 2.0がリリースされました(Zabbix 2.0リリースのスペシャルニュースレター)。1.8から2年6ヶ月、2.0のリリースはいつになるのかという質問をたくさん頂いたので、リリースを待たれていた方も多くいらっしゃるのではと思います。

2.0の主な機能はZabbix SIAのサイトにまとまっているので、ここでは改めて解説はしません。必要に応じて以下のページを参考にして戴ければと思います。(ドキュメントは未翻訳です)

その他には、以下の記事、資料などが参考になると思います。

第4回 ZABBIX-JP勉強会「ラトビアの生活とZabbix 2.0 & カンファレンスの話」
クラウドコンピューティングEXPO「オープンソース統合監視ソフトウェア Zabbix 2.0によるクラウド監視」
第5回 ZABBIX-JP勉強会「Zabbix 2.0 新機能レビュー： snmp-trap 監視をGW中に機能評価してみる」
ThinkITの記事「さらなる進化を続けるZabbix ～2.0へのバージョンアップ～」

今回、1.8から2.0までの間に2年半もかかってしまった理由としては、1.8で新機能を追加してしまったことでその追加機能の開発工数やバグフィックスなどで時間が割かれてしまい、2.0の開発に時間が割けなかったからだ、とAlexeiは言っているのですが、個人的には以下の要因もあると思っています。

1.8から大規模なシステムでZabbixが使われ始めていて、パフォーマンス改善のための修正なども多くなってきていること
2.0ではWebインターフェースの一部分を根本的に入れ替えていること。特にJavaScriptのライブラリをprototype.jsからjQueryに変更や、インターフェース翻訳にgettextを使うなど
2.0では多数の新機能が追加されていること

Zabbixサーバやエージェントのコードは早いうちから安定していたものの、Webインターフェースはリリース直前まで修正が行われてたように思います。

第5回 ZABBIX-JP勉強会でAlexeiも話していたのですが、2010年の初めに「2010年の9月に2.0をリリースする。リリースできなければ帽子を食べる(日本で言うと針千本を飲むという感じです)」と話していたものが、同じことをあと2回(2010年9月、2011年5月)言っているので、そのくらい予定から遅れていた、ということになります。

2.0がリリースされたとき(私は日本にいたので参加していないのですが)、Zabbixのオフィスで2.0のリリースパーティでAlexeiが帽子を食べましたという記事があるので、こちらもどうぞ。

Zabbix社では次の2.2に向けての開発がすでに始まっています。クラウドコンピューティングEXPOのセミナーでも発表したのですが、2.0以降は以下のリリースポリシーに変更されます。

9ヶ月ごとにメジャーバージョンをリリース
マイナーバージョンではバグフィックスのみ。仕様変更や新機能の追加は行わない

9ヶ月ごとにメジャーバージョンがリリースされることで、新しい機能をより早く使うことができます。ただ、これまで1.8のマイナーバージョンでも仕様変更をともなうバグでも修正が行われてましたが、2.0以降は次のメジャーバージョンを待つことになる場合もあると思います。必要な機能修正/追加要望は早めにお願いします。

また、上記Alexeiの資料にもありますが、Zabbixでは2.0以降の開発の方向性としては以下のことを考えています。

より高品質なソフトウェアをリリースするための取り組み
WebインターフェースにMVCモデルを
Webインターフェースをよりユーザーフレンドリーに
プラグインアーキテクチャ
HAや冗長化を含む水平方向のスケーラビリティ

近日中に2.2のロードマップを公開予定なので、こちらも期待頂ければと思います。

Zabbix 2.0のソースコードはZabbix SIAのダウンロードページからダウンロード可能です。

第5回 ZABBIX-JP勉強会を開催しました

2012-05-27T20:14:00.001+09:00

2012/05/12(土)にフューチャーアーキテクトさんの大崎オフィスで第5回 ZABBIX-JP勉強会を開催しました。

今回は今までにZABBIX-JP単独で開いた勉強会としては最大の170名の申し込みということで、当日どの程度の参加者が集まるのかや、懇親会の費用や食事の用意など手探りのところが多かったのですが、なんとか無事終えることができました。

開場前の受付の様子

本編開始直後の様子

また、今回はZabbixのお菓子と、ラトビアの有名なお菓子メーカーのLaimaさんからいただいたチョコレートを無料配布しました。

LaimaさんからいただいたチョコレートはZabbixへのスポンサーという形で無償でいただいたものなので、おいしかったよ！という人はぜひ、LaimaのTwitterアカウントに英語でThanksと言っていただくか、Facebookのアカウントでいいね！ボタンを押してあげてください。

最終的に本編は115人の方に参加いただきました。当日の発表の様子はUstreamでも公開しているので、当日来れなかった方はぜひ録画をご覧ください。

そのあとは1つ下の階に移動して懇親会も行いました。懇親会は61名の参加ということで、当初予想していたよりもかなり多くの方に参加いただきました。用意した食事と飲み物が足りず、何度もコンビニまで往復いただいたスタッフの方々、どうもありがとうございました！

懇親会のLTの様子

懇親会では@udaotokoさんがなんとこの日のためにZabbix銘菓を作ってきていただいていました。最終的には売り切れになってしまい大盛況ということで、こちらも持って行かれた方は@udaotokoさんに一言コメント頂ければと思います。

当日のアジェンダや資料などはZABBIX-JPのイベントページにまとめてあるので、見逃したという方や、発表資料を再度見たいという方はこちらからアクセス頂ければと思います。

今回は私も他のイベントの準備で気が回らなかったこともあり、本編の時間が遅れてしまったりとか、懇親会の準備に不足があったりなど反省すべき点は多かったのですが、反省点は次回に生かしたいと思います。

当日、会場の貸し出しや設営準備、買い出しなどを手伝っていただいたフーチャーアーキテクトの方々、それから登壇いただいた方々、どうもありがとうございました！ZABBIX-JPスタッフのみなさんもお疲れさまでした！。また次回、勉強会を開催できることを楽しみにしています。

Zabbixがうまく動かないときに参考になる情報

2012-03-25T05:57:00.000+09:00

Zabbixがうまく動かない！というときに原因を調べる方法や参考になるサイトや資料、本家にバグ報告を行う方法までをまとめてみました。こういった情報はあまりまとまったものがないので、思ったように動かない、パフォーマンスが出ない、他の人はどうしてるんだろう？、バグのような気がするんだけど…という時に参考にして頂ければと思います。

Googleなどを使ってネットを検索する

オープンソースのソフトウェアの場合は最も一般的な方法です。IT系のサイトの記事や個人のブログなどで問題の解決方法が書かれている場合もあるので、うまく検索にヒットする場合は解決策が見つかる可能性が高いと思います。

ただ、Zabbixの場合はZabbix SIAやZABBIX-JPのサイトに情報が集中していると思います。Googleなどで検索をかけるよりも、各サイトのフォーラムやドキュメントなどを見る方が効率的な場合も多いです。

ドキュメントを読む

監視の設定が合っているかどうか分からない、というような場合はまずドキュメントを見てみましょう。Zabbixの公式ドキュメントは以下のURLで公開されています。

英語版は日々更新されていますので、以前見つからなかった場合でも改善されている可能性もあります。日本語版は後から追随する形になるので、日本語版になくても英語版には記載がある可能性もあります。

英語のドキュメントは…という人も、勉強だと思って根気よく読んでみることをお勧めします。オープンソースソフトウェアを利用するには、英語のドキュメントに慣れることは重要です。

フォーラムとサポートシステムの投稿を検索する

英語、日本語ともにコミュニティのフォーラムには活発に投稿があるので、フォーラムを検索することで同じ問題を抱える人やその回答が見つかるかもしれません。

また、Zabbix SIAにはサポートシステムがあり、バグ報告や新機能の追加要望などはこちらで管理されています。

Zabbixサポートシステム

アカウントの作成は自由にできますので、気になるバグ報告があればログインしてウォッチしておくことで更新時にメールを受け取ることができます。

また、サポートシステムで重要だと思うバグ報告や、欲しいと思う機能改善/追加要望があればぜひVote(投票)をしておいてください。投票の数が多いほど実現の可能性が高くなります。

書籍を参考にする

手前味噌ですが、Zabbixの書籍を執筆しています。こちらにも参考になる情報を記載していますので、試しに書店で手に取ってみて頂ければと思います。

Amazon.co.jp: Zabbix統合監視「実践」入門

ログをじっくり見る

基本中の基本ではあるのですが、ソフトウェアのログは英語で出力されることがほとんどなので、意外と見落としがちです。

コンパイル時の問題であればコンパイルのログにエラーが出力されます。人によっては意味不明なエラーに見えるかもしれませんが、前後のログも含めて少しじっくり見てみてください。意外と重要なエラーを見落としていることもよくあります。エラーメッセージでネット検索をかけてみるのも良い方法です。

Zabbixの監視設定でつまづいた時も、ZabbixサーバやZabbixエージェントのログを確認してみてください。Zabbixの場合、監視設定がWebインターフェースなので忘れがちですが、実際に監視の処理を行っているのはOS上のプロセスなので、ログに重要なエラーが出力されているかもしれません。

ちなみに、Zabbixに関連のあるログは以下の4つです。

Zabbixサーバのログ: /var/log/zabbix/zabbix_server.log
Zabbixエージェントのログ: /var/log/zabbix/zabbix_agentd.log
Zabbixプロキシサーバのログ: /var/log/zabbix/zabbix/_proxy.log
Webインターフェース関連のログ: /var/log/httpd/error.log

フォーラムに投稿する

フォーラムで同じ投稿が見つからなければ、質問を投稿してみるのもコミュニティへの参加の1つです。その際、以下のことに気をつけて投稿すると良い回答をもらえる可能性が高いと思います。

同じ質問がすでに投稿されていないか、まずは検索してみる。
利用しているZabbixのバージョンや、問題が発生する設定の内容、必要な場合は利用しているOSや環境の説明を書くこと。回答する人はすべての環境やパターンを知っているわけではありません。
まずは自分で試してみた上で、その結果、問題が出ている箇所を質問すること。可能性があるすべてのことを回答するのは手間がかかりますし、場合によっては非現実的です。

公開フォーラムで質問をするということは、同じ問題に遭遇した人の助けになるということでもあります。他の人の参考になることも考えて、具体的に状況を書いた方が良いです。また、フォーラムの支援を受けて最終的に解決したかどうか、そのときの設定や解決方法なども投稿すれば、それは他のユーザの有用な情報になります。

デバッグログを出力する

Zabbixはデバッグログを出力できるようになっています。Zabbixエージェント、サーバ、プロキシサーバの各プロセスは、設定ファイルで以下のように設定して再起動するとでバッグログを出力できます。

DebugLevel=4

内部で実行している関数の実行状況や、重要な変数のデータ、実行しているSQLクエリなどがログに出力されるようになり、デバッグログを参照することでどこで問題が発生しているかを特定できる可能性があります。

Webインターフェースでも以下の手順でデバッグログを出力できます。

ユーザーグループの設定でデバッグモードを有効にする
デバッグモードを有効にしたユーザーグループに所属するユーザーでログイン
右上の「デバッグ」のリンクをクリック

すると、今表示している画面を出力する際にかかった時間や利用したメモリ容量、実行したSQLと要した時間などが表示できます。Webインターフェスのパフォーマンスが悪いといった場合に有用な情報を得ることができます

ソースコードを読む

オープンソースであることの一番のメリットは、誰でもソースコードを読めることです。当然ですが、ソフトウェアはソースコード以外のものからは出来ていないので、問題解決にあたってソースコードを読まない手はないと思います。

ログやデバッグログなどである程度問題個所の特定ができれば、ソースコードを調べればソフトウェアそのものが原因なのか、それとも外部の要因(環境依存、利用しているライブラリの問題)なのかが明確に分かります。内部の動きを知ることで、より深くZabbixを理解することもできますので、問題の調査のときは参照してみると良いと思います。

一般的にオープンソースのソフトウェアに仕様書はありません。だいたいの場合、定められたコーディングルールに沿って実現する機能を実装し、途中でレビューを入れながら細かく修正を入れていく、というスタイルだと思いますし、Zabbixもそのように開発されています。ドキュメントは出来上がったソフトウェアの動きをベースに作成されています。

つまりは今あるソースコードが仕様書なわけで、最新のドキュメントであり、それが全てです。ソースコードを読めるかどうかはオープンソースソフトウェアを利用する上で、問題解析にあたって大きな差が出てくると思います。

バグ報告や機能改善要望を送る

オープンソースソフトウェアというのはバグ出しや機能改善要望をユーザーと一緒にやっていくところに面白さがあると思いますし、そのプロセスがとても重要だと思います。開発側はユーザーからのフイードバックをダイレクトに受けられますし、ユーザー側は開発に協力したり、リクエストを出してそのフィードバックがすぐに受けることができます。

マニュアルを見た、ログも確認した、コミュニティフォーラムにも解決方法はない、だけど、どうにも動きがおかしい。というときはバグの第一発見者である可能性があります。可能であればデバッグログを出してみたり、ソースを読んでみるとバグかどうか確実性が高まると思います。

多分これはバグだ！となれば、ぜひZabbix SIAにバグ報告をしてみましょう。誰かがバグ報告をしなければその問題は永遠に直らないかもしれませんし、バグ報告できるのは第一発見者の特権です。パッチを付けて取り込まれた場合はリリースノートに名前を載せてもらえます。

Zabbix SIAへのバグ報告は上にも書いたサポートシステムから行います。サポートシステムへの投稿は必ず英語でお願いします。これは投稿の文章もそうですが、スクリーンショットを取るときの画面の言語、ログに含まれる言語などにも注意してください。ちなみに日本語はダメですが、ラトビア語かロシア語なら大丈夫です。

Zabbixサポートシステム

バグ報告の場合はZABBIX BUGS AND ISSUES(ZBX)に、新規機能追加要望の場合はZABBIX FEATURE REQUESTS(ZBXNEXT)に投稿します。

バグ報告するときは、上の「フォーラムに投稿するときの注意点」と同様のことに注意することと、加えて以下のことにも注意しておくと良いです。

問題の内容を簡潔に書く。(1)どのような環境/操作/設定のときに、(2)どのような動作をする。(3)どのような点が問題で、(4)どのようにするのが良いか。といった形で書くのが良いと思います。箇条書きで良いので簡潔に、分かりやすく。
ある程度の大きさのパッチを作成する場合、Zabbixのコーディングルールに従うようにする
仕様が大きく変わるようなパッチの作成はできるだけ避ける
どうしても仕様が変わらざるを得ない問題の場合、説明をより詳細に書いてディスカッションする

基本的に、他の部分にも影響が出るようなパッチは簡単には取り込まれませんし、取り込まれるとしても時間がかかります。大きな修正を取り込む場合、他に良い修正方法がないか検討する必要も出てきますし、他の機能への影響やテストも必要になります。大きめのパッチを投稿するような場合は、ディスカッションをより重視した方が良いです。

Zabbix SIAのエンジニアとコミュニケーションを取る

バグ報告するにあたってコミュニケーションも重要と書きましたが、Zabbix SIAのエンジニアと直接コミュニケーションを取るにあたり、一番リアルタイムにレスポンスがもらえるのはIRCでチャットすることです。

Zabbixの公式IRCチャネルがfreenodeサーバのzabbixグループにあり、誰でも参加できます。常に100人程度のユーザが参加していますし、Zabbix SIAの開発者や世界中のアクティブなZabbixコミュニティメンバーが集まっています。

発言しなくても参加してみるだけでも有益な情報が得られて面白いと思います。あまり発言は多くないですが、私も昼間は基本的にログインしています。

バグ報告/機能追加要望をしてみたい！という人に

Zabbix SIAに直接バグ報告や機能追加要望をしてみたい、けど自信が無い、という場合は以下の方法で誰か詳しい人にコンタクトを取ってみてください。Zabbixのコミュニティは親切な人が多いので、誰かが手助けしてくれると思います。

ZABBIX-JPフォーラムに投稿する
Twitterで#zabbixまたは#zabbix_jpハッシュタグをつけてつぶやく
Twitterで私の個人アカウント@kodai74、もしくはZabbix SIA公式日本語アカウント@zabbix_jpに聞いてみる

IRCで私にダイレクトメッセージを送ってもらっても構いません。バグ報告やパッチ投稿の手助けも何かしらできると思いますので気軽にご連絡ください。

「Zabbixのバグを見つけたけど、誰かがバグ報告して修正されるまで待っていよう」というよりは、小さなものでも、パッチがなくても良いので開発元に報告することがオープンソースの活動への参加と貢献につながると思います。

Zabbix SIAが仮想環境の監視機能のスポンサーシップを募集

2012-03-05T19:06:00.001+09:00

この記事はZabbix SIAのblogの翻訳です。原文はDevelopent sponsorship of VM environment supportを参照ください。

現行バージョンのZabbixでも仮想化環境の監視を行うことは可能ですが、そのためには監視のための設定に時間がかかり、Zabbixと統合されたものにはなりません。

現在、VMware, Xen, KVM (可能であれば他の仮想環境も)に対応し、ハイパーバイザーとゲストOSの双方のステータスを簡単に監視できる、より統合された仮想環境の監視機能の開発を検討しています。

現在の一般的なアプローチはZabbixエージェントを各ゲストOSにインストールして監視する方法です。これは仮想環境特有のステータスやハイパーバイザーレベルのステータスを監視することが難しく、外部チェックやユーザパラメーター、Zabbix senderを利用する必要があります。この方法は悪くはありませんが、Zabbixのネイティブな監視方法ではありませんし、大規模なシステムではパフォーマンスが悪くなる場合があります。

検討を行っている機能には以下のものが含まれます:

VMware, Xen, KVMをサポート
ハイパーバイザーのAPIを利用して、ハイパーバイザー自体とゲストOSのステータスを監視
ZabbixのフロントエンドからゲストOSの管理

しかしながら、よりパワフルで簡単に監視できるような機能を実装するための支援が必要です。もし仮想環境の監視機能の開発のスポンサーシップに興味のある会社をご存知でしたら、ぜひ教えてください。

すでに数社がこのスポンサーシップに興味を持って頂いていますが、この機能を2.2で実装するためにはより多くの支援が必要です。スポンサーシップ企業には以下のメリットがあります。

仕様策定への参加
開発状況の通知と共有
開発バージョンの早期テスト
実装された機能へのフィードバックと議論
共同マーケティングの機会

もしスポンサーシップへ興味を持って頂けたら、sales /at/ zabbix /dot/ comへメールを送付いただくか、問い合わせフォームからご連絡ください。より詳細なプランをお送りします。

日本の企業向けには日本語で対応も可能です。興味のある企業様はぜひご連絡ください！

Zabbixのlog[]とlogrt[]キーの動作

2012-02-15T19:24:00.000+09:00

Zabbixにはログ監視用のアイテムとしてlog[]とlogrt[]キーがあります。ともにテキストベースのログファイルを監視し、1行を1データとしてZabbixサーバに送付、文字列マッチを行って障害判定をすることができます。

これらのキーを使ったときに、Zabbix内部ではどのような動作をしているのかというのが見えにくいですし、ログ関係はZABBIX-JPのフォーラムでもよく質問があります。私自身、質問を受けるたびに何度もソースコードを調べている気がするので、一度まとめておこうと思います。

解説に利用しているソースコードは1.8.10です。間違っていたらコメントでご指摘いただけると助かります。

log[]キーの動き

log[]キーはZabbix 1.1から追加されれいるログ監視用のキーです。1.6まではログ監視をするにはこのキーを利用する以外の手段はありませんでした。アイテムのキーには以下のように実際に監視するファイル名をそのままオプションに設定します。

log[file_path,regexp,encoding,maxlines]

regexp以降は1.8で追加されたオプションです。単純にファイルを監視するだけであれば、以下のように設定できます。

log[/var/log/messages]

logキーの処理はソースコードのsrc/zabbix_agent/logfiles.cの598行目から始まるprocess_log()関数で定義されています。

/* handling of file shrinking */
if (0 != zbx_stat(filename, &buf))
{
    zabbix_log(LOG_LEVEL_WARNING, "cannot stat [%s]: %s", filename, zbx_strerror(errno));
    return ret;
}

ここでファイルをの状態を取得し、

if (buf.st_size < *lastlogsize)
    *lastlogsize = 0;

ここでファイルのサイズがlastlogsizeよりも小さければ、lastlogsizeを0に設定しています。

lastlogsizeというのはログファイルをどこまで読んだかを記録しておく変数で、つまり、前回読んだバイト数よりもファイルが小さくなっていれば、ファイルが新規作成もしくはローテートされたと判断して、ファイルを先頭から読みにいくようになっています。

if (-1 == (f = zbx_open(filename, O_RDONLY)))
{
    zabbix_log(LOG_LEVEL_WARNING, "cannot open [%s]: %s", filename, zbx_strerror(errno));
    return ret;
}

ファイルをREADONLYでオープンし、

if ((off_t)-1 != lseek(f, (off_t)*lastlogsize, SEEK_SET))
{
    if (-1 != (nbytes = zbx_read(f, buffer, sizeof(buffer), encoding)))
    {
        if (0 != nbytes)
        {
            *lastlogsize += nbytes;
            *value = convert_to_utf8(buffer, nbytes, encoding);
            zbx_rtrim(*value, "\r\n ");
        }
        ret = SUCCEED;
    }
    else
        zabbix_log(LOG_LEVEL_WARNING, "cannot read from [%s]: %s", filename, zbx_strerror(errno));
}
else
    zabbix_log(LOG_LEVEL_WARNING, "cannot set position to [%li] for [%s]: %s", *lastlogsize, filename, zbx_strerror(errno));

close(f);

lastlogsize以降の文字列をutf8に変換しながら読み込み、読んだバイト分lastlogsizeを増加させ、ファイルをクローズしています。このときbufferのサイズはMAX_BUFFER_LENで定義されている65536B=64KBなので、それを超えない行末までを1度に読み込んでいます。

ここでvalueに読み込まれた文字列とlastvalueの値は最終的にソースのsrc/zabbix_agent/active.cの753行目あたりからの処理

while (SUCCEED == (ret = process_log(filename, &lastlogsize, &value, encoding)))
{
    if (NULL == value) /* End of file. The file could become empty, must save `lastlogsize'. */
    {
        active_metrics[i].lastlogsize = lastlogsize;
        break;
    }

    if (SUCCEED == regexp_match_ex(regexps, regexps_num, value, pattern, ZBX_CASE_SENSITIVE))
    {
        send_err = process_value(server, port, CONFIG_HOSTNAME,
                active_metrics[i].key_orig, value, &lastlogsize,
                NULL, NULL, NULL, NULL, NULL, 1);
        s_count++;
    }
    p_count++;

    zbx_free(value);

    if (SUCCEED == send_err)
        active_metrics[i].lastlogsize = lastlogsize;
    else
    { /* buffer is full, stop processing active checks till the buffer is cleared */
        lastlogsize = active_metrics[i].lastlogsize;
        goto ret;
    }

    /* do not flood Zabbix server if file grows too fast */
    if (s_count >= (maxlines_persec * active_metrics[i].refresh))
        break;

    /* do not flood local system if file grows too fast */
    if (p_count >= (4 * maxlines_persec * active_metrics[i].refresh))
        break;
} /* while processing a log */

でvalueの値はprocess_value()関数に処理され、lastvalueの値はactive_metrics配列にセットされています。active_metrics配列にはZabbixサーバから取得したアクティブチェックのアイテム設定が入っています。これらの値は最終的にZabbixサーバに送付され処理されます。

このwhile部分は1回の監視処理で1度呼ばれ、gotoまたはbreakが呼ばれるまで繰り返しprocess_log()関数を実行して64KBづつファイルを読んでいます。

ループを抜ける条件としては、

ログファイルの末尾まで読む
Zabbixエージェントのバッファ(Zabbixサーバに送信前のデータを溜めておくもの)が一杯になる
s_count(Zabbixサーバに送付する行数)がmaxlinex_persec * アイテムの監視間隔(秒)に達する
p_count(読み込んだログの行数)が4 * maxlinex_persec * アイテムの監視間隔(秒)に達する

のいずれかです。ログの途中で終了した場合は次の監視の時に続きから読みます。

maxlines_persecはlog[]キーのmaxlinesパラメータで指定された値か、zabbix_agentd.confのMaxLinesPerSecondパラメータで指定された値を使用します。

logrt[]キーの動き

logrt[]キーはローテーションをするログファイルを監視するためのキーで、1.8から新しく追加されています。アイテムのキーには以下のように設定します。

logrt[file_format,regexp,encoding,maxlines]

log[]キーと異なるのはファイル指定部分に正規表現が利用できる点です。例えば以下のように指定します。

logrt[/var/log/messages.*]

logrt[]キーの動作としてはフォルダを探索し、マッチするファイルを抜き出し、監視すべきファイルを選定してからファイルを読みます。この処理が入るためlog[]キーよりは動作が複雑です。それ以外はlog[]キーとほぼ同じ動作をしますので、ここではファイルの選択ロジックについてのみ解説します。

ちなみに、ファイル名部分に利用できるのは正規表現です。正規表現をシェルのワイルドカードと誤解している人をよく見かけます。正規表現で*は「直前の文字の0回以上の繰り返し」なので、間違えると思いがけないファイルまで読んでしまう場合があるので注意してください。

logrtキーの処理はソースコードのsrc/zabbix_agent/logfiles.cの366行目から始まるprocess_logrt()関数で定義されています。Windowsとそれ以外で処理が分かれているので、ここではWindows部分の解説は飛ばします。

/* splitting filename */
if (SUCCEED != split_filename(filename, &directory, &format))
{
    zabbix_log(LOG_LEVEL_WARNING, "filename [%s] does not contain a valid directory and/or format", filename);
    return FAIL;
}

ここで指定されたパスをディレクトリとファイル名に分けて、

if (NULL == (dir = opendir(directory)))
{
    zabbix_log(LOG_LEVEL_WARNING, "cannot open directory [%s] for reading: %s", directory, zbx_strerror(errno));
    zbx_free(directory);
    zbx_free(format);
    return FAIL;
}

ディレクトリをオープン

while (NULL != (d_ent = readdir(dir)))
{
    logfile_candidate = zbx_dsprintf(logfile_candidate, "%s%s", directory, d_ent->d_name);

    if (-1 == zbx_stat(logfile_candidate, &file_buf) || !S_ISREG(file_buf.st_mode))
    {
        zabbix_log(LOG_LEVEL_DEBUG, "cannot process read entry [%s]", logfile_candidate);
    }
    else if (NULL != zbx_regexp_match(d_ent->d_name, format, &length))
    {
        zabbix_log(LOG_LEVEL_DEBUG, "adding the file [%s] to logfiles", logfile_candidate);
        add_logfile(&logfiles, &logfiles_alloc, &logfiles_num, d_ent->d_name, (int)file_buf.st_mtime);
    }
    else
        zabbix_log(LOG_LEVEL_DEBUG, "[%s] does not match [%s]", logfile_candidate, format);

    zbx_free(logfile_candidate);
}

ディレクトリにあるファイルから、指定された正規表現にマッチするファイルを探してlogfiles配列に追加しています。

途中にあるadd_logfile()関数でlogfiles配列への追加処理を行っているのですが、この関数内は

ファイルのmtime(ファイルの更新日時)が古い順
mtimeが同じ場合はアルファベット/数字の降順(z->a, 9->0)

に並ぶように処理されています。

/* find the oldest file that match */
for (i = 0; i < logfiles_num; i++)
{
    if (logfiles[i].mtime < *mtime)
        continue;   /* not interested in mtimes less than the given mtime */
    else
        break;  /* the first occurrence is found */
}

ここで*mtimeとなっているのは、前回ログを読み込んだ際に記憶しておいたmtimeです。つまり、logfiles配列にあるログファイルのmtimeと前回読んだファイルのmtimeを比較して、最初に見つけた「前回よりもmtimeが新しいファイル」のインデックスが変数iに入ります。logfiles配列の先頭から読んでいるので、配列の順番が重要です。

/* escaping those with the same mtime, taking the latest one (without exceptions!) */
for (j = i + 1; j < logfiles_num; j++)
{
    if (logfiles[j].mtime == logfiles[i].mtime)
        i = j;  /* moving to the newer one */
    else
        break;  /* all next mtimes are bigger */
}

ここでは先ほど見つけたmtimeが新しいログファイルを基準に、それよりもlogfiles配列の後ろにあるファイルを探索してmtimeを比較しています。mtimeが同じファイルがあれば、より配列の後ろにあるファイルが選択されます。(実際にはインデックスが変数iに入る)

/* if all mtimes are less than the given one, take the latest file from existing ones */
if (0 < logfiles_num && i == logfiles_num)
    i = logfiles_num - 1;   /* i cannot be bigger than logfiles_num */

最終的にインデックスiが配列の最後まで行ってしまった場合は、logfiles配列の一番後ろのログファイルが選択されます。

ここから実際にログファイルを読む部分です。少し長いですがそのまま貼付けます。

/* processing matched or moving to the newer one and repeating the cycle */
for ( ; i < logfiles_num; i++)
{
    logfile_candidate = zbx_dsprintf(logfile_candidate, "%s%s", directory, logfiles[i].filename);
    if (0 != zbx_stat(logfile_candidate, &file_buf))/* situation could have changed */
    {
        zabbix_log(LOG_LEVEL_WARNING, "cannot stat [%s]: %s", logfile_candidate, zbx_strerror(errno));
        break;  /* must return, situation could have changed */
    }

    *mtime = (int)file_buf.st_mtime;    /* must contain the latest mtime as possible */
    if (file_buf.st_size < *lastlogsize)
    {
        *lastlogsize = 0;   /* maintain backward compatibility */
    }

    if (-1 == (fd = zbx_open(logfile_candidate, O_RDONLY)))
    {
        zabbix_log(LOG_LEVEL_WARNING, "cannot open [%s]: %s", logfile_candidate, zbx_strerror(errno));
        break;  /* must return, situation could have changed */
    }

    if ((off_t)-1 != lseek(fd, (off_t)*lastlogsize, SEEK_SET))
    {
        if (-1 != (nbytes = zbx_read(fd, buffer, sizeof(buffer), encoding)))
        {
            if (0 != nbytes)
            {
                *lastlogsize += nbytes;
                *value = convert_to_utf8(buffer, nbytes, encoding);
                zbx_rtrim(*value, "\r\n ");
                ret = SUCCEED;
                break;  /* return at this point */
            }
            else    /* EOF is reached, but there can be other files to try reading from */
            {
                if (i == logfiles_num - 1)
                {
                    ret = SUCCEED;  /* EOF of the the most current file is reached */
                    break;
                }
                else
                {
                    zbx_free(logfile_candidate);
                    *lastlogsize = 0;
                    close(fd);
                    continue;   /* try to read from more current file */
                }
            }
        }
        else    /* cannot read from the file */
        {
            zabbix_log(LOG_LEVEL_WARNING, "cannot read from [%s]: %s",
                    logfile_candidate, zbx_strerror(errno));
            break;  /* must return, situation could have changed */
        }
    }
    else    /* cannot position in the file */
    {
        zabbix_log(LOG_LEVEL_WARNING, "cannot set position to [%li] for [%s]: %s",
                *lastlogsize, logfile_candidate, zbx_strerror(errno));
        break;  /* must return, situation could have changed */
    }
}   /* trying to read from logfiles */

forループ内でここまでで決めたインデックスiを使って、logfiles[i]以降にあるログファイル全てを読みにいこうとしています。つまり、ログローテーションしてmessagesがmessages.1になった場合、先にmessages.1の残りの部分を読んでから、新しいmessagesファイルを読みに行こうとします。

その後にあるファイル情報の取得、lastlogsizeの処理、64KBづつログファイルを読み込んでutf8変換などの処理はlog[]キーと同様です。少し異なるのは、ファイルのmtimeを変数に保存しておいたり、ファイルの末尾まで読んだときにlogfiles配列に次のファイルが残っていたら、続けて次のファイルを先頭から(lastlogsize=0)読もうとする点です。

valueに読み込まれた文字、lastlogsizeの値の処理はlog[]キーと同様に処理されます。logrt[]の場合はmtimeもlastlogsizeと同様にactive_metrics配列に保存されます。

ラトビアでスノーボードに行ってきました

2012-02-12T05:46:00.000+09:00

会社の人に誘われて、ラトビアでスノーボードに行ってきました。

行ってきたのはリガから80キロほど離れたCēsisという街の近くにあるŽagarkalnsというスキー場です。ほかにもリガから50キロほど離れたSiguldaにもスキー場があるらしいのですが、スノーボードにはŽagarkalnsの方が良いんだそうです。

先週末が一番寒い時期だったようで、リガでも最低気温が-30度近くまで下がりました。今週は寒くても-20度くらい、昼間は-10度くらいになるので一時期よりは暖かくなりましたが、それでも寒いことには変わらないです。Cēsisは少し内陸部にあるので、リガよりは少し寒くなります。

スキー場の木もとても寒そうなことになっています。

スキー場はそれなりに混雑していました。スキーヤーの方が多く、スキーとスノーボードの割合が7:3くらいの割合でしょうか。

到着したのが昼の1時過ぎくらいと遅めだったこともあってか、スノーボードの板は借りれたもののウェアを借りることができず、普段着のまま滑ることになってしまいました。ウェアは数が少ないので借りれないかもしれない、と前日に聞いてはいたので覚悟はしていたのですが、転ばないように気をつけながらになるので、あまり思い切りすべれないのが残念です。

ちなみに、ラトビアは日本と違って山がありません。一番標高の高いところで海抜300mくらいなんだそうです。300mといえば東京タワーと同じくらいですね。

なので、スキー場といっても日本ほど長いコースはなく、短いところで1分くらい、長くても3〜5分で滑りきってしまうくらいの長さです。ところどころ急な斜面もあったり、ジャンプ台のようなものもあったりと、コース自体は楽しめる作りになっていました。

コースの一番下にあった開けた場所。これは川が凍ってるんだそうです。名前を聞かなかったので分からないのですが、川幅から察するに年末にボートツアーに行った川なんじゃないかと思います。

滑り始めたのが遅かったこともあり、2時間くらい滑ったところで日が暮れ始めたので、Cēsis市内に戻って食事してから帰ろうということになりました。

今年初めてのスノーボードだったので2時間でも十分楽しめました。普段着で転倒しないように注意しながらだったので思い切り滑れなかったのが残念でした。今日は宿が取れずに日帰りになってしまったので、次回は早めに宿を確保して1泊で来たいね、と話しながらCēsisに向かいました。

Cēsisでピザを食べて、少し周辺を歩いてからリガに向かうことになりました。これはCēsis市内の中心にあるモニュメント。

これはヴェンデン城跡です。昼間は中に入って見学できるんだそうです。

Cēsisの古い町並み

今回スノーボードに誘ってくれた人は、Cēsisはラトビアの中でも一番好きな街の一つだと言っていました。今回は夜も遅く、寒かったのであまり見て回れませんでしたが、次回は暖かいときにゆっくり観光に来てみたいと思います。