Grafana: 监控Grafana

++

：+1：

确保运行状况URL不会生成会话

：+1：

+1，这对于在loadbalancer后面运行grafana很有用，loadbalancer会调用/ health HTTP来验证grafana返回HTTP 200 OK。

我已经整理了一些简单的东西，但是我现在对此并不特别满意。

如果有人想看一下当前状态与主状态： https :

它返回类似：

{"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"}}

我最初返回的数据库检查是一些统计信息，但是我已经删除了。 我可以将查询切换到更简单的查询，例如“ select 1”，并检查它是否没有错误。 不确定是否值得。

会话检查我都不满意。 如果不站起测试Macaron服务器并从启动会话提供程序或修改macaron /会话以向每个服务器中添加测试功能时会引发的恐慌中恢复（），似乎很难进行测试。提供者。 就目前而言，它令人烦恼的是返回了Set-Cookie标头，我并不是特别想要的。 我希望从Macaron经验丰富的人那里得到一些建议，以供参考。

考虑到grafana的编写方式，检查数据源似乎并不是特别明智的尝试。 添加到常规监视系统中可能更为明智。

我面临着相同的问题，并且作为一种解决方法，我使用了来自负载均衡器的API调用以及专用的身份验证API密钥。 我正在使用HAProxy，它具有在option httpchk中设置自定义HTTP标头的一些有用的“隐藏”功能：

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

（我需要使用HTTP / 1.0而不是1.1，因为后者需要设置Host标头，而我无法在HAProxy配置中动态获取它）。

/api/org似乎是最简单的请求，几乎没有开销，并且返回HTTP 200，这正是负载均衡器所需要的-并且不会创建任何新会话。

在这个问题上有进展或公关吗？

+1

我会将其分为一个单独的/ liveness和/ readiness端点，这是kubernetes中的最佳实践。 / liveness仅指示grafana本身是否已启动并正在运行，/ readiness指示其是否已准备好接收流量，并将检查其依存关系是否可达。

在kubernetes中，将检测活动性端点，并在多次失败后以200 ok响应时，该容器将被杀死并替换为新容器。 准备就绪端点用于使容器成为服务的一部分，并按自己的方式发送流量。 就像从负载均衡器中添加和删除它一样。

+1

添加/ metrics Prometheus端点怎么办？

+1

对于需要对某些服务（例如Amazon ECS）进行健康检查的人：
使用此技巧：路径/public/img/grafana_icon.svg ，HTTP代码：200。

+1

同时，如果您只寻找简单的HTTP code: 200 ，则只需使用/login 。 我和我的同事刚刚将Grafana部署到Kubernetes集群，并且使用该端点可以很好地进行活动性/就绪性探测。 也适用于Google Compute Engine负载平衡器。

认为每个人都知道如何从技术上暗示这一点，但重点是要明确支持对服务运行状况的监视，包括外部依赖项。

从我的iPhone发送

2016年12月5日下午4：09，Hunter Satterwhite [email protected]写道：

如果您要查找一个简单的HTTP代码：200，则只需使用/ login。 我和我的同事刚刚将Grafana部署到Kubernetes集群，并且使用该端点可以很好地进行活动性/就绪性探测。 也适用于Google Compute Engine负载平衡器。

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在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
。

-

[image：TransLoc_logos_gear-blue_600x600.png]

猎人萨特怀特

TransLoc首席构建和运营工程师

手机：252.762.5177 | http://transloc.com http://www.transloc.com/

[image：社交媒体icons-03.png] https://www.facebook.com/TransLoc/ [image：
社交媒体图标-04.png] https://www.linkedin.com/company/transloc [image：
社交媒体icons-02.png] http://www.twitter.com/transloc [image：社交
media icons-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调用时，是否应该即时完成？
授权确定是什么意思？

@torkelo提出一个想法，但绝对认为/ health应该允许grafana-server和已安装的插件注册任意东西以进行报告：

{
    "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进行比较。
恕我直言，一个端点就足够了，但是在大多数现代工具中看到两个端点正在改变我的想法。 只是说我还没有被说服，因为我认为B是A的子集，因此我将使返回的JSON能够反映出这一点，而不是具有2个端点。 然后可以在Grafana可以群集的一天添加“ / cluster_state”。

现在，关于每个答案的细节，这是我的-非详尽的初步想法：
详细说明：

• 状态（例如红色/黄色/绿色）
• 状态注释（例如“一切都很好” /“无法启动组件Foo” /“正在启动”）
• 版本（例如v4.1.1-1）

B细节：

• 数据库状态（例如，红色/黄色/绿色）
• 数据库详细信息（例如“无法连接，错误身份验证”，或在xxx.yyy。zzz ：3306 ，模式版本v34132处可以正常连接到mySQL v4.1，应该对SQL模式进行版本控制（4））
• 身份验证/授权（例如，与xx.xx.xx的LDAP连接：389正常）
• 数据源（例如，数据源1，类型为Graphite，状态为红色，状态注释为“身份验证失败”，数据源2，类型为Elasticsearch，状态为绿色，状态注释为“所有良好”）

B中还有很多可以做的事情，这就是为什么将监视分为两个端点可能更有意义，嗯。

至于如何处理在查询端点（运行中，API等）时会发生什么，我会顺从到底谁来实现。

几个-很明显吗？-但建议：

• 要非常注意用于收集监视数据的资源，并对工具代码非常“保护”，帮助Grafana管理员避免“我对Grafana的监视使Grafana崩溃了”或“自从我开始监视它以来，Grafana的速度降低了X％” 。

• 在提供的监视数据上尽可能确定，警报疲劳是一个困扰

（1） https://www.elastic.co/guide/zh-CN/elasticsearch/reference/current/cluster-health.html
（2） https://www.elastic.co/guide/zh-CN/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有一点，这不再是可选的。 无论是文档中专门介绍“如何监视Grafana”的新部分，其中记录了今天可以使用现有工具（例如，杠杆管理或指标页面）执行的操作，还是完整的专用API（如本提案中所述），我们昨天都需要。
请不要采取这种错误的方式，我的意思不是要告诉您应该优先考虑的事情，这仅仅是让应用程序“面向企业就绪”的艰难销售，而没有专门的方法来监控它。

+1

添加了一个简单的http端点来检查grafana健康状况：

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

如果无法访问数据库（mysql / postgres / sqlite3），它将在database字段中返回“失败”。 Grafana仍将以状态码200回答。不确定在这种情况下正确的方法。

关于此端点的最重要的事情是，它将永远不会导致创建会话（如果您不使用api密钥或基本身份验证来调用其他api，则可能会执行某些操作）。

当数据库无法访问时，最好返回状态码503吗？

Kubernetes使用：

任何大于或等于200且小于400的代码均表示成功。 其他任何代码均表示失败。

是的，我认为当db status失败时的503状态码是最好的，它将更新

503表示/api/health端点最好仅用于Kubernetes中的readiness支票。 如果此检查用于liveness ，则数据库问题将导致所有吊舱被杀死。 是否有查询参数可以省去数据库检查？

@JorritSalverda，您可能可以在livenessProbe使用tcpSocket支票

/metrics不会创建会话或发出数据库请求。

我们通常会进行积极的准备情况检查和轻松的活动检查，1秒，1次准备失败，而60秒10次失败，1次成功，这样可以在出现问题时进行响应式重新路由，但同时如果发生自我恢复，可能，防止不必要的Pod重新启动。 但是，持久性数据库问题将导致重新启动，如果由于某些不良的容器状态而导致重新启动，则实际上可能会有所帮助。