江苏龙网

  1. 首页 > 资讯 > 科技 > >

[数据]Grafana VS Kibana VS Knowi：大逃杀2020( 二 )


Grafana正式支持与14种数据源集成 ， 例如MySQL ， Graphite ， InfluxDB ， PostgreSQL和Prometheus 。另一方面 ， Knowi支持36种不同的数据源 ， 包括Oracle ， MySQL ， MongoDB ， PostgreSQL ， Elasticsearch等 。这些只是列出的本机集成 。凭借其连接到任何REST API的能力 ， 可能的数据源总数是无限的 。
从多个数据源中挖掘数据的能力使Grafana和Knowi成为各种日志管理体系结构的真正灵活选择 。
但是 ， Kibana仅支持与Elasticsearch集成 。它看起来像是Kibana的一个很大的缺点 ， 但是从积极的方面来说 ， 如果您的项目仅使用Elasticsearch（并且您不认为它将来会扩展以包含更多的数据源） ， 那么您应该考虑将Kibana紧密地结合在一起 在ELK堆栈中 。
但是 ， Grafana和Knowi仍然完全支持Elasticsearch集成 ， 并且如果针对特定用例提供了更多支持 ， 则可以考虑将它们考虑在Kibana上 。日志搜索和分析
在进行一些分析或调试时 ， 您可能需要搜索日志 。Knowi和Kibana都支持查询文本数据 。因此 ， 可以使用这两个工具执行日志分析 。但是 ， 该支持目前在Grafana中不存在 ， 被视为选择该平台的主要缺点 。
一个查询案例可能是您选择在Grafana上选择Knowi或Kibana的一个很好的理由 ， 如果您打算为技术支持团队构建一个监视解决方案 ， 以分析日志中的问题 。在这种用例中 ， 文本数据查询将是必不可少的 。主动警报
监视敏感系统的一个关键方面是主动检测某些问题 ， 以便可以在导致严重后果之前提前采取措施 。例如 ， 我们可以设置一个规则 ， 以在服务器内存利用率超过90％时发送警报 。这将有助于运营团队降低内存利用率 ， 从而避免系统上的任何不必要的中断 。
Grafana和Knowi都具有内置功能 ， 可针对我们可以定义的一组规则引发警报 。但是 ， Kibana不提供对警报的支持 。相反 ， 它需要第三方集成来启用警报 。用户授权
在拥有许多用户和涉众的大型企业中 ， 您不希望所有用户都访问数据 。即使对于监视仪表板也是如此 。您希望某些用户仅访问某些仪表板 。或者 ， 您的要求是创建特定于某些用户的仪表板 。
好消息是Grafana和Knowi都提供了开箱即用的用户管理功能 。您可以创建用户和角色 ， 并授权对它们的特定仪表板访问 。
Kibana不提供任何用户管理功能 。这意味着拥有指向Kibana仪表板链接的任何人都可以看到数据 。这可能并不总是一种好的工作方式 。但是可以节省的好处是 ， 我们仍然可以借助第三方集成在Kibana中实现用户和角色限制 。在线社区
Grafana和Kibana都是开源的 ， 并且正在GitHub上积极开发 。这意味着如果需要 ， 可以为两者提供良好的在线社区支持 。如果必须衡量两个项目的受欢迎程度 ， 那么值得注意的是 ， 在Github上 ， Kibana的提交数量要超过Grafana 。
但是 ， Knowi当前不是开源工具 。他们仍然在自己的网站上拥有自己的论坛 ， 您可以在其中寻求其他用户的帮助 。但是他们在社区中缺乏的东西可以通过客户支持来弥补 。作为一家相对年轻的初创企业 ， 他们希望自己出名 ， 他们拥有一支充满活力 ， 反应迅速且积极进取的解决方案工程师团队 ， 以证明他们的产品是市场上最好的 。机器学习
当前 ， 机器学习正在全球范围内所有有数据的可能空间中入侵 。如果您拥有大量的大数据 ， 您将不会错过应用机器学习从数据中获取隐藏的见解和模式的机会 。想象一下 ， 如果您可以提前很好地从日志数据中预测任何潜在风险并采取预防措施 。这可以使日志监视过程达到一个全新的水平 。
不幸的是 ， Kibana和Grafana都不支持机器学习 。但是Knowi已与许多机器学习算法（例如分类 ， 回归和时间序列异常检测类型机器学习用例）进行了内置集成 ， 即将推出集群和深度学习 。
这使Knowi用户可以使用机器学习进行预测分析 ， 并基于监视工作流中的预测来设置触发警报 。目的考虑


推荐阅读


上一篇：天津港保税区发布【科技创新】优投空间(天津港保税区)启动仪式成功举办

下一篇：阿里■原创 丰巢还在涨价，菜鸟继续免费，顺丰第二次叫板阿里又没成功！