Watcherを始めてみようedit
ElasticsearchとKibanaにX-Packをインストールすると、Watcherは自動的に有効になります。
監視を設定してアラートの送信を開始するようにするには、次の手順を実行します。
- 監視のスケジュールを設定して入力を定義します。
- アラートを送信する必要があるかどうかを確認する条件を追加します。
- 条件を満たしたときにアラートを送信するアクションを設定します。
監視のスケジュール設定とinputの定義edit
監視のscheduleは、監視がトリガされる頻度を管理します。 監視のinputは、評価したいデータを取得します。
ログデータを定期的に検索して結果を監視に読み込むには、intervalscheduleとsearch inputを使用します。たとえば、次の監視は、10秒ごとに`logs`インデックスでエラーを検索します。
PUT _xpack/watcher/watch/log_error_watch
{
"trigger" : {
"schedule" : { "interval" : "10s" }
},
"input" : {
"search" : {
"request" : {
"indices" : [ "logs" ],
"body" : {
"query" : {
"match" : { "message": "error" }
}
}
}
}
}
}
|
通常、スケジュールは少ない頻度で実行するために設定します。この例では、intervalを10秒に設定して、監視がトリガされるのをわかりやすくしています。 この監視は実行頻度が多いため、試験を終えたら忘れずに監視を削除してください。 |
監視履歴を確認すると、監視が10秒ごとにトリガされていることがわかります。ただし、検索が結果を返していないため、監視ペイロードには何も読み込まれません。
次のリクエストは、監視履歴から直近の10個の監視実行（監視レコード）を展開します。
GET .watcher-history*/_search?pretty
{
"sort" : [
{ "result.execution_time" : "desc" }
]
}
条件の追加edit
conditionは、監視に読み込んだデータを評価して、アクションが必要かどうかを決定します。これで、監視にログエラーを読み込みました。エラーが見つかったどうかを確認する条件を定義できます。
次のcompare条件は、search inputがヒットを返したかどうかを単純に確認します。
PUT _xpack/watcher/watch/log_error_watch
{
"trigger" : { "schedule" : { "interval" : "10s" }},
"input" : {
"search" : {
"request" : {
"indices" : [ "logs" ],
"body" : {
"query" : {
"match" : { "message": "error" }
}
}
}
}
},
"condition" : {
"compare" : { "ctx.payload.hits.total" : { "gt" : 0 }}
}
}
|
compare条件を使用すると、実行コンテキスト内の値を容易に比較できます。 |
この比較条件が`true`と評価されるには、エラーを含む`logs`インデックスにイベントを追加する必要があります。たとえば、次のリクエストは`logs`インデックスに404エラーを追加します。
POST logs/event
{
"timestamp" : "2015-05-17T18:12:07.613Z",
"request" : "GET index.html",
"status_code" : 404,
"message" : "Error: File not found"
}
このイベントを追加すると、次回の監視実行時に、この条件は`true`と評価されます。条件結果は、監視実行ごとに`watch_record`の一部として記録されるため、監視結果を検索して、条件が満たされたかどうかを検証できます。
GET .watcher-history*/_search?pretty
{
"query" : {
"bool" : {
"must" : [
{ "match" : { "result.condition.met" : true }},
{ "range" : { "result.execution_time" : { "from" : "now-10s" }}}
]
}
}
}
アクションの設定edit
監視記録を監視履歴に記録するのは良いことですが、Watcherの真の実力は、条件が満たされたときに何かを実行できるということです。監視のactionsは、監視条件が`true`と評価されたときに何を実行するかを定義します。Eメールの送信、サードパーティのWebhookの呼び出し、Elasticsearchインデックスへのドキュメントの書き込み、Elasticsearch標準ログファイルへのメッセージのログ記録などを実行できます。
次のアクションは、エラーが検出されたときにElasticsearchログにメッセージを書き込みます。
PUT _xpack/watcher/watch/log_error_watch
{
"trigger" : { "schedule" : { "interval" : "10s" }},
"input" : {
"search" : {
"request" : {
"indices" : [ "logs" ],
"body" : {
"query" : {
"match" : { "message": "error" }
}
}
}
}
},
"condition" : {
"compare" : { "ctx.payload.hits.total" : { "gt" : 0 }}
},
"actions" : {
"log_error" : {
"logging" : {
"text" : "Found {{ctx.payload.hits.total}} errors in the logs"
}
}
}
}
監視の削除edit
`log_error_watch`は10秒ごとに実行するように設定されているため、試験を終えたら必ず削除してください。削除しないと、この監視例からのノイズのため、監視履歴やログファイルで何が起きているのかを確認しにくくなります。
監視を削除するには、DELETE watchAPIを使用します。
DELETE _xpack/watcher/watch/log_error_watch
必須のセキュリティ権限edit
Watcherを使用するには、ユーザーは次のセキュリティが必要になります。
- クラスタ`manage`権限。Watcher APIにアクセス可能になります。
-
.watch*`インデックスのインデックス`read`権限。.watches`インデックスと`.watcher-history-*`インデックスを読み取り可能になります。
次はどこにedit
- 監視の分析と監視ライフサイクルの詳細については、How Watcher Worksを参照してください。
- 監視の設定の追加例については、Example Watchesを参照してください。
- カスタム監視を作成するスターティングポイントとして使用できる追加のサンプル監視については、Elastic Examples repoの 監視例を参照してください。