clamp_min() - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

clamp_min()

clamp_min(v instant-vector, min scalar)は、vの全要素のサンプル値を下限maxまでにする

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

<alertmanager_config> - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

<alertmanager_config>

alertmanager_configは、Prometheusサーバーがアラートを送るAlertmanagerのインスタンスを指定する。 Alertmanagerとどのように通信するかを設定するパラメーターも提供する。

Alertmanagerは、static_configsによって静的に設定することも、サポートされているサービスディスカバリーで動的に検出することもできる。

relabel_configsによって、検出された中からAlertmanagerを選択したり、__alerts_path__ラベルでexposeされるAPIのパスに対して高度な変更をすることができる。

# Per-target Alertmanager timeout when pushing alerts.
[ timeout: <duration> | default = 10s ]
 
# アラートがpushされるHTTPのプリフィックス
[ path_prefix: <path> | default = / ]
 
# Configures the protocol scheme used for requests.
[ scheme: <scheme> | default = http ]
 
# 設定されてusernameとpasswordでscrapeのリクエストの`Authorization`ヘッダを毎回セットする。
# passwordとpassword_fileは相互排他的である。
basic_auth:
  [ username: <string> ]
  [ password: <string> ]
  [ password_file: <string> ]
 
# 設定された署名なしトークン (Bearer Token)でリクエストの`Authorization`ヘッダを
# 毎回セットする。`bearer_token_file`と相互排他的である。
[ bearer_token: <string> ]
 
# 設定ファイルから読み込んだ署名なしトークン (Bearer Token)でリクエストの
# `Authorization`ヘッダを毎回セットする。`bearer_token`と相互排他的である。
[ bearer_token_file: /path/to/bearer/token/file ]
 
# Configures the scrape request's TLS settings.
tls_config:
  [ <tls_config> ]
 
# Optional proxy URL.
[ proxy_url: <string> ]
 
# List of Azure service discovery configurations.
azure_sd_configs:
  [ - <azure_sd_config> ... ]
 
# List of Consul service discovery configurations.
consul_sd_configs:
  [ - <consul_sd_config> ... ]
 
# List of DNS service discovery configurations.
dns_sd_configs:
  [ - <dns_sd_config> ... ]
 
# List of EC2 service discovery configurations.
ec2_sd_configs:
  [ - <ec2_sd_config> ... ]
 
# List of file service discovery configurations.
file_sd_configs:
  [ - <file_sd_config> ... ]
 
# List of GCE service discovery configurations.
gce_sd_configs:
  [ - <gce_sd_config> ... ]
 
# List of Kubernetes service discovery configurations.
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]
 
# List of Marathon service discovery configurations.
marathon_sd_configs:
  [ - <marathon_sd_config> ... ]
 
# List of AirBnB's Nerve service discovery configurations.
nerve_sd_configs:
  [ - <nerve_sd_config> ... ]
 
# List of Zookeeper Serverset service discovery configurations.
serverset_sd_configs:
  [ - <serverset_sd_config> ... ]
 
# List of Triton service discovery configurations.
triton_sd_configs:
  [ - <triton_sd_config> ... ]
 
# List of labeled statically configured Alertmanagers.
static_configs:
  [ - <static_config> ... ]
 
# List of Alertmanager relabel configurations.
relabel_configs:
  [ - <relabel_config> ... ]

# 参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

prometheus.ymlの検証方法 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

prometheus.ymlが正しいことを検証するには

プロダクション環境にデプロイする前に、設定が正しいことを確認するのは良いことである。

Prometheusは、間違った設定があればリロードしないが、正しい設定がないと起動できない。 従って、継続的インテグレーションなどの仕組みにチェックインする前に設定が正しいことを確認するのが賢明である。

Prometheusに付属しているpromtoolには、check configコマンドがある。 Prometheusをダウンロードして、正しくない設定を作ってみよう。

wget https://github.com/prometheus/prometheus/releases/download/v2.5.0/prometheus-2.5.0.linux-amd64.tar.gz
tar -xzf prometheus-*.tar.gz
cd prometheus-*
cat >prometheus.yml <<'EOF'
scrape_configs:
- job_name: prometehus
static_configs:
  - targets: ['localhost:9090']
EOF

設定をチェックしてみると、エラーが表示される。

./promtool check config prometheus.yml
Checking prometheus.yml
  FAILED: parsing YAML file prometheus.yml: yaml: unmarshal errors:
  line 3: field static_configs not found in type config.plain

終了コードは、失敗を表す1になる。

最後の2行を正しくインデントし直して再びチェックすると、今度はパスする。

./promtool check config prometheus.yml 
Checking prometheus.yml
 SUCCESS: 0 rule files found

終了コードは0になる。

この種の機能はPrometheusに限られたものではなく、Alertmanagerのamtoolにも同様の機能がある。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

amtoolの使い方 - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

Amtool

全てのalertmanagerのリリースに付属している。

インストール

代わりに以下のコマンドでもインストールできる。

go get github.com/prometheus/alertmanager/cmd/amtool

利用例

今起きている全アラートを表示する

$ amtool alert
Alertname        Starts At                Summary
Test_Alert       2017-08-02 18:30:18 UTC  This is a testing alert!
Test_Alert       2017-08-02 18:30:18 UTC  This is a testing alert!
Check_Foo_Fails  2017-08-02 18:30:18 UTC  This is a testing alert!
Check_Foo_Fails  2017-08-02 18:30:18 UTC  This is a testing alert!

今起きているアラートを拡張された出力と共に表示する

$ amtool -o extended alert
Labels                                        Annotations                                                    Starts At                Ends At                  Generator URL
alertname="Test_Alert" instance="node0"       link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local
alertname="Test_Alert" instance="node1"       link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node0"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node1"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local

アラートは、ただ表示するだけでなく、Alertmanagerが提供するたくさんのクエリを利用できる

$ amtool -o extended alert query alertname="Test_Alert"
Labels                                   Annotations                                                    Starts At                Ends At                  Generator URL
alertname="Test_Alert" instance="node0"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local
alertname="Test_Alert" instance="node1"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local

$ amtool -o extended alert query instance=~".+1"
Labels                                        Annotations                                                    Starts At                Ends At                  Generator URL
alertname="Test_Alert" instance="node1"       link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local
alertname="Check_Foo_Fails" instance="node1"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local

$ amtool -o extended alert query alertname=~"Test.*" instance=~".+1"
Labels                                   Annotations                                                    Starts At                Ends At                  Generator URL
alertname="Test_Alert" instance="node1"  link="https://example.com" summary="This is a testing alert!"  2017-08-02 18:31:24 UTC  0001-01-01 00:00:00 UTC  http://my.testing.script.local

アラートをサイレンスする

$ amtool silence add alertname=Test_Alert
b3ede22e-ca14-4aa0-932c-ca2f3445f926

$ amtool silence add alertname="Test_Alert" instance=~".+0"
e48cb58a-0b17-49ba-b734-3585139b1d25

サイレンスを表示する

$ amtool silence query
ID                                    Matchers              Ends At                  Created By  Comment
b3ede22e-ca14-4aa0-932c-ca2f3445f926  alertname=Test_Alert  2017-08-02 19:54:50 UTC  kellel

$ amtool silence query instance=~".+0"
ID                                    Matchers                            Ends At                  Created By  Comment
e48cb58a-0b17-49ba-b734-3585139b1d25  alertname=Test_Alert instance=~.+0  2017-08-02 22:41:39 UTC  kellel

サイレンスを無効にする

$ amtool silence expire b3ede22e-ca14-4aa0-932c-ca2f3445f926

クエリにマッチするサイレンスを全て無効にする

$ amtool silence query instance=~".+0"
ID                                    Matchers                            Ends At                  Created By  Comment
e48cb58a-0b17-49ba-b734-3585139b1d25  alertname=Test_Alert instance=~.+0  2017-08-02 22:41:39 UTC  kellel

$ amtool silence expire $(amtool silence -q query instance=~".+0")

$ amtool silence query instance=~".+0"

全てのサイレンスを無効にする

$ amtool silence expire $(amtool silence query -q)

設定

amtoolは、設定ファイルでいくつかのオプションを指定することができる。 デフォルトのファイルパスは、$HOME/.config/amtool/config.ymlまたは/etc/amtool/config.ymlである。

設定例は以下のようになる。

# amtoolが`alertmanager`のインスタンスを見つける方法を指定する
alertmanager.url: "http://localhost:9093"

# デフォルトのauthorを上書きする(指定しなければ、デフォルトは自分のusername)
author: me@example.com

# サイレンスにコメントを含めなかった場合にamtoolがエラーになるようにする
comment_required: true

# デフォルトの出力形式を指定する(指定しなければsimple)
output: extended

# デフォルトのレシーバーを指定する
receiver: team-X-pager

ルート

amtollによって、設定されたルートをテキストの木構造で可視化することができる。 また、アラートのラベル集合を渡して、ルーティングのテストをすることができる。 amtoolはそのアラートがマッチする順に,区切りで全てのレシーバーを出力する。 --verify.receiversを利用すると、マッチしなかったときにエラーコード1を返す。

利用例:

# リモートのAlertmanagerのルートツリーを表示する
amtool config routes --alertmanager.url=http://localhost:9090

# 期待されたレシーバーにマッチするかテストする
./amtool config routes test --config.file=doc/examples/simple.yml --tree --verify.receivers=team-X-pager service=database owner=team-X

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

clamp_max() - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

clamp_max()

clamp_max(v instant-vector, max scalar)は、vの全要素のサンプル値を上限maxまでにする

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

changes() - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

changes()

changes(v range-vector)は、入力の各時系列に対してその値が指定された時間幅内に変化した回数をinstant vectorとして返す

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

アラーティングベストプラクティス - Prometheusドキュメント

このページはPrometheus公式ドキュメント和訳+αの一部です。

Alerting

Googleで見たことに基づくRob EwaschukのMy Philosophy on Alertingを読むことをお勧めする。

まとめると、アラートをシンプルに保つ、症状についてアラートする、原因を特定できるように良いコンソールを持つ、何もすることがない呼び出しを避けることである。

何についてアラートするか

苦痛を起こし得る可能性全てを捉えようとするのではなく、エンドユーザーの苦痛に結びついた症状についてアラーティングすることで、可能な限り少ないアラートが来ることを目指すこと。

Allow for slack in alerting to accommodate small blips.

online-servingシステム

一般的に、可能な限り高いレイヤーのレイテンシーとエラー率についてアラートすること。

スタックの1箇所のレイテンシーについてのみ呼び出しを行うこと。 低レベルのコンポーネントが遅くても、全体としてのレイテンシーが良好なら、呼び出しをする必要はない。

エラー率に関して、ユーザーに見えるエラーについて呼び出しを行うこと。 そのようなエラーを引き起こし得る下位レイヤーのエラーが起きていたとしても、個別にそれらについて呼び出しをする必要はない。 ただし、あるエラーが、ユーザーには見えなくても、人間の対応が必要なぐらい深刻(例えば、金銭的な損失が大きい)なら、それらについて呼び出しを追加すること。

リクエストが種類によって異なる特徴を持つなら、それらに対して異なるアラートが必要になるだろう。 そうしなければ、トラフィックの少ない種類のリクエストの問題は、トラフィックの多いリクエストに埋れて消えてしまうだろう。

オフライン処理

オフライン処理システムに対しては、鍵となるメトリックは、データがシステムに入ってから出るまでにどれぐらいかかるかである。 したがって、それがユーザーに影響を与えるぐらいまで高くなったら、呼び出しをするべきである。

バッチジョブ

バッチジョブに対しては、直近で十分に成功しておらずユーザーに見える問題を起こしそうな場合に呼び出しを行うのが合理的である。

これは、バッチジョブ実行全体の少なくとも2回分に十分な時間にするべきである。 4時間ごとに実行され1時間かかるジョブに対しては、10時間が合理的な閾値であろう。 もし、一回の実行の失敗も耐えられないのであれば、一回の失敗で人間の介在が必要とならないように、ジョブをもっと頻繁に実行すること。

キャパシティ

ユーザーへの影響をすぐに起こす問題ではないが、キャパシティに注意することは、近い将来の不測の事態を避けるために、しばしば人間の介在を必要とする。

メタ監視

監視が動いていると確信を持つことは重要である。 したがって、Prometheusサーバー、Alertmanager、Pushgatewayおよびその他の監視インフラが正しく動いていると保証するためにアラートするべきである。

いつものように、原因ではなく症状についてアラートすることが可能ならば、そうするのがノイズを減らすことに繋がる。 例えば、アラートがPushgatewayからPrometheusとAlertmanagerを通ってメールまで届くことのブラックボックステストは、それぞれに対する個別のアラートよりも良い。

Prometheusのホワイトボックステストを外部のブラックボックス監視で補うことで、そうしないと見つけられない問題を検出する可能性がある。 また、内部システムが完全に失敗している場合の最後の拠り所として働く。

参考リンク

和訳活動の支援

Prometheusドキュメント和訳が役に立った方は、以下QRコードからPayPayで活動を支援して頂けるとありがたいです。

PayPayによる支援用QRコード
上のQRコードからPayPayによる支援

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

Prometheus: Up & Running: Infrastructure and Application Performance Monitoring

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム