node_exporter の次期アップグレードで変更になるオプション設定

現時点ではリリースされていないのですが、masterに後方互換のない破壊的変更が入っていますので紹介します。

node_exporterでは、28個のコレクターが既定で有効になっています。
既定で有効になっているコレクターを無効にするには、「–no-collector.<name>」をflagに設定します。

例えば、arpとcpuを無効にするには、オプションに次のように指定します。

./node_exporter –no-collector.arp –no-collector.cpu

また、node_exporterは、既定では無効になっている16個のコレクターがあります。
それらを有効にするには、「–collector.<name>」をflagに設定します。

例えば、logindを有効にするには、オプションに次のように指定します。

./node_exporter –collector.logind

実装

コレクターの実装を見てみましょう。
コレクターをnode_exporterに登録するには、init時に「registerCollector」で登録します。
引数にコレクター名と、デフォルトで有効か無効かと、実装関数を渡します。

func init() {
    registerCollector("bonding", defaultDisabled, NewBondingCollector)
}

collector.go では、配列に実装関数とコレクターフラグ名・有効無効とをそれぞれに格納します。

collectorState[collector] = flag
factories[collector] = factory

後は順次、ループで非同期でコレクターをexecuteしていきます。

// Collect implements the prometheus.Collector interface.
func (n nodeCollector) Collect(ch chan<- prometheus.Metric) {
	wg := sync.WaitGroup{}
	wg.Add(len(n.Collectors))
	for name, c := range n.Collectors {
		go func(name string, c Collector) {
			execute(name, c, ch)
			wg.Done()
		}(name, c)
	}
	wg.Wait()
}

Prometheus Alertmanager 0.9.0/0.9.1 リリースの機能追加内容

Prometheus Aertmanager 0.9.0が9/28に、バグ修正がされた0.9.1が9/29にリリースされました。
0.9.0 で追加された機能について紹介します。その他にも多くのバグが修正されています。

  1. webhookメッセージに現在時刻が追加されました
  2. slackの通知にlink_nameが追加されました
  3. 選択/ハイライトできるラベルUIが作成されました
  4. 注釈内にクリックできるリンクUIが作成されました
  5. API経由でアラートのfingerprint(ユニークな識別子)を出力できるようにしました
  6. READMEにamtoolに関する記述を追加しました
  7. Aertmanager全体で、ユーザー設定ロギングオプションを使用するようにしました
  8. fingerprintでソートしてAPIからアラートを返すようにしました
  9. サイレンスページビューで編集/削除するサイレンスボタンを追加しました
  10. amtoolにcheck configをするサブコマンドを追加しました
  11. メール通知でテキストサポートを追加しました
  12. make build時に対象のバイナリ名を渡せるようにしました
  13. プレビューでサイレントアラート数を表示するようにしました
  14. 期限切れサイレンスのとき確認ダイアログを出すようにしました

1.webhookメッセージに現在時刻が追加されました

通知送信のデバッグをしやすくするため、webhookの標準出力に現在時刻が追加されました。

2017/07/18 11:38:25 6
2017/07/18 11:38:25 [foo@bar.com baz@quux.edu]

 

2.slackの通知にlink_nameが追加されました

Slackに通知を送信する際に、link_nameオプションを設定できるようになりました。
link_nameをtrueに設定することで、Slackに通知されたときに、ユーザー名やチャネル名にリンクが張られます。
link_nameのイメージは、Slack API でユーザ・チャンネルの名前がリンクされないときの対処法を参照すると理解しやすいです。

configで、次のように指定すれば使用可能です。

slack_configs:
   link_names: true

 

3.選択/ハイライトできるラベルUIが作成されました

ラベルUIが変更されました。これまではフィルタリング用のボタンで、文字列をコピーしずらい状況でした。
選択可能な部分とボタンにわけることで、ラベル文字列を選択してコピーできるようになりました。

image

 

4.注釈内にクリックできるリンクUIが作成されました

annotation(注釈)内に、http(s)://で始まる文字列があったら、クリックできるようにしました。

image

 

5.API経由でアラートのfingerprint(ユニークな識別子)を出力できるようにしました

http://localhost:9093/api/v1/alertsのAPIからalertを取得した際のレスポンスにfingerprintを含めるようにしました。

"status":{"state":"suppressed","silencedBy":null,"inhibitedBy":["8531739189852378575"]},"receivers":["slack"],"fingerprint":"6543bc164be4f176"}

fingerprintが出力されることで、Alertを識別できるようになります。

 

6.READMEにamtoolに関する記述を追加しました

READMEにAmtoolに関する説明が追加されました。

Amtoolは、altermanager apiを利用するCLIツールです。
全てのアラートの参照
アラートの詳細を表示
クエリでフィルターしてアラートを出力
アラートをサイレンスにする
サイレンス一覧を表示
すべてのサイレンスを期限切れにする

 

7.Aertmanager全体で、ユーザー設定ロギングオプションを使用するようにしました

サブコンポーネント用に新たしロガーを作成するのではなく、基本ロガーを用いるようにします。
CLIは渡されたロギングオプションを利用するようになります。

 

8.fingerprintでソートしてAPIからアラートを返すようにしました

APIからアラートを取得する際に、結果をfingerprintで並べ替えてから出力されるようになりました。

 

9.サイレンスページビューで編集/削除するサイレンスボタンを追加しました

サイレンスビュー(http://example.com:9093/#/silences/)に、Edit、Expireボタンが追加されました

image

image

 

10.amtoolにcheck configをするサブコマンドを追加しました

amtoolにコンフィグをチェックするコマンドが追加されました。

$ ./amtool check-config alertmanager.yml ./doc/examples/simple.yml
Checking 'alertmanager.yml'  SUCCESS
Found 1 templates:   FAILED: template: foo.tmpl:3: unexpected {{end}}
Checking './doc/examples/simple.yml'  SUCCESS
Found 1 templates:   SUCCESS
Error: Failed to validate 1 file(s).

 

11.メール通知でテキストサポートを追加しました

それまでメール通知はHTMLメールでしたが、テキストメールも送信できるようにオプションが追加sれました。

オプション:text

 

12.make build時に対象のバイナリ名を渡せるようにしました

make時にバイナリ名を指定できるようにしました。

$make build BINARIES=amtool
>> building binaries
 >   amtool

バイナリ名を設定しない場合は、通常通りビルドします。

 

13.プレビューでサイレントアラート数を表示するようにしました

サイレンスページで、指定した条件に当てはまる件数が何件あるのかをpreviwボタンを押した際に表示するようにしました

image

image

 

14.サイレンスを期限切れにする際に確認ダイアログを出すようにしました

EC2 DiscoveryでIAMロールで認証できるオプションが追加

2017/9/9 に、Prometheus の master ブランチにマージされ、EC2 Discovery で、IAMロール認証を使用できるオプションが追加されました。

yamlファイルに次のオプションを指定すれば利用できます。

role_arn: ‘arn:aws:iam::account-id:role/role-name’

認証ロジックとしては、シンプルな修正で済んでますね。

if d.roleARN != "" {
        creds := stscreds.NewCredentials(sess, d.roleARN)
        ec2s = ec2.New(sess, &aws.Config{Credentials: creds})
}

「Prometheus入門から運用まで徹底解説」で登壇してきました

July Tech Festa 2017 で、「Prometheus入門から運用まで徹底解説」というタイトルで登壇してきました。

セッションの目的は、すでに別のモニタリングシステムを使ったことがある人が、Prometheusを評価、検証しようとしたときに必要な情報の提供と、初めてだとハマるポイントを予め解説しておくことです。

それによって、最初の評価検証がスムーズに行えることを企図したセッションとなっています。

Prometheusの冗長化について公式のスタンス

Prometheusをどうやって冗長構成を組むか一度は悩むのではないでしょうか。
公式ドキュメントを見ても、冗長構成の組み方には言及がされていないように見えます。

Prometheusの冗長構成については、Githubのissuesで公式見解が語られていますので紹介します。

For HA, simply run the two Prometheus servers independently with the same configuration. They’ll have the same data, modulo sample timings.

潔いスタンスですね。
別々に2つのPrometheusを構築して、同じ構成ファイルで動かしましょう。同じデータになるよとのこと。
クエリ発行先を片方にして、何か問題が発生すればもう片方にスイッチさせる。
DNSのCNAMEを使って切り替えるのが一番楽だろう。
もっと自動化したいのなら、ロードバランサ―かVIPを使いましょう。
その名前をGrafanaで使えばばっちり。

スケールのためだとしても、Prometheusを分けて、監視する対象を分けちゃいましょう。

ちなみに質問者が喰い下がって、「so you could query any server, and get forwarded (http 301 or just proxy request) to a server who has the data.」と要望しました。
それに対する回答が、「This is not a feature we plan to add.」と。

他の質問者が突っ込んでみました。「Example that was mentioned above: when a physical server is downed.」
それに対する回答が、「If you need 100% accuracy in data reporting, Prometheus is not for you 」
100%のデータ保持を担保したいのなら、Prometheusはあなた向きじゃないよだって。

Prometheusのローカルストレージの特性をよく表現した説明が書かれています。
耐久性、レプリケーション、長期のデータ保持は考慮してないよ。
数週間、数カ月、数年問題なく動作するのだとしても、あくまでも上記のことは考慮してない。

Prometheus’s local storage is generally not considered a durable, replicated, or arbitrarily long-term storage – even if it works well for weeks, months, or sometimes even years in practice.

とは言え、希望が無いわけでもありません。

長期保存については対応しようとしてるし、サーバダウンやデータレプリケーションについてはよくしようと思っている。

"Real" long-term storage is still in the works and aims to address individual down servers and replication of data better. It will be decoupled enough from the main Prometheus servers that these won’t have to hard-depend on it though.

altermanagerは?

Prometheusを複数運用していても、Altermanagerは1つにしましょう。
Altermanagerは、手動フェールオーバーでいいんじゃない?

とのこと。。。

ただし、「監視システムを独立して監視することはいつでも重要だよ」で締めくくられています。