Grafana: グラファナの監視

++

：+1：

ヘルスURLがセッションを生成しないことを確認してください

：+1：

+1、これはロードバランサーの背後でgrafanaを実行するのに非常に便利です。ロードバランサーは/ health HTTPを呼び出して、grafanaがHTTP 200OKを返すかどうかを確認します。

とてもシンプルなものをまとめましたが、現時点では特に満足していません。

誰かが現在の状態とマスターを確認したい場合： https ：//github.com/grafana/grafana/compare/master ... theangryangel：feature / health_check

次のようなものを返します。

{"current_timestamp":"2016-06-04T18:43:49+01:00","database_ok":true,"session_ok":true,"version":{"built":1464981754,"commit":"v3.0.4+158-g7cbaf06-dirty","version":"3.1.0"}}

私が最初にいくつかの統計を返していたデータベースチェックですが、私はそれを切り取りました。 クエリを「select1」のようなもっと単純なものに切り替えることができ、それをチェックしてもエラーは発生しません。 それが価値があるかどうかわからない。

セッションチェックも特に満足していません。 テストマカロンサーバーを立ち上げて、セッションプロバイダーの起動時にスローされるパニックからrecover（）するか、マカロン/セッションを変更して各にテスト機能を追加しない限り、テストするのは簡単ではないようです。プロバイダー。 今のところ、イライラしてSet-Cookieヘッダーが返されますが、これは特に必要ありません。 マカロンの経験が豊富な人からこれをどこに持っていくかについて、いくつかの意見をいただければ幸いです😞

grafanaがどのように記述されているかを考えると、データソースをチェックすることは、これを試すのに特に賢明ではないようです。 おそらく、通常の監視システムに追加する方が正気です。

同じ問題に直面していましたが、回避策として、専用の認証APIキーを使用してロードバランサーからのAPI呼び出しを使用します。 option httpchkカスタムHTTPヘッダーを設定する便利な「隠し」機能を備えたHAProxyを使用しています。

option httpchk GET /api/org HTTP/1.0\r\nAccept:\ application/json\r\nContent-Type:\ application/json\r\nAuthorization:\ Bearer\ your_api_key\r\n

（1.1ではなくHTTP / 1.0を使用する必要があります。後者ではHostヘッダーを設定する必要があり、HAProxy構成で動的に取得できないためです）。

/api/orgは、オーバーヘッドがほとんどない最も単純なリクエストのようで、HTTP 200を返します。これは、ロードバランサーがまさに必要としているものであり、新しいセッションを作成しません。

この問題に関する進捗状況やPRはありますか？

+1

kubernetesのベストプラクティスとして、これを個別の/ livenessエンドポイントと/ readinessエンドポイントに分割します。 / livenessは、grafana自体が稼働しているかどうかのみを示し、/ readynessは、トラフィックを受信する準備ができているかどうかを示し、依存関係に到達できるかどうかを確認します。

kubernetesでは、活性エンドポイントがプローブされ、200 okで何度も応答に失敗すると、コンテナーが強制終了され、新しいコンテナーと交換されます。 準備エンドポイントは、コンテナーをサービスの一部にし、トラフィックをその方法で送信するために使用されます。 ロードバランサーに追加したり、ロードバランサーから削除したりするようなものです。

+1

/ types Prometheusエンドポイントを追加するのはどうですか？

+1

Amazon ECSなどの一部のサービスでヘルスチェックが必要な場合：
このハックを使用してください：パス/public/img/grafana_icon.svg 、HTTPコード：200。

+1

それまでの間、単純なHTTP code: 200だけを探している場合は、 /login 。 同僚と私はGrafanaをKubernetesクラスターにデプロイしたところ、そのエンドポイントを使用すると、活性/準備状況のプローブに問題なく機能しました。 Google ComputeEngineロードバランサーでも機能します。

誰もがこれを技術的に暗示する方法を知っていると思いますが、重要なのは、外部の依存関係を含むサービスの状態の監視を明示的にサポートすることです。

私のiPhoneから送信された

2016年12月5日には、16:09で、ハンターSatterwhiteの[email protected]は書きました：

単純なHTTPコード200を探している場合は、/ loginを使用してください。 同僚と私はGrafanaをKubernetesクラスターにデプロイしたところ、そのエンドポイントを使用すると、活性/準備状況のプローブに問題なく機能しました。 Google ComputeEngineロードバランサーでも機能します。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

特定のユースケースを追加したいと思います。ユーザーがログインしてグラフを表示できるかどうかを確認するための単純なHTTPエンドポイントが必要です。 /loginなどの静的リソースとエンドポイントを使用してこれがないことを回避できることは知っていますが、Grafanaの内部が期待どおりに実行されていることを確認するものが本当に必要です。 データソースからデータを取得するためにステータスチェックは必ずしも必要ではありません。それらには個別のヘルスチェックがあるためです。

これに+1。

2016年12月5日月曜日午後11時51分、Philip Wernersbach <
[email protected]>書き込み：

特定のユースケースを追加したいと思います。次のような単純なHTTPエンドポイントが必要です。
ユーザーがログインしてグラフを表示できるかどうかを確認します。 私たちは使用できることを知っています
不在を回避するための静的リソースと/ loginなどのエンドポイント
これの、しかし私達は本当にGrafanaがそれをチェックする何かが必要です
内部は期待どおりに実行されています。 必ずしもステータスチェックは必要ありません
個別のヘルスチェックがあるため、データソースからデータを取得するため
それらのための。

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/grafana/grafana/issues/3302#issuecomment-265060171 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AIESgm7BZw3jqs8ElVWU9v7CjtcXBYFwks5rFOm-gaJpZM4Gm4T8
。

-

[画像：TransLoc_logos_gear-blue_600x600.png]

ハンターサッターホワイト

TransLocのリードビルド＆オペレーションエンジニア

セル：252.762.5177 | http://transloc.com http://www.transloc.com/

[画像：ソーシャルメディアアイコン-03.png] https://www.facebook.com/TransLoc/ [画像：
ソーシャルメディアアイコン-04.png] https://www.linkedin.com/company/transloc [画像：
ソーシャルメディアアイコン-02.png] http://www.twitter.com/transloc [画像：ソーシャル
メディアアイコン-01.png] http://www.instagram.com/transloc_inc

そのため、現在4.0には、いくつかの内部メトリックを持つ/ api / metricsエンドポイントがあります。

しかし、問題はこのようなものを要求します

{ "date_sources_ok": True, "database_ok": True, "authorization_ok": True, "grafana_version": "2.5.1" }

ここで期待されることについてのより詳細な説明があればよいでしょう。 APIヘルスコールは、すべての組織のすべてのデータソースでライブチェックを行う必要がありますか？ / health api呼び出しが行われるときに、その場で実行する必要がありますか？
承認OKとはどういう意味ですか？

@torkeloはアイデアを

{
    "ok": false,
    "items": [
        "datasources": {
            "ok": true,
        },
        "database": {
            "ok": false,
            "msg": "Cannot communicate ###.###.###.###/XXXXXXX"
        },
        ...
    ]
}

デフォルトでは、ヘルスチェックはエンドポイントが呼び出されたときにすべてのもののライブチェックを実行します。 ヘルスチェックを特定のものに分離したい場合は、elasticsearchがクラスターヘルスに対して行うようなことを行うことができます。 Thingが外部サービス（承認、データベースなど）の場合、接続テストは最小限で実行され、その他の妥当な健全性チェック（データベースのSELECT 1、承認のLDAPバインドテストなど）が実行されます。

このような出力があると、特定の問題を見つけてそれに応じて出力しながら、監視チェックで問題を全体的にチェックできます。

+1

@torkelo回答が遅れて申し訳ありませんが、質問が表示されました。

TL; DR
@andyfeller彼のコメントで良い仕事をしました、そしてそれは私が心に

Grafanaの監視に使用されるエンドポイント（またはエンドポイント）は、2つの質問に詳細で回答する必要があります。
A）このGrafanaインスタンスは準備ができていますか？
B）このGrafanaインスタンスは、構成の意図に従って期待どおりに実行されていますか？

ここで重要なのは「構成インテント」です。たとえば、管理者がデータソースとして追加する場合、保存された構成が正しいかどうかに関係なく、データソースが利用可能であると期待します。 したがって、構成されたデータソースがGrafanaで利用できない場合、監視エンドポイントはそのように言う必要があり、同じように、非常に便利な「テスト」ボタンが機能します。

飛行機が離陸するという観点から考えると、最初に飛行機が離陸を終えて空中にあることを知る必要があります。次に、飛行機が目的地に向かって期待どおりに飛行していることを知る必要があります（何に入るのはやめましょう。」巡航高度に到達する」とは、;-)）を意味します。

これは、他の人が指摘している/ live / readyや、Elasticsearchモデルの/ health（1）/ state（2）、またはSensu（3）の/ healthと/ infoとある程度比較できます。
私見では1つのエンドポイントで十分ですが、最新のツールで2つのエンドポイントを見ると、私の考えが変わります。 BはAのサブセットであると思うので、まだ説得されていないとしましょう。2つのエンドポイントを使用する代わりに、返されるJSONにそれを反映させます。 次に、Grafanaをクラスター化できるある日、「/ cluster_state」を追加できます。

ここで、各回答の詳細について、これが私の-網羅的ではない-最初の考えです。
詳細：

• ステータス（例：赤/黄/緑）
• ステータスコメント（例：「すべて良好」/「コンポーネントFooを開始できませんでした」/「開始中」）
• バージョン（例：v4.1.1-1）

Bの詳細：

• DBステータス（例：赤/黄/緑）
• DBの詳細（例：「接続できませんでした、認証が正しくありません」、またはxxx.yyyのmySQL v4.1への接続はOKです。zzz ：3306 、スキーマバージョンv34132、はいSQLスキーマはバージョン管理する必要があります（4））
• 認証/承認（例：xx.xx.xx：389へのLDAP接続ok）
• データソース（例：データソース1、タイプGraphite、ステータス赤、ステータスコメント「認証失敗」、データソース2、タイプElasticsearch、ステータス緑、ステータスコメント「すべて良好」）

Bにはさらに多くのことができるので、監視を2つのエンドポイントに分割する方が理にかなっているかもしれません。

エンドポイントが照会されているときに何が起こるか（オンザフライ、APIなど）については、誰が実装するかを延期します。

いくつかの-明らかですか？-アドバイス：

• 監視データの収集に使用されるリソースに十分注意し、インストルメンテーションコードを非常に「保護」し、Grafana管理者が「Grafanaの監視でGrafanaがダウンした」または「Grafanaが監視を開始してからX％遅くなった」状況を回避できるようにします。 。

• 提供された監視データをできるだけ確実に、アラート疲労は疫病です

（1） https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html
（2） https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-state.html
（3） https://sensuapp.org/docs/0.23/api/health-and-info-api.html#the -info-api-endpoint
（4） https://blog.codinghorror.com/get-your-database-under-version-control/

それで、4.2.0がリリースされたばかりで、サービスを調査する方法はまだありませんか？ （k8sクラスターを考えてください）

@torkelo @dynekにはポイントがあると思い
これを間違えないでください。優先順位を教えてくれるわけではありません。監視方法に特化した部分がなければ、アプリケーションを「エンタープライズ対応」にするのは難しいことです。

+1

grafanaの状態をチェックするための簡単なhttpエンドポイントを追加しました。

GET /api/health 
{
  "commit": "349f3eb",
  "database": "ok",
  "version": "4.1.0"
}

データベース（mysql / postgres / sqlite3）に到達できない場合、 databaseフィールドに「失敗」が返されます。 Grafanaは引き続きステータスコード200で応答します。その場合、何が正しいかわかりません。

このエンドポイントで最も重要なことは、セッションが作成されないことです（APIキーまたは基本認証を使用して呼び出さない場合、他のapi呼び出しが行う可能性があります）。

データベースにアクセスできない場合は、ステータスコード503で戻るのが最善ではないでしょうか。

Kubernetesの用途：

200以上400未満のコードは、成功を示します。 その他のコードは失敗を示します。

はい、データベースステータスが失敗したときの503ステータスコードが最適だと思います。更新されます

503は、 /api/healthエンドポイントがKubernetesのreadinessチェックにのみ最適に使用されることを意味します。 このチェックをlivenessに使用すると、データベースの問題によりすべてのポッドが強制終了されます。 データベースチェックを除外するためのクエリパラメータはありますか？

@JorritSalverdaあなたはおそらく使用することができますtcpSocketでチェックlivenessProbe

/metricsは、セッションを作成したり、dbリクエストを発行したりしません。

通常、積極的な準備チェックとリラックスした活性チェックがあり、1秒、1は準備に失敗しますが、60秒10失敗は1成功になります。これにより、問題が発生したときに応答性の高い再ルーティングが可能になりますが、同時に自己回復が可能で、不要なポッドの再起動を防ぎます。 ただし、永続的なDBの問題により再起動が発生し、コンテナの状態が悪いことが原因である場合に実際に役立つ可能性があります。