redis集中监控_集中记录和监控

redis集中监控

我的生活充满混乱，这很正常。 您已经习惯了。 您只需要放松，平静下来，深吸一口气，然后试着看看如何使事情有效，而不必抱怨事情错了。 —汤姆·威灵

监视单个服务器上的许多服务会带来一些困难。 监视许多服务器上的许多服务需要一种全新的思维方式和一套新的工具。 随着您开始接受微服务，容器和集群，已部署容器的数量将开始Swift增加。 对于构成集群的服务器也是如此。 我们再也无法登录到节点并查看日志。 有太多日志需要查看。 最重要的是，它们分布在许多服务器之间。 昨天我们在一个服务器上部署了两个服务实例，明天我们可能将八个实例部署到了六个服务器。 监视也是如此。 诸如Nagios之类的旧工具并非旨在处理正在运行的服务器和服务中的不断变化。 我们已经使用Consul，当达到阈值时，Consul提供了一种不同的方法（更不用说新的方法）来管理近实时监视和响应。 但是，这还不够。 实时信息对于检测出故障是有价值的，但它并不能为我们提供故障发生原因的信息。 我们可以知道服务没有响应，但是我们不知道为什么。

我们需要有关系统的历史信息。 该信息可以采用日志，硬件利用率，运行状况检查和许多其他形式。 存储历史数据的需求并不是新鲜的，并且已经使用了很长时间。 但是，信息传播的方向随时间而改变。 过去，大多数解决方案都基于集中式数据收集器，而如今，由于服务和服务器的动态特性，我们倾向于将数据收集器分散。

集群日志记录和监视所需的是分散的数据收集器的组合，这些收集器将信息发送到集中的解析服务和数据存储。 从内部部署到云解决方案，以及介于两者之间的所有内容，都有许多专门设计用来满足此要求的产品。 FluentD ， Loggly ， GrayLog ， Splunk和DataDog只是我们可以采用的一些解决方案。 我选择通过ELK堆栈（ ElasticSearch ， LogStash和Kibana ）向您展示这些概念。 该协议栈的优点是免费，有据可查，高效且广泛使用。 ElasticSearch已将自己确立为实时搜索和分析的最佳数据库之一。 它是分布式的，可伸缩的，高度可用的，并提供完善的API。 LogStash使我们能够集中数据处理。 它可以轻松扩展为自定义数据格式，并提供了许多可以满足几乎所有需求的插件。 最后， Kibana是一个分析和可视化平台，其直观界面位于ElasticSearch之上。 我们将使用ELK堆栈这一事实并不意味着它比其他解决方案要好。 这完全取决于特定的用例和特定需求。 我将向您介绍使用ELK堆栈进行集中日志记录和监视的原理。 一旦理解了这些原理，您便可以选择将它们应用于其他堆栈。

在讨论集中式日志记录的需求之前，我们改变了顺序并选择了工具。 让我们对此进行补救。

集中记录的需求

在大多数情况下，日志消息将写入文件。 这并不是说文件是唯一，也不是最有效的日志存储方式。 但是，由于目前大多数团队都以一种或另一种形式使用基于文件的日志，所以我也认为这也是您的情况。

如果幸运的话，每个服务或应用程序只有一个日志文件。 但是，我们的服务通常会将多个文件输出到这些文件中。 在大多数情况下，我们不太在乎日志中写的内容。 当一切运行良好时，不需要花费宝贵的时间浏览日志。 日志不是我们为了打发时间而读的小说，也不是我们花费时间作为提高知识水平的技术书。 当某处出现问题时，日志可以提供有价值的信息。

情况似乎很简单。 我们将信息写入大多数时间都被忽略的日志中，并且当出现问题时，我们会立即咨询它们并找出问题的原因。 至少，这就是许多人所希望的。 现实要复杂得多。 在除大多数琐碎的系统之外的所有系统中，调试过程要复杂得多。 应用程序和服务几乎总是相互连接的，并且常常不容易知道是哪个引起了问题。 尽管它可能出现在一个应用程序中，但调查通常表明原因是在另一个应用程序中。 例如，服务可能无法实例化。 花了一些时间浏览其日志后，我们可能会发现原因在数据库中。 该服务无法连接到它并无法启动。 我们得到了症状，但没有原因。 我们需要切换到数据库日志才能找到它。 通过这个简单的示例，我们已经了解到仅查看一个日志是不够的。

对于在群集上运行的分布式服务，情况将成倍地复杂化。 服务的哪个实例失败？ 它在哪台服务器上运行？ 发起请求的上游服务是什么？ 罪魁祸首所在的节点中的内存和硬盘使用量是多少？ 正如您可能已经猜到的那样，找到，收集和过滤成功发现原因所需的信息通常非常复杂。 系统越大，越难获得。 即使是单片应用程序，事情也很容易失控。 如果采用（微）服务方法，那么这些问题就会成倍增加。 除了最简单和最小的系统，集中式日志记录是必不可少的。 相反，当发生问题时，我们许多人开始从一台服务器运行到另一台服务器，然后从一个文件跳到另一个文件。 就像头被割断的鸡一样-无方向奔跑。 我们倾向于接受伐木带来的混乱，并将其视为我们职业的一部分。

我们在集中式日志记录中寻找什么？ 碰巧的是，有很多事情，但最重要的如下。

• 一种解析数据并将其几乎实时发送到中央数据库的方法。
• 数据库处理近实时数据查询和分析的能力。
• 通过过滤的表格，仪表板等以可视方式表示数据。

ELK堆栈（LogStash，ElasticSearch和Kibana）可以完成所有操作，并且可以轻松扩展以满足我们摆在我们面前的特殊需求。

现在，我们对要完成的任务有一个模糊的想法，并且拥有实现该目标的工具，让我们探索一些可以使用的日志记录策略。 我们将从最常用的场景开始，然后逐步向定义我们的日志记录策略的更复杂，更有效的方法过渡。

DevOps 2.0工具包

本文是《 DevOps 2.0工具包：使用容器化微服务实现持续部署管道自动化》一书的“ 集中式日志记录和监视”一章的开始。

本书介绍了不同的技术，这些技术可以帮助我们更好，更高效地构建软件，并将微服务包装成不可变的容器 ，并进行测试并连续部署到由配置管理工具自动 配置的服务器上。 它是关于零停机时间和回滚能力的快速，可靠和连续的部署。 它涉及到可扩展到任意数量的服务器，能够从硬件和软件故障中恢复的自我修复系统的设计以及有关群集的集中式日志记录和监视 。

换句话说，这本书使用一些最新和最好的实践和工具来涵盖整个微服务开发和部署生命周期 。 我们将使用Docker，Kubernetes，Ansible，Ubuntu，Docker Swarm和Docker Compose，Consul，etcd，Registrator，confd，Jenkins等。 我们将介绍许多实践，甚至更多的工具。

该书可从LeanPub和Amazon（ Amazon.com和其他全球站点）获得。

翻译自: https://www.javacodegeeks.com/2016/02/centralized-logging-monitoring.html

redis集中监控