Monthly Archives: 10月 2016

2016-10-17

EditorConfigでEclilpseのテンプレートとオサラバしよう!

こんにちは。NIKKOエンジニアのS.TKです。今回は簡単に導入できるエディタ設定の共有ツールを紹介したいと思います。

皆さんは開発の際にインデントをタブ、スペースのどちらにするか、文字エンコーディングを何にするか等のルールで揉めた経験はありませんか?また、ルールを決めても結局守られなかった……といった経験はありませんか?

今回紹介する EditorConfig は、こういう問題に対する解決策の一つです。

EditorConfigとは

EditorConfig は異なるエディタ、 IDE 間で編集ルールを統一することができるツールです(公式ページ)。

多くのエディタと IDE が対応しており、設定ファイルを置くだけで有効になるため、導入はとても簡単です。有名どころでは以下のエディタ、 IDE が対応しています(詳細は公式ページを参照)。

  • Notepad++
  • Atom
  • Emacs
  • Vim
  • Eclipse
  • NetBeans
  • IntelliJ IDEA

導入方法

ファイルと同じ階層に設定ファイル( .editorconfig )を置けば導入完了です。エディタまたは IDE が EditorConfig に対応していることを確認してください。

.editorconfig ファイルはこんな感じに書きます。

EditorConfig の設定ファイル

設定ファイルは .editorconfig という名前の INI 形式ファイルです。  [ と ] でセクションを指定し、 name = value でプロパティを設定します。また、コメントは # か ; で開始します。

設定の優先度

結論から言うと、開いたファイルに近い .editorconfig の設定値が優先されます。具体的な優先度は以下のようにして決められます。

  1. 開いたファイルと同階層から上位の階層へと順番に .editorconfig を探索する。
  2. 最上位階層に到達するか、rootプロパティにtrueが指定されている .editorconfig を発見したなら探索を止める。
  3. 見つかった .editorconfig を上位階層から順番に適用する。よって同じプロパティに異なる値が設定されている場合、開いたファイルに一番近い .editorconfig の設定値が優先される。

セクションの形式

セクションにはルールを適用するファイルをワイルドカード等を使用して指定します。実際に使用できるパターンは以下のとおりです。
なお、特殊文字を文字として使いたい場合はバックスラッシュでエスケープしてください。

パターン 説明
* パス区切り文字( / )以外の任意の文字列にマッチ。
** パス区切り文字( / )も含めた任意の文字列にマッチ。
? 任意の1文字にマッチ。
[name] nameに含まれている任意の1文字にマッチ。
[!name] nameに含まれていない任意の1文字にマッチ。
{s1,s2,s3} カンマ区切りで与えられた文字列のいずれかにマッチ。
{num1..num2} num1からnum2までの範囲の整数値にマッチ。

プロパティの一覧

プロパティにはファイルに適用するルールを指定します。実際に使用できるプロパティは以下のとおりです。
なお、プロパティを設定しなかった場合は、エディタまたはIDEの設定がそのまま使われます。

プロパティ名 設定可能な値 説明
indent_style tab
space
インデントの形式を指定する。
tabはタブ、spaceはスペースを使用する。
indent_size 数値
tab
インデント時のスペースの個数を指定する。
tabを指定した場合、tab_widthプロパティの指定値を適用する。
tab_width 数値 タブを表現するためのスペースの個数を指定する。
デフォルト値としてindent_sizeプロパティの値が指定されているので、通常は設定する必要なし。
end_of_line lf
cr
crlf
改行コードの形式を指定する。
charset latin1
utf-8
utf-16be
utf-16le
文字エンコーディングを指定する。
trim_trailing_whitespace true
false
trueの場合、行末の空白文字を削除する。
insert_final_newline true
false
trueの場合、ファイル保存時にファイル末尾が改行記号でなければ改行記号を付与する。
root true trueの場合、このファイルより上位の階層の .editorconfig ファイルを探索しない。

まとめ

今回は、エディタ設定を共有するツールとしてEditorConfigを紹介しました。対応しているエディタ、IDEであれば設定ファイルを置くだけで導入できますので、是非試してみてください。

2016-10-14

今更だけど、 Nagios について知っておきたい 5 つのこと

みなさんは監視していますか? 健全な運用には、まずは適切な監視が重要です。そんな監視をするツールは、 2016 年現在いろいろありますが、そうは言っても、監視と言えばとりあえず Nagios です。ということで、今回はそんな Nagios について知っておきたいポイントを 5 つほど紹介したいと思います。

その 1: “Nagios” の読み方を知る

そもそも Nagios はどのように読む・発音するのでしょうか? 巷ではどうも「ナギオス」派と「ナジオス」派がいるようです。どちらが正しいのでしょうか。実はこの問いに対しては公式に答えが示されています。

Nagios Support – How do you pronounce Nagios?

つまりカタカナで書くならば「ナギオス」が公式見解に近いと言えましょう。

なお、以前は、公式サイトで Nagios の発音の mp3 が置いてあったのですが、 What is the correct pronunciation of Nagios? に “Answer originally linked to an mp3 audio file which contained the pronunciation as spoken by Ethan, the author of Nagios. File is no longer hosted by Nagios.” とありました。残念ですね…。

その 2: 必読の書籍を知る

まずは書籍です。幸いなことに Nagios については良い日本語で書かれた書籍があります。
“Nagios統合監視[実践]リファレンス”です。 Nagios に触るならば、手元に置いておきましょう。

その 3: Nagios による監視プログラム実行の 3 パターンを知る

Nagios による監視プログラム実行のパターンは 3 つあります。

  1. Nagios が監視プログラムを直接実行する
  2. Nagios がリモートの監視プログラムを NRPE で実行する
  3. 監視プログラムが NSCA を使って、結果を Nagios に通知する

1 は最もポピュラーなやり方です。デフォルトの監視項目はこれで動いています。これが大量にあると、 Nagios が動いているサーバで大量の監視プログラムのプロセスが起動することになります。

2 の NRPE = Nagios Remote Plugin Executer は 1 ではできない・やりづらいケースで用います。現実的にこれが有効なのは、「そのサーバにしか置いていないプログラムや設定ファイルを使うような監視」をやる場合でしょうか。ただし、 NRPE は、監視に用いたいコマンドを nrpe.cfg という設定ファイルに記述し、 Nagios の設定ファイル側では、その設定でのコマンド名を指定する、というようになります。例えば、 nrpe.cfg が以下のように記述されている場合、

これを呼び出すには Nagios 本体側の設定ファイルで以下のように記述することになります。

3 の NSCA = Nagios Service Check Acceptor はいわば監視プログラム側からのプッシュ型です。監視のタイミングを Nagios で定められるような定期的な設定にしたくない場合は、これの出番となります。例えば「ログに特定の文字列が書き出されたらその時点でアラートを上げる」という場合は、これを使うと自然にできます。

その 4: Nagios プラグインの書き方を知る

さて、どのような監視方式を選ぶにしても、任意の監視をやりたいとなると、 Nagios プラグインを自身で実装することになります。
Nagios プラグイン、とだけ聞くと、何か書くにあたってめんどくさいルールを覚えないといけないのでは、と臆してしまうこともあるかもしれませんが、基本的には 2 つのルールだけ覚えておけば OK です。

ルール 1: プログラムの exit status を Nagios プラグイン的にする

Nagios による監視のステータスというのは 4 種類あって、 OK, WARNING, CRITICAL, UNKNOWN ですが、これは Nagios プラグインの exit status にてそれぞれ 0, 1, 2, 3 に対応しています。つまり、

ステータスのラベル exit status の値
OK 0
WARNING 1
CRITICAL 2
UNKNOWN 3

 

ということです。自分で Nagios プラグインを書くときも、ただこれに従うだけで良いのです。

ルール 2: メッセージを標準出力に書き出せ。ただしもっとも重要なことは 1 行目に。

Nagios の WebUI の Services のような、監視項目(これを Nagios 的には service と呼んでいる)の一覧表では Status Information というところに、メッセージが表示されていますが、これは、 Nagios プラグインが標準出力に書き出した 1 行目( = 最初の改行文字よりも前の内容)です。そして、その監視項目の詳細を開くと 2 行目以降も表示されています。ということで、監視結果のステータスと合わせて伝えたい内容は、まず 1 行目に重要なことを書き、 2 行目以降により詳細な内容を書き出すようにしましょう。

また、その 1 行目・ 2 行目以降の内容は、 Nagios の内部的にはそれぞれ $SERVICEOUTPUT$, $LONGSERVICEOUTPUT$という変数で保持されています。このことを知っていると、監視の通知をするメールの本文の組み立てに活かすことができます。

その 5: 「通知」のためのプログラムを知る

Nagios というと「監視がひっかかったら、メールで通知してくれる」というイメージが強かろうと思いますが、この「メールで通知する」というのは、そもそもデフォルトではどう実現しているのでしょうか?

「通知」について知るには、まず contact の定義を読む必要があります。
contact は文字通り「連絡先」で、つまり、「通知」を出す相手を表すモノです。

この contact の定義に service_notification_commandshost_notification_commands という項目がありますが、これはそれぞれ service の監視・ host の監視で通知対象となったとき(WARNING や CRITICAL になったときや、そこから復帰して OK になったときなど)に呼び出すコマンドです。 commands と複数形で書かれているとおり、複数指定することができます

デフォルトで用意されている contact では、それぞれのコマンドとして notify-service-by-email や notify-host-by-email というのが指定されていますが、これらはそれぞれ、その名前で command として定義されています。そこで、 notify-service-by-email という command 定義を探してみると、デフォルトでは commands.cfg に定義されており、その command_line はデフォルトでは以下のようになっています。

これを読むとわかるとおり、実は単に、本文として送りたい内容を Nagios が用意している変数を使いつつ printf コマンドで書き出し、それを mail コマンドに食わせているだけなのです。

ここまで読み解いてくると、「通知」のためのプログラムというのも、なんら特別なことはない、ということがわかります。 “$” で囲まれている定義済みの変数を上手く使って、件名や本文を組み立てたコマンドを用意すれば OK です。この “$” で囲まれている変数の一覧は Standard Macros in Nagios で確認することができます。前のセクションで触れた $SERVICEOUTPUT$, $LONGSERVICEOUTPUT$ についても、こちらで紹介されています。

例えば Nagios と Slack を使っている人の場合は、これを使っているかもしれませんが、これも結局、定義済みの変数を上手く使って Slack の API を叩くようなプログラムを呼び出しているだけ、です。

まとめ

今回は、 Nagios を扱う際に知っておきたい 5 つのことを書いてみました。 Nagios とうまく付き合っていくために覚えておきましょう。