应用程序是会表达的，而时序数据就是它们的语言之一。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，InfluxDB ，Chronograf 和 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 运行命令。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论