1. Homepage
  2. Runtime Fabric (1.13)
  3. VM/ベアメタル

  4. アラートの設定

Runtime Fabric でのアラートの設定

VM/ベアメタルの Runtime Fabric では、既存の SMTP サーバーを介してアラートを送信できます。VM/ベアメタルの Runtime Fabric には、システムの健全性が低下したときに通知を送信するアラート機能があります。

組み込みアラート

次の表では、VM/ベアメタルの Anypoint Runtime Fabric によって提供されるデフォルトのアラートを示しています。

アラート 説明

​docker

Docker デーモンがダウンしたときにエラーを送信します。

​etcd

etcd リーダーが 5 分以上アクセスできない場合または etcd クラスターがダウンしている場合にエラーを送信します。

​etcd_latency_batch

フォロワーとリーダーのレイテンシーが 500 ミリ秒を超えたときに警告を送信し、1 分間で 1 秒を超えたときにエラーをトリガーします。

​filesystem

容量の使用量が 80% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。inode 容量の使用量が 90% に達したときに警告を送信します。使用量が 95% を超えたときに重大なエラーをトリガーします。

​high-cpu

容量の使用量が 75% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。

​high_memory

メモリの使用量が 80% に達したときに警告を送信します。使用量が 90% を超えたときに重大なエラーをトリガーします。

​influxdb_health_batch

InfluxDB がダウンしたか Kapacitor と InfluxDB の間に接続がないときにエラーをトリガーします。

​ingress

ポッドの CPU 容量の使用量が 80% を超えたときに重大なエラーをトリガーします。ポッドのメモリ容量の使用量が 80% を超えたときに重大なエラーをトリガーします。

​kubernetes_node

ノードが 5 分以上準備完了と報告されていないときに警告を送信します。

​muleapps

CPU の使用量が 90% を超えたときに重大なエラーをトリガーします。ポッドのメモリの使用量が 90% を超えたときに重大なエラーをトリガーします。

​network_params

ノードでネットワーキングが無効になっているときに重大なエラーをトリガーします。

​uptime

システムが 5 分以上アクセスできないときにエラーを送信します。

アラートの設定

SMTP サーバー経由で指定されたアラート送信者メールアドレスから Runtime Fabric アラートを送信できます。アラートにつき設定できるメール受信者は 1 人のみです。

  1. rtfctl​ をインストールします。

    Runtime Fabric のアラート送信者メールを管理するには、​rtfctl​ ユーティリティが必要です。次の手順を実行する前に、​「rtfctl のインストール」​の手順を実行します。

  2. ターミナルを使用して、コントローラー VM へのシェル/SSH 接続を開きます。

  3. 次の内容が含まれる ​alert-smtp.yaml​ という名前のファイルを作成します。

    kind: smtp
version: v2
metadata:
  name: smtp
spec:
  host: <smtp host>
  port: <smtp port>
  username: <username>
  password: <password>
---
kind: alerttarget
version: v2
metadata:
  name: email-alerts
spec:
  email: <email>

  4. 環境に固有の次の値を使用して、​alert-smtp.yaml​ のコンテンツを変更します。

    Table 1. 環境変数
    キー 説明

    <smtp host>

    SMTP サーバーのエンドポイント。

    <smtp port>

    SMTP サーバーに接続するために使用されるポート。(デフォルトは 465)。

    <username>

    SMTP サーバーに接続するときに使用するユーザー名。

    <password>

    SMTP サーバーに接続するときに使用するパスワード。

    <email>

    受信者のメールアドレス。

  5. コントローラー VM で次のコマンドを実行します。

    $ sudo gravity resource create -f alert-smtp.yaml

  6. rtfctl​ ユーティリティを使用して、SMTP ドメインが含まれるアラート送信者メールアドレスを設定します。アラートをトリガーするクラスターを識別するには、各クラスターに区別しやすいメールアドレスを使用します。

    $ sudo ./rtfctl appliance apply alert-smtp-from "sender@example.com"

メールアラートのコンテンツを変更する

必要に応じて、Runtime Fabric から送信されるメールアラートのコンテンツを変更できます。アラートは TICKscript で記述されます。

いずれかの Runtime Fabric メールアラートをカスタマイズした場合、アプライアンスのアップグレードにより、カスタマイズが上書きされます。

  1. Ops Center に移動します。

  2. Ops Center メニューから ​[Configuration (設定)]​ をクリックします。

  3. [Config maps (設定マップ)]​ ドロップダウンメニューから ​[kapacitor-alerts]​ を選択します。

  4. [Namespace (名前空間)]​ ドロップダウンメニューから ​[monitoring]​ を選択します。

  5. 目的のアラートを選択して変更を行います。

  6. 完了したら、​[Apply (適用)]​ をクリックします。

  7. SSH または Ops Center を使用していずれかのコントローラーノードにログインします。

  8. kapacitor ポッド名を取得します。

    kubectl -n monitoring get pod -l component=kapacitor

    名前は ​kapacitor-xxxxxxxxxx-xxxx​ のようになります。

  9. 設定済みアラートのリストを取得します。

    kubectl -n monitoring exec <pod name> -c alert-loader -- kapacitor -url http://localhost:9092 list tasks

  10. 変更したアラートを削除します。

    kubectl -n monitoring exec <POD NAME> -c alert-loader -- kapacitor -url http://localhost:9092 delete tasks <MODIFIED ALERT NAME>

  11. アラートが再作成され、[Status (状況)] の値が ​enabled​、[Executing (実行中)] の値が ​true​ であることを確認します。

    kubectl -n monitoring exec <pod name> -c alert-loader -- kapacitor -url http://localhost:9092 list tasks

    結果にアラートのリストが表示されます。

    ID                     Type      Status    Executing Databases and Retention Policies
<MODIFIED ALERT NAME>  stream    enabled   true      ["k8s"."default"]
...

  12. 新しいアラートのコンテンツを確認します。

    kubectl -n monitoring exec kapacitor-85c9d79c9b-ttkdn -c alert-loader -- kapacitor -url http://localhost:9092 show <MODIFIED ALERT NAME>

    結果は次のようになります。

    ID: <alert_name>
Error:
Template:
Type: stream
Status: enabled
Executing: true
...

関連情報