[转帖]开源的监控技术栈除了ELK,还有InfluxData的TICK

开源的监控技术栈除了ELK,还有InfluxData的TICK

https://cloud.tencent.com/developer/news/357119

来源 | Influxdata

译者 | Key 先森

如何选择合适的工具取决于你正在做的事情。

应用程序是会表达的,而时序数据就是它们的语言之一。DevOps,云计算和容器技术改变了我们编写和运行应用的方式。基于一些列开源项目,InfluxData 及其社区正在致力于提供一套现代化且灵活的监控工具包。

在过去的十年中,容器,虚拟机,云计算改变了一切。这些变化发生快速,我们需要能够应对这种变化速度的环境,应用程序也需要以一种更便于维护的方式继续演进。因此,我们需要理解应用的行为,准备好应对故障,进而改进应用。现在我们已经拥有了相应的工具和技术,只需要将它们集成起来去理解应用如何运行,基础设施如何演进,并最终理解系统故障进而提升性能。

监控日志

我们一直在读日志,也有一些工具能帮助我们理解应用行为。我们做这些是因为:

我们必须信任某些东西。光靠屏幕上的信息,我们是没法理解应用行为的。我们需要知道用户如何使用应用,出现了多少异常。可以跟踪的指标有很多,把它们结合起来才能在我们的系统中建立信任。

我们希望能预测未来。我们希望将预测建立在我们识别出的各类指标和行为上,这样就能够判断我们自身是否在成长,有多少成长,在未来还能够成长多快。有了这些信息,我们可以设计一个方案,或许还能预测一些不太好的事件。

日志样例

系统监控组使用一个叫“tail”的强大命令来读日志。通常,我们的应用通过这种方式表达。至于日志,有一个基础或者说正常状态。如果日志在正常状态下持续输出,那么没问题。如果日志输出地过快或者过慢,那么就有问题了,需要采取纠正措施。

日志并不是理解应用最聪明的方式,但却是最常见的,人人都在用这种方式监控应用。我们现在肯定可以做的更好,不过这个涉及到日志的特性。

日志是描述性的,包含大量信息。将它们保存在数据库中的代价太大。由于日志通常是纯文本格式,它们并不容易索引。这意味着引擎必须努力去理解日志间的关系并且支持搜索信息。如果你有很多日志,或者正在用日志记录应用中发生的一切,你需要一个很好的系统来支持。这很难,但也不是不可能。

有很多工具和服务能够将日志结合并且计算出正在发生的事件,比如 Logstash,Kibana,Elasticsearch,NewRelic,CloudWatch,Graphite 等等。它们中有些是以服务形式提供,有些是开源项目,有些两种形式兼有。关键一点是有很多的选择。

选择日志监控工具

如何选择合适的工具取决于你正在做的事情。有一些场景你需要日志来与人辩论或者仅仅用于存档。既然日志包含正在发生的事件的详细信息,你就可以将日志用于这些场景。当出现一个异常时,你可以断定它的类型。日志更多是用来获取这样的信息的。

然而,在一些其他的场景中,你仅仅想知道应用是如何运行的,比如说日志是变多了还是变少了,异常在时间上又是如何分布的。你并不需要知道究竟发生了什么事,它们为什么发生 -- 你只需要知道应用在行为上有改变就行了。另一方面,你每天同时也在使用时序数据来帮助理解系统行为。时序数据并没有日志那么详细 -- 它们是另一种语言。比如说,CPU、内存的使用率就是时序数据。

你不能仅仅使用时序数据而不使用日志,因为有些问题必须借助日志才能解决。我并不是要在这里辩论日志和时序数据谁更好,因为你很可能两种都需要,它们都有价值。不仅仅两种你都需要,实际上日志就是时序数据的一种形式。如果你用时间序列和值来简化日志,我们可以做一些计算,日志也会更容易索引。

你实际上是在将日志转换成时序数据。想象一下你的应用中有多少登录,多少异常,或者如果你是一家金融公司,有多少笔交易,这些都是时序数据,因为它们是时间点上的一个值,一次登录。它们是时间上的一个分布。这就是时序数据的含义。日志就是可以这样被转换的。这不是一个整数或者一个值,而是从不同角度看的一个日志。

简单说,你可以将日志简化为仅仅一个值以及对应的时间点,你可以将这些时间点进行聚合,比较等等。如果花 10 分钟思考一下你的应用,你能拿到很多时序数据。

另外,所有你能从服务器获得并且使用的资源都是时序数据。你可以使用应用数据统计来可视化它们,进而理解突增的异常率是怎样导致内存使用率上升的。

作为开发者,我们知道,5 年前我们做的所有事情如今会显得很复杂。我们现在的目标是将事情简化。简单的事情更容易解释给别人也容易维护。对于时序数据,我就是这样做的:一个值和一个时间,值是一个数字。有了这种模型,你可以做一些计算,聚合它们,创建一个图表,用代价不那么高昂的方式从应用中提取信息。然而,与 Cassandra,MySQL,MongoDB 这些传统的通用工具相比,InfluxDB 更适合用来处理这类数据,因为它专门为持续查询,保留策略等特定场景提供了功能特性,而不是一套序列和压缩的优化特性。

使用 InfluxDB 作为日志存储

InfluxDB 是一个时序数据库。你可以将应用或服务器产生的所有信息推送到这个数据库。它是一个在 Windows 和 Mac 上都可以下载的 Go 二进制文件,很容易安装和启动。InfluxDB 使用 InfluxQL 表达。这意味着你可以使用与 SQL 很相似的语言来查询这个数据库,而 SQL 你已经很熟悉了,不需要学习另一个新语言。这里是选择 InfluxDB 的一些理由的总结。

容易上手

熟悉的查询语法

无外部依赖

开源

水平可扩展

一套结合紧密的时序数据平台的成员

InfluxDB 拥有很大的用户群和社区。结合以下讨论的 InfluxData 平台的其他组件,InfluxDB 创建了一个全栈监控系统,同时支持非常规时序数据(非固定时间间隔发生的事件)和常规时序数据(固定时间间隔的事件指标),如下。

在 InfluxData,我们做了一系列基准测试来展示为什么你需要选择合适的时序数据库而不是你喜欢的那类数据库。InfluxDB 和其他可对比的数据库间的写性能差异很大。基准测试通常有倾向性,但是我们会通过独立测试尝试将它们变得更客观。参考 InfluxDB 与 Elasticsearch, MongoDB,Cassandra 和 OpenTSDB 的对比基准测试。

搭建现代化监控系统

InfluxData 拥有一套全栈的开源项目 -- Telegraf (https://www.influxdata.com/time-series-platform/telegraf/),InfluxDB (https://www.influxdata.com/time-series-platform/influxdb/) ,Chronograf (https://www.influxdata.com/time-series-platform/chronograf/) 和 Kapacitor (https://www.influxdata.com/time-series-platform/kapacitor/)。 它们在一起构成 TICK 栈。

构建监控或事件系统的完整栈

Telegraf是服务端的一个指标采集和数据发送代理,它是一个可以下载和启动的 Go 二进制文件,使用起来非常简单。你可以在每个服务器上安装一个 Telegraf,将它配置为从所在服务器上采集信息。Telegraf 对各类指标,事件,运行它所在的容器或系统的日志,从第三方 API 拉取的指标甚至通过 StatsD 和 Kafka 消费者服务监听到的指标都提供了集成。Telegraf 是插件化的,并提供输入和输出插件,输出插件可以将指标发送至各类数据仓库,服务,消息队列,比如 InfluxDB,Graphite,OpenTSDB,Datadog,Librato,Kafka,MQTT,NSQ 等等。如果你已经有一个监控系统,并且正在寻找一个强大的采集器,你可以使用 Telegraf。

InfluxDB是存储引擎,可作为所有带有大量时间戳数据使用场景的数据仓库,包括 DevOps 监控,日志数据,应用指标,物联网(IoT)传感器数据以及实时分析数据。所有来自 Telegraf 的指标都可以被发送至 InfluxDB。InfluxDB 可以被配置为仅仅保留特定时长的数据,从系统中自动过期并删除不再需要的数据,这样可以节省机器的存储空间。InfluxDB 还提供了一个类似 SQL 的查询语言来进行数据交互。

Chronograf是 InfluxData 平台 TICK 栈的用户接口组件,在 Chronograf 上可以看到所有存储在 InfluxDB 的数据,这样就能构建健壮的查询和告警。Chronograf 使用简单,包含一些模板和库让你能够迅速构建带有实时可视化数据的仪表盘。你也可以在 Chronograf 上管理 InfluxDB 和 Kapacitor。如果你不打算使用 Chronograf,还有其他实现 InfluxDB 输出插件的项目,包括 Grafana。

Kapacitor是 TICK 栈的本地实时流式数据处理引擎,可以被配置为基于监听到的指标,对正在发生的事件提前采取措施。它可以同时处理来自 InfluxDB 的流式数据和批数据。Kapacitor 允许嵌入自定义逻辑或者用户定义的函数来处理动态阈值告警,对指标进行模式匹配,计算概率统计异常,以及基于告警执行类似动态负载均衡的特定动作。你可以发送 Kapacitor 告警到兼容的 事件管理集成组件,包括 HipChat,OpsGenie,Alerta,Sensu,PagerDuty,Slack 等等。比如,Kapacitor 可以发送一条消息到 PagerDuty,如果夜里发生了问题你可以被通知到,或者发送一条消息到 Slack。

启动 InfluxDB 并运行整个 TICK 栈是相当简单的。你可以运行二进制文件或者 Docker 容器,这样一个监控系统就正常运转了。但是一个监控系统真正的目标是当基础设施出问题或者应用宕机时通知你。如果你的监控系统和服务器一起宕掉了,那么它就没有正常工作。所以你需要信任你的监控系统。你需要将它与应用以及基础设施解耦,这样你能 100% 确定当应用和服务器宕掉时监控系统仍然能正常工作。你需要知道这不是一个简单的目标,也不仅仅意味着一些 Docker 运行命令。

不是人人都能管理一个监控系统

参考链接:

https://www.influxdata.com/time-series-platform/telegraf/

https://www.influxdata.com/time-series-platform/influxdb/

https://www.influxdata.com/time-series-platform/chronograf/

https://www.influxdata.com/time-series-platform/kapacitor/

  • 发表于: 2018-11-16
  • 原文链接:https://kuaibao.qq.com/s/20181116B0PN3B00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

原文地址:https://www.cnblogs.com/jinanxiaolaohu/p/11294571.html

时间: 2024-11-05 11:30:00

[转帖]开源的监控技术栈除了ELK,还有InfluxData的TICK的相关文章

TICK技术栈 -- DevOps轻量级监控解决方案

了解和学习TICK栈不久,还有很多需要进一步深入.但我个人非常看好这个项目,也希望更进一步研究,可能的话,会在生产环境谨慎和大胆地尝试一下.同时,在阅读源码和二次开发中,希望技术上能有所提升. TICK技术栈 简介 T = Telegraf is a plugin-driven server agent for collecting and reporting metrics. I = InfluxDB is a time series database built from the groun

开源IT监控系统对比

应邀对开源IT监控系统进行对比,选取了Nagios.Cacti.Zenoss.Zabbix.Hyperic HQ做为对比样本,帮助读者选择开源的IT监控系统作为底层,开发所需的监控运维工具. 1 背景和目标 1.1 前言 随着SaaS.P2P等各类在线应用的兴起,使得各类在线应用服务公司采购了大量的服务器等IT设施.而如何对庞大的IT设施进行有效的监控和管理,一直是很头疼的问题.以往,网络监控软件都是商业软件的天下,主要是BMC Patrol.CA Unicenter.HP OpenView或I

转: 拒绝「技术栈」选择恐惧症

所谓最小化可行产品(Minimum Viable Product,MVP),就是将产品快速推向客户,从客户反馈中不断进行迭代.更重要的是,MVP 也是研发团队进一步完善产品的基础. 但是,在正式代码之前,你需要选择今后支撑产品的 技术栈,也就是要选择好整个产品每一层所要应用的技术语言.架构等. 技术栈的选择往往是创始人面临的艰难问题.无论是技术人员还是非技术人员,如果不具体了解每个语言和架构的特点,面对现在如此多元化的IT技术,简直能逼死纠结症患者.而且,如果选错了语言或者框架,很可能会导致较为

百亿互金平台技术栈大起底

技术栈(technology stack)就是一个公司的透视镜,从某些程度上可以展示出公司的技术实力.从技术桟也可以看出整个平台的技术要素,平台大小规模等,今天来给大家分享我司的技术全家桶. 题外话 今天是一个特殊的日子,我就多说两句,2017年过半了,大家的年终计划都执行的怎么样?而对于我还有另一层的意思,就是我终于要离职了. 今天是我在这家公司的最后一个工作日.以前每次和朋友聚会都会问,最近发展的怎么样,在那家公司?我说还在xx,他们就开玩笑说,强哥你准备把公司干倒呀.从写下一行代码到成为公

一个可供中小团队参考的微服务架构技术栈

一个可供中小团队参考的微服务架构技术栈 聊聊架构 2018-05-07 作者 杨波 作者 |  杨波编辑 |  张浩 近年,Spring Cloud 俨然已经成为微服务开发的主流技术栈,在国内开发者社区非常火爆.我近年一直在一线互联网公司(携程,拍拍贷等)开展微服务架构实践,根据我个人的一线实践经验和我平时对 Spring Cloud 的调研,我认为 Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离.比方说 Spring Cloud Config 和 Spring Cloud

【干货】微服务技术栈选型手册2.0

一.前言 2014年可以认为是微服务1.0的元年,当年有几个标志性事件,一是Martin Fowler在其博客上发表了"Microservices"一文,正式提出微服务架构风格:二是Netflix微服务架构经过多年大规模生产验证,最终抽象落地形成一整套开源的微服务基础组件,统称NetflixOSS,Netflix的成功经验开始被业界认可并推崇:三是Pivotal将NetflixOSS开源微服务组件集成到其Spring体系,推出Spring Cloud微服务开发技术栈. 一晃三四年过去,

微服务架构技术栈选型手册¶

微服务架构技术栈选型手册 2014~2018,微服务经过三年的发展,现状如何?这是一份为让你更好使用微服务的技术站选型手册.除此之外,你还可以按需选用配套的微服务架构视频内容. 一.前言 2014 年可以认为是微服务 1.0 的元年,当年有几个标志性事件,一是 Martin Fowler 在其博客上发表了"Microservices"一文,正式提出微服务架构风格:二是 Netflix 微服务架构经过多年大规模生产验证,最终抽象落地形成一整套开源的微服务基础组件,统称 NetflixOS

大数据技术栈

大数据技术栈 Hadoop 历史: https://www.jikexueyuan.com/course/677_1.html?ss=1 1. Google大数据与Hadoop对比 功能 Google Hadoop 存储 GFS HDFS 计算 MapReduce MapReduce 查询 BigTable HBase 2. 大数据分类 2.1 根据数据类型分类 2.1.1 结构化数据 能够用数据或统一的结构加以表示,人们称之为结构化数据,如数字.符号.传统的关系数据模型,行数据,存储于数据库,

.Net 微服务架构技术栈的那些事

一.前言 大家一直都在谈论微服务架构,园子里面也有很多关于微服务的文章,前几天也有一些园子的朋友问我微服务架构的一些技术,我这里就整理了微服务架构的技术栈路线图,这里就分享出来和大家一起探讨学习,同时让新手对微服务相关技术有一个更深入的了解. 二.技术栈 2.1 工欲善其事,必先利其器 现在互联网盛行的年代,互联网产品也层出不穷,受欢迎的互联网产品都有一个比较牛的技术团队,我这里分享下.net 微服务架构技术栈图如下: 俗话说得好:工欲善其事,必先利其器.一个优秀的工程师应该善于使用框架和工具,