問題の笑は、スロットリングが終了した後にLinuxがMCEを修正することです。 つまり、モードは「通常」ですが、代わりにMCEに変わります。 次のようになります。
CPU0：コア温度がしきい値を超え、CPUクロックが調整されました（合計イベント= 40997） CPU4：コア温度がしきい値を超え、CPUクロックが調整されました（合計イベント= 40997） CPU4：コア温度/通常の速度 CPU0：コア温度/通常速度 mce：[ハードウェアエラー]：マシンチェックイベントがログに記録されました
この場合、通常のMCEに確実に応答する必要があります。 どうする
logstashの一部として、メッセージ処理はステートレスであると想定されています。 メッセージが表示されます-あなたは反応します。 1つのタイプのメッセージのために、より複雑なシステムを導入する-過剰です。
フィルタ（出力と混同しないでください）elasticsearchがあり、クエリを作成できるように思われます。 残念ながら、彼はifsの実行方法を知りません。つまり、remove_tagとadd_tagは、検索が成功したかどうかに関係なく機能します。
悲しい
2番目の問題：リクエストはelasticsearchでどのように見えるべきですか？ 現在の間隔と相対的な時間間隔が必要であり、現在のホスト（つまり、MCEが送信されたホスト）でフィルタリングする必要があります。
順番に決定を始めましょう。
最初：要求。 queryには通常の検索クエリを含めることはできませんが、 lucene query内にあるクエリ文字列を含める必要があります 。 固定リクエストから始めましょう：
「タイプ：netconsole ANDホスト：compute109 ANDメッセージ：temperature」。 （タイプは、netconsoleを介してカーネルからメッセージを受信するときに入力で設定されます）。
残念ながら、結果はありますが、間隔が長いため、誤検出がたくさんあります。 しかし、@タイムスタンプはどうですか？ クエリ言語のヘルプは非常に控えめであり、数学や特別な変数は提供されていません。 ただし、範囲は「[from TO to]」などのレコードを使用してサポートされます。
その後、私は直観を持ち、リクエスト
@ timestamp:[now-2h TO now]
に書き込みました
@ timestamp:[now-2h TO now]
、ドキュメントには「今」についての言葉はありませんが。 そして、彼らは私を理解しました。 そのようなクエリをチェックすることは、kibanaの「クエリ」フィールドの方が優れています。 簡単なチェックでは、now-1mが時間とともにロールすることも示されました。
そのため、リクエストはより楽しくなりました：
type:netconsole AND host:compute109 AND message:temperature and @timestamp:[now-1m to now]
...
すべてうまくいくようです。 しかし、うまくいきませんでした。 あるべきだったが。 そして、WTF光線をlucene、logstash、elasticsearchの作成者に送信します。 andとANDは6つの異なる文字だからです。
正しい（そしてそうだけ！）
type:netconsole AND host:compute109 AND message:temperature AND @timestamp:[now-1m to now]
。 それ以外の場合、要求は、温度の単語、および
@ timestamp
を含むメッセージ（メッセージ）の検索を開始します。
問題は残っています：ホストはどこから来たのですか？ Logstashはすでにここで役立ちます-処理されたメッセージのフィールドからテキスト文字列に変数を置き換えることができます。
logstash構成の照会queryは、次のようになり始めます。
query => "(type:netconsole) AND (host:%{[host]}) AND (@timestamp:[now-1m TO now]) AND (message:temperature)"
そして、elasticsearchフィルター内にifがなければ、幸福があります。 その結果、倒錯した構成になります。ifにelasticsearchを使用したいが、使用できない場合、およびifを使用できる場所では、「過去に」要求を行うことができません。
「ツリーに乗ろう」という数十回の試行の後、次の構成が判明しました。MCEを発見し、エラスティックでリクエストを行い、MCEに関するメッセージからのホストの「温度」に関する見つかったメッセージのメッセージコンテンツを含むフィールド（MCEに関するメッセージ）に「mce_temperature」を入力し、土壇場で。 つまり、MCEに関するメッセージに、温度に関する以前のメッセージを追加します。 もちろん、見つかった場合。
残りは簡単です。MCEがあり、「前の」メッセージを含むmce_temperatureフィールドの内容があります。 elasticsearchブロックの外側に、次のように記述します。
if [temperature_mce] =〜/コアtemperature.speed normal / {
noop {
remove_tag => ["通知"]
add_tag => ["抑制"]
}
}
（notifyタグを使用して、メッセージをshinkenに送信します。suppressは、メッセージが送信されなかった理由を確認するためのものです。）
ゴキブリ
問題が解決したと仮定して、この記事を書いた時点で、そのような幸せなnagiosを受け取り、人間の声で話すことを除いて、すべてが順調でした：**問題：アラート...カーネル：[8871838.807783] mce：[ハードウェアエラー]：マシンチェックイベントのログ
私たちは見ます：
[2015年2月24日15:51:40火曜日] CPU0：コア温度/スピードノーマル [2015年2月24日15:52:54火曜日] mce：[ハードウェアエラー]：マシンチェックイベントがログに記録されました
まあ、ありがとう！ そして、[今-1m TO今]の間隔、つまり60秒があります。 また、イベント間隔は74秒でした。 そのため、最終バージョンでは、表示間隔を3分に増やす必要がありました。
少し後に発生した2番目の「面白い」問題は、リバースDNSの問題でした。 DNSはある時点で監視に追いついておらず、すべてのIPを解決できないことが判明しました。 通常、名前のIPを解決し、ホストフィールド（dnsフィルター）に書き込みます。 そして、「温度」はホストフィールドにIPで書き込まれ（解決に失敗した）、MCEにはホスト名が付いていたことがわかります。 またはその逆。 いずれにしても、正当な理由なしに夜に電話から卑劣なbzz-bzzzz。
解決策も簡単になりました。名前を解決し、IPを別のフィールドに保存します。 そして、IPによる検索を行います。
おわりに
最終構成（スニペット）：
if [message] =〜/マシンチェックイベント/ {
elasticsearch {
ホスト=> ["localhost"]
query => "（type：netconsole）AND（source_ip：％{[source_ip]}）AND（@timestamp：[now-3m TO now]）AND（message：temperature）"
フィールド=> ["message"、 "temperature_mce"]
}
if [temperature_mce] =〜/コアtemperature.speed normal / {
noop {
remove_tag => ["通知"]
add_tag => ["抑制"]
}
}
}
MCEの調整を完全に無効にする場合は、/ Core temperature.speed normal /を/ Core temperature /に置き換えます
提案されたソリューションがベストプラクティスであるかどうかはわかりませんが、機能し、構成への影響は最小限です。 このアプローチにより、複数行のメッセージに関連するあらゆるクラスの問題を解決でき、ビッグデータを無駄に育てることなく、遡及的な状況解決を行うことができます。