如何高效应对集群异常及机器性能波动问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1561个文字，预计阅读时间需要7分钟。
如何通过可视化工具有效监测集群状态，快速解决线上集群的异常故障？本文为你带来一种新思路。
原文首发于Nebula Graph社区公众号，从集群性能波动讲起，前几天，我们收到某用户的反馈：...
（此处省略部分内容，总字数不超过100字）
如何通过可视化工具有效监测集群状态，从而快速解决线上集群的异常故障，本文给你带来一个新思路。从集群性能波动讲起本文首发于 Nebula Graph Community 公众号
前几天，我们收到某公司 Nebula 数据库维护人员小张同学的反馈：发现集群 A 性能波动，同样的语句有时查询快，但是有时慢，帮忙看看是机器还是服务本身的问题呢？
想到了小张同学之前安装过 Nebula Dashboard 社区版，便推荐他进去查看监控情况。小张进入平台后，查看当前机器的 CPU、内存、磁盘、网络情况，发现同之前相比并没有明显异常情况，机器们都在正常运行。如下图所示：
但，你如果仔细查看这张图，会发现集群 A 个别时间段确实存在网络和 CPU 使用率飙升的问题。
于是，我们继续让小张再查看该集群的服务运行情况，发现在这段时间内查询数量会突然激增，而且有周期性。如下图：
发现周期性问题之后，我们询问小张在这个时间段该集群的使用场景。经排查发现，小张同学在这个时间每天会有定期运行一个数据库 nGQL 执行脚本。经他重新 review 脚本逻辑，发现查询中涉及多跳查询并且跳数超过 5 跳。问题定位后，小张建议相关的业务同学对语句脚本进行了优化解决了资源波动问题。
让人头疼的集群问题解决了这个问题，小张同学又向我们提出了新问题：我能及时感知集群内的服务和机器的异常情况吗？我是不是可以接入告警服务，通过钉钉、微信、短信方式告知服务异常？
碰巧的是，另一个公司团队的小刘也反馈了个异常问题：某个集群连接不上，不知道是不是服务挂了。而且对外业务流量入口现在已经关闭了，怎么排查问题呢？由于 Nebula Dashbaord 社区版并未提供查看集群状态管理功能，在我们发现服务的监控查询数确实都是 0 之后，建议小刘同学挨个检查机器。小刘检查之后，反应集群 A 的机器能正常登录，但挨个查看发现端口的 graphd 和 storaged 服务并不在线，存在服务异常情况。为了不影响业务正常运行，小刘需要一个个手动启动服务异常的机器，花费了他不少启停时间。经过这次之后，小刘说他打算写个集群快速启动脚本，不然每次手动启停太麻烦。
无独有偶，除了上面两个运维同学反馈的问题之外，其实，我们还收到了这样的反馈：流量小的情况下，集群正常运行；一旦流量超过某个阈值，便会发生服务连不上、连接超时、某个查询服务离线等等问题…一般来说，因为集群服务比例分布不合理、分片不均的情况，集群或存在某台机器一直处在高负载状态。以上面这位同学为例，他平时业务流量比较均衡，但最近刚好是某个活动期，参与了多项推广活动，流量骤升是平时流量的几百倍。基于这种情况，我们建议他对集群进行弹性扩容，增加 5 台服务以应对突发的大流量。这波活动过去之后，再缩容，节省成本。
其实集群除了弹性扩缩容问题之外，常见以下几类反馈：
1：如何快速创建集群，默认 3 节点配置就好？
2：我能看到某台集群某个时间段的操作记录吗?
3：我能删除某个集群，并回收资源吗？
4：昨天查看日志信息，我发现集群 B 的存储服务 storaged2 启停了一次，能帮忙排查是什么问题问题造成的吗？是否后续上生产环境也会出现？
5：graph 服务查不到，怎么定位问题？
6：集群的某个服务能查到，但是状态一直是退出状态，怎么快速拉起？
基于用户的各种场景反馈，我们计划打造一款比 Dashboard 社区版更便捷管理 Nebula 数据库集群的工具——是的，它便是今天的主角 Nebula Dashboard 企业版，上面提到的那些集群问题以及性能波动问题，在新发布的 Nebula Dashboard v3.0 面前均不是问题：Nebula Dashboard 企业版，专治集群的疑难杂症。
为了让数据库运维、DBA 同学更方便地管理 Nebula 数据库集群，基于社区版的 Nebula Dashboard 我们扩展多个功能场景，这里可以简单介绍下部分功能，更多信息可以
本文共计1561个文字，预计阅读时间需要7分钟。
如何通过可视化工具有效监测集群状态，快速解决线上集群的异常故障？本文为你带来一种新思路。
原文首发于Nebula Graph社区公众号，从集群性能波动讲起，前几天，我们收到某用户的反馈：...
（此处省略部分内容，总字数不超过100字）
如何通过可视化工具有效监测集群状态，从而快速解决线上集群的异常故障，本文给你带来一个新思路。从集群性能波动讲起本文首发于 Nebula Graph Community 公众号
前几天，我们收到某公司 Nebula 数据库维护人员小张同学的反馈：发现集群 A 性能波动，同样的语句有时查询快，但是有时慢，帮忙看看是机器还是服务本身的问题呢？
想到了小张同学之前安装过 Nebula Dashboard 社区版，便推荐他进去查看监控情况。小张进入平台后，查看当前机器的 CPU、内存、磁盘、网络情况，发现同之前相比并没有明显异常情况，机器们都在正常运行。如下图所示：
但，你如果仔细查看这张图，会发现集群 A 个别时间段确实存在网络和 CPU 使用率飙升的问题。
于是，我们继续让小张再查看该集群的服务运行情况，发现在这段时间内查询数量会突然激增，而且有周期性。如下图：
发现周期性问题之后，我们询问小张在这个时间段该集群的使用场景。经排查发现，小张同学在这个时间每天会有定期运行一个数据库 nGQL 执行脚本。经他重新 review 脚本逻辑，发现查询中涉及多跳查询并且跳数超过 5 跳。问题定位后，小张建议相关的业务同学对语句脚本进行了优化解决了资源波动问题。
让人头疼的集群问题解决了这个问题，小张同学又向我们提出了新问题：我能及时感知集群内的服务和机器的异常情况吗？我是不是可以接入告警服务，通过钉钉、微信、短信方式告知服务异常？
碰巧的是，另一个公司团队的小刘也反馈了个异常问题：某个集群连接不上，不知道是不是服务挂了。而且对外业务流量入口现在已经关闭了，怎么排查问题呢？由于 Nebula Dashbaord 社区版并未提供查看集群状态管理功能，在我们发现服务的监控查询数确实都是 0 之后，建议小刘同学挨个检查机器。小刘检查之后，反应集群 A 的机器能正常登录，但挨个查看发现端口的 graphd 和 storaged 服务并不在线，存在服务异常情况。为了不影响业务正常运行，小刘需要一个个手动启动服务异常的机器，花费了他不少启停时间。经过这次之后，小刘说他打算写个集群快速启动脚本，不然每次手动启停太麻烦。
无独有偶，除了上面两个运维同学反馈的问题之外，其实，我们还收到了这样的反馈：流量小的情况下，集群正常运行；一旦流量超过某个阈值，便会发生服务连不上、连接超时、某个查询服务离线等等问题…一般来说，因为集群服务比例分布不合理、分片不均的情况，集群或存在某台机器一直处在高负载状态。以上面这位同学为例，他平时业务流量比较均衡，但最近刚好是某个活动期，参与了多项推广活动，流量骤升是平时流量的几百倍。基于这种情况，我们建议他对集群进行弹性扩容，增加 5 台服务以应对突发的大流量。这波活动过去之后，再缩容，节省成本。
其实集群除了弹性扩缩容问题之外，常见以下几类反馈：
1：如何快速创建集群，默认 3 节点配置就好？
2：我能看到某台集群某个时间段的操作记录吗?
3：我能删除某个集群，并回收资源吗？
4：昨天查看日志信息，我发现集群 B 的存储服务 storaged2 启停了一次，能帮忙排查是什么问题问题造成的吗？是否后续上生产环境也会出现？
5：graph 服务查不到，怎么定位问题？
6：集群的某个服务能查到，但是状态一直是退出状态，怎么快速拉起？
基于用户的各种场景反馈，我们计划打造一款比 Dashboard 社区版更便捷管理 Nebula 数据库集群的工具——是的，它便是今天的主角 Nebula Dashboard 企业版，上面提到的那些集群问题以及性能波动问题，在新发布的 Nebula Dashboard v3.0 面前均不是问题：Nebula Dashboard 企业版，专治集群的疑难杂症。
为了让数据库运维、DBA 同学更方便地管理 Nebula 数据库集群，基于社区版的 Nebula Dashboard 我们扩展多个功能场景，这里可以简单介绍下部分功能，更多信息可以