随着动态系统架构的复杂性和规模的增加，IT 团队面临着越来越大的压力来跟踪和响应其多云环境中的条件和问题。因此，IT 运营、DevOps 和 SRE 团队都在寻找对这些日益多样化和复杂的计算环境的更高可观察性。

但什么是可观察性？为什么它很重要，它实际上可以帮助组织实现什么？

什么是可观察性？

在 IT 和云计算中，可观察性是根据系统生成的数据（例如日志、指标和跟踪）来衡量系统当前状态的能力。

可观察性依赖于源自多云计算环境中端点和服务的仪器的遥测。在这些现代环境中，每个硬件、软件和云基础架构组件以及每个容器、开源工具和微服务都会生成每个活动的记录。可观察性的目标是了解所有这些环境和技术之间正在发生的事情，这样您就可以检测和解决问题，以保持您的系统高效和可靠，让您的客户满意。

组织通常使用包括开源仪器工具（如 OpenTelemetry）在内的仪器方法组合来实现可观察性。

许多组织还采用可观察性解决方案来帮助他们检测和分析事件对其运营、软件开发生命周期、应用程序安全和最终用户体验的重要性。

近年来，可观察性变得越来越重要，因为云原生环境变得更加复杂，并且故障或异常的潜在根本原因变得更加难以查明。随着团队开始收集和使用可观察性数据，他们也意识到它对业务的好处，而不仅仅是 IT。

由于云服务依赖于独特的分布式和动态架构，因此可观察性有时也可能指企业用来解释云性能数据的特定软件工具和实践。尽管有些人可能将可观察性视为复杂应用程序性能监控 (APM) 的流行词，但在比较可观察性和监控时需要牢记一些关键区别。

监控和可观察性有什么区别？

可观察性真的是用另一个名字来监控吗？简而言之，没有。虽然可观察性和监控是相关的——并且可以相互补充——但它们实际上是不同的概念。

在监控场景中，您通常会预先配置仪表板，这些仪表板旨在提醒您稍后会看到的性能问题。但是，这些仪表板依赖于一个关键假设，即您能够在问题发生之前预测您会遇到哪些类型的问题。

云原生环境不适合这种类型的监控，因为它们是动态且复杂的，这意味着您无法提前知道可能会出现什么样的问题。

在可观察性场景中，环境已被充分检测以提供完整的可观察性数据，您可以灵活地探索正在发生的事情并快速找出您可能无法预料的问题的根本原因。

要了解分析师的观点，您可以听听 451 Research 的 Nancy Gohring 如何定义可观察性：

为什么可观察性很重要？

在企业环境中，可观察性有助于跨职能团队理解和回答有关高度分布式系统中正在发生的事情的具体问题。可观察性使您能够了解什么是缓慢或损坏的，以及需要做什么来提高性能。有了可观察性解决方案，团队可以收到有关问题的警报，并在问题影响用户之前主动解决这些问题。

由于现代云环境是动态的，并且在规模和复杂性方面不断变化，因此大多数问题既不为人知，也不被监控。可观察性解决了“未知未知数”这一常见问题，使您能够在新类型问题出现时持续自动地理解它们。

可观察性也是用于 IT 运营 (AIOps) 的人工智能的一项关键能力。随着越来越多的组织采用云原生架构，他们也在寻找实施 AIOps 的方法，利用 AI 作为在整个 DevSecOps 生命周期中自动化更多流程的一种方式。通过将 AI 应用于一切——从收集遥测数据到分析整个技术堆栈中发生的事情——您的组织可以获得对自动化应用程序监控、测试、持续交付、应用程序安全和事件响应至关重要的可靠答案。

可观察性的价值并不仅限于 IT 用例。一旦您开始收集和分析可观察性数据，您就有了一个了解数字服务对业务影响的宝贵窗口。这种可见性使您能够优化转换、验证软件版本是否满足业务目标、衡量您的用户体验 SLO 的结果，并根据最重要的事项确定业务决策的优先级。

当可观察性解决方案还使用综合和真实用户监控分析用户体验数据时，您可以在用户发现问题之前发现问题，并根据真实、即时的反馈设计更好的用户体验。

可观察性的好处

可观察性为 IT 团队、组织和最终用户等提供了强大的优势。以下是可观察性促进的一些用例：

• 应用程序性能监控：完整的端到端可观察性使组织能够更快地查明应用程序性能问题的根源，包括云原生和微服务环境引起的问题。高级可观察性解决方案还可用于自动化更多流程，提高 Ops 和 Apps 团队的效率和创新。
• DevSecOps 和 SRE：可观察性不仅是实施高级工具的结果，而且是应用程序及其支持基础设施的基本属性。创建软件的架构师和开发人员必须将其设计为可观察的。然后，DevSecOps 和 SRE 团队可以在软件交付生命周期中利用和解释可观察的数据，以构建更好、更安全、更有弹性的应用程序。
• 基础设施、云和 Kubernetes 监控：基础设施和运营 (I&O) 团队可以利用可观察性解决方案提供的增强环境来提高应用程序的正常运行时间和性能，减少查明和解决问题所需的时间，检测云延迟问题并优化云资源利用率，并改善对其 Kubernetes 环境和现代云架构的管理。
• 最终用户体验：良好的用户体验可以提升公司的声誉并增加收入，在竞争中提供令人羡慕的优势。通过在最终用户注意到之前发现并解决问题并在甚至提出要求之前进行改进，组织可以提高客户满意度和保留率。还可以通过实时回放来优化用户体验，获得与最终用户完全一样的体验的窗口，这样每个人都可以很快就改进的地方达成一致。
• 业务分析：组织可以将业务上下文与全栈应用程序分析和性能相结合，以了解实时业务影响、改进转换优化、确保软件版本满足预期的业务目标，并确认组织遵守内部和外部 SLA。
• DevSecOps 团队可以利用可观察性来更深入地了解他们开发的应用程序，并自动化测试和 CI/CD 流程，以便他们可以更快地发布质量更好的代码。这意味着组织在作战室和相互指责上浪费的时间更少。从生产力的角度来看，这不仅有好处，而且还能加强对有效协作至关重要的积极工作关系。

这些组织改进为进一步创新和数字化转型打开了大门。而且，更重要的是，最终用户最终会以高质量用户体验的形式受益。

如何使系统可观察？

如果你读过可观察性，你可能知道收集日志、指标和分布式跟踪的测量是取得成功的三个关键支柱。但是，仅从后端应用程序观察原始遥测数据并不能提供系统行为的全貌。

忽视前端视角可能会歪曲甚至歪曲您的应用程序和基础架构在现实世界中为真实用户执行的全貌。扩展三支柱方法，IT 团队必须使用用户体验数据来增加遥测收集，以消除盲点：

• 日志：这些是在特定时间发生的离散事件的结构化或非结构化文本记录。
• 指标：这些值表示为计数或度量，通常在一段时间内计算或汇总。指标可以来自多种来源，包括基础设施、主机、服务、云平台和外部来源。
• 分布式跟踪：这会显示事务或请求在流经应用程序时的活动，并显示服务如何连接，包括代码级详细信息。
• 用户体验：这扩展了传统的可观察性遥测，通过在应用程序上添加特定数字体验的由外而内的用户视角，即使在预生产环境中也是如此。

为什么可观察性的三大支柱还不够

显然，数据收集仅仅是开始。仅仅访问正确的日志、指标和跟踪并不足以获得对环境的真正可观察性。一旦你能够使用遥测数据来实现改善最终用户体验和业务成果的最终目标，你才能真正说你已经实现了可观察性的目的。

组织可以使用其他可观察性功能来观察其环境。 OpenTelemetry 等开源解决方案为在云环境中收集遥测数据提供了事实上的标准。这些开源解决方案增强了云原生应用程序的可观察性，并使开发人员和运营团队更容易在多个环境中实现对应用程序健康状况的一致理解。

组织还可以使用真实用户监控来实时了解用户体验，跟踪单个请求的路径，并深入了解它在此过程中与每项服务的每次交互。这种体验可以通过综合监控甚至实际会话的记录来观察。这些功能通过从用户角度添加 API、第三方服务、浏览器中发生的错误、用户人口统计和应用程序性能的数据来扩展遥测。这使 IT、DevSecOps 和 SRE 团队不仅能够查看请求的完整端到端旅程，还能够实时了解系统运行状况。从那里，他们可以在影响应用程序性能之前主动排除运行状况恶化的区域。他们还可以更轻松地从故障中恢复，并更深入地了解用户体验。

尽管 IT 组织拥有最好的意图和策略，但他们经常高估已经负担过重的团队不断观察、理解和处理海量数据和洞察力的能力。尽管存在与可观察性相关的许多复杂挑战，但克服这些挑战的组织会发现值得一试。

可观察性的挑战是什么？

可观察性一直是一个挑战，但云计算的复杂性和快速的变化使其成为组织需要解决的紧迫问题。云环境会生成大量遥测数据，尤其是在涉及微服务和容器化应用程序时。他们还创建了比团队过去必须解释的更多种类的遥测数据。最后，所有这些数据到达的速度使得跟上信息流变得更加困难，更不用说及时准确地解释它以解决性能问题了。

组织还经常遇到以下可观察性挑战：

• 数据孤岛：多个代理、不同的数据源和孤立的监控工具使得很难理解应用程序、多个云和数字渠道（如 Web、移动和物联网）之间的相互依赖关系。
• 数量、速度、多样性和复杂性：几乎不可能从不断变化的现代云环境（例如 AWS、Azure 和 Google 云平台 (GCP)）中每个组件收集的大量原始数据中获得答案。对于 Kubernetes 和可以在几秒钟内启动和关闭的容器也是如此。
• 手动检测和配置：当 IT 资源被迫为每种新类型的组件或代理手动检测和更改代码时，他们大部分时间都在尝试设置可观察性，而不是根据可观察性数据的见解进行创新。
• 缺乏预生产：即使在预生产中进行负载测试，开发人员仍然无法观察或了解真实用户在将代码投入生产之前将如何影响应用程序和基础设施。
• 浪费时间进行故障排除：应用程序、运营、基础设施、开发和数字体验团队参与故障排除并尝试找出问题的根本原因，浪费宝贵的时间猜测并尝试理解遥测并提出答案。
• 然后，存在多个工具和供应商的问题。虽然单个工具可以让组织对其应用程序架构的一个特定区域具有可观察性，但该工具可能无法提供对可能影响应用程序性能的所有应用程序和系统的完全可观察性。

此外，并非所有类型的遥测数据对于确定问题的根本原因或了解其对用户体验的影响都同样有用。因此，团队仍然需要在多个解决方案中挖掘答案并煞费苦心地解释遥测数据的耗时任务，而此时他们可以应用他们的专业知识来立即解决问题。但是，通过单一的事实来源，团队可以更快地获得答案并解决问题。

单一事实来源的重要性

组织需要单一的事实来源才能在其应用程序基础架构中获得完整的可观察性，并准确查明性能问题的根本原因。当组织拥有可以控制云复杂性、捕获所有相关数据并使用 AI 进行分析的单一平台时，团队可以立即确定任何问题的根本原因，无论是应用程序本身还是支持架构。

单一的事实来源使团队能够：

• 将 TB 的遥测数据转化为真正的答案，而不是要求 IT 团队使用来自不同来源的数据片段拼凑对发生的事情的理解
• 获得对他们可能无法看到的基础设施领域的关键上下文洞察。
• 协同工作并进一步加快故障排除过程，使组织能够比使用传统监控工具更快地采取行动，这要归功于增强的可见性。

使 IT 团队的可观察性具有可操作性和可扩展性

可观察性必须以允许资源受限的团队对实时收集的大量遥测数据采取行动的方式实现，以防止影响业务的问题进一步传播甚至首先发生。这里有一些方法可以使可观察性具有可操作性和可扩展性。

• 了解上下文和拓扑：这涉及以一种方式进行检测，以了解高度动态、多云环境中可能存在数十亿个互连组件的每个相互依赖关系之间的关系。丰富的上下文元数据支持实时拓扑图，提供对整个堆栈垂直和服务、进程和主机之间的因果依赖关系的理解。
• 实施持续自动化：持续自动发现、检测和基线化每个系统组件，将 IT 工作从手动配置工作转移到增值创新项目，这些项目可以优先考虑对重要事物的理解。可观察性变得“永远在线”和可扩展，因此受限团队可以事半功倍。
• 建立真正的 AIOps：详尽的 AI 驱动的故障树分析与代码级可见性相结合，解锁了自动查明异常根本原因的能力，而无需依赖耗时的人工试错、猜测或关联。此外，基于因果关系的人工智能可以自动检测任何不寻常的变化点，以发现未被理解或监控的“未知未知数”。这些可操作的洞察力推动了 DevOps 和 SRE 团队所需的更快、更准确的响应。
• 培育一个开放的生态系统：这将可观察性扩展到包括外部数据源，例如 OpenTelemetry，这是一个由 Dynatrace、Google 和 Microsoft 等供应商领导的开源项目。 OpenTelemetry 为提供拓扑映射、自动发现和检测以及大规模可观察性所需的可操作答案的平台扩展了遥测收集和摄取。

人工智能驱动的基于解决方案的方法通过解决与云复杂性相关的挑战，使可观察性真正可行。可观测性解决方案可以更轻松地解释以越来越快的速度从多个来源产生的大量遥测数据。借助单一事实来源，团队可以在问题导致应用程序性能下降之前快速准确地查明问题的根本原因，或者在已经发生故障的情况下加快恢复时间。

高级可观察性还通过跨无服务器平台、Kubernetes 环境、微服务和开源解决方案的端到端分布式跟踪来提高应用程序的可用性。通过了解请求从开始到结束的整个过程，团队可以主动识别应用程序性能问题并获得对最终用户体验的重要洞察。这样，即使组织扩展其应用程序基础架构以支持未来的增长，IT 团队也可以迅速对关注的问题采取行动。

为一切带来可观察性

您不能浪费数月或数年时间尝试构建自己的工具或测试多个供应商，这些供应商只能让您解决可观察性难题的一部分。相反，您需要一个解决方案来帮助您的所有系统和应用程序可观察，为您提供可操作的答案，并尽快提供技术和业务价值。

Dynatrace 的高级可观察性在单个平台中提供所有这些功能，使您的组织能够驾驭现代云复杂性并更快地进行转型。

原文：https://www.dynatrace.com/news/blog/what-is-observability-2/

本文：https://jiagoushi.pro/node/1928

NGINX最近委托约1825名NGINX用户进行的一项调查显示，约68%的受访者组织正在使用或调查微服务，66%的受访者组织正在使用或调查容器。当您谈论一个样本池的“三分之二”时，您正在处理一个相当大的区块。

不管怎样，你要问其他的NX用户在做什么。

正如本出版物的读者所知，采用这些技术是有代价的。DevOps团队通常会比以前有更多的活动部件需要监控。更重要的是，他们正在监控更多短暂的组件，这可能会促使他们使用几种不同的监控解决方案。

InfluxData的InfluxDB和Grafana这两个流行的开源项目的合作可以帮助他们监视和控制云基础设施、应用程序和数据库实例以及容器，从而为DevOps提供一个统一的视图或单一的窗口。

InfluxData提供了一个时间序列数据平台，用于收集和存储用于监控的度量和事件。它包括一个流引擎和100多个收集器代理，用于从多个源收集度量并将其存储在时间序列数据库中。该数据库针对高写负载和大数据集存储进行了优化。它通过下采样、自动过期和删除不需要的数据来节省空间。它还带有一个优雅的UI，支持警报阈值，可以触发流行的工具，如HipChat、OpsGenie、Alerta、Sensu、PagerDuty和Slack。

Grafana是一个供应商中立、开源的时间序列分析平台，拥有超过100000个活动安装。DevOps团队求助于Grafana实验室，帮助他们将不同的数据源整合在一起。它与扩展数据的无缝集成使其成为可视化收集的度量的理想工具。

如何设置Grafana和XDB

您可以从这里下载XDB和相关工具，也可以从这里下载Grafana。

对于扩展数据，您需要一个代理来收集和存储度量。我们推荐我们自己的Telegraf，它有100多个插件，尽管您可以使用传统的收集代理，如StatsD。

XDB和Grafana进程可能共享同一服务器或同一实例。但是，如果您希望安装大量XDB、拥有大量Grafana用户，或者如果您的组织具有特别严格的安全态势或部署配置文件，那么单独的服务器也是完全可以接受的。XDB的API通常默认为端口8086，Grafana的默认为端口3000。Grafana将查询XDB API，以便为仪表板收集数据。

在这两个应用程序中，InfluxDB将是内存和CPU密集度更高的应用程序，因为Grafana的许多工作都发生在一个非常轻量级的基于浏览器的应用程序中。

InfluxDB和 Grafana安装配置

在一起设置InfluxDB和Grafana的默认配置时，可以启用查询日志，该日志将记录执行或发送到InfluxDB API时的所有查询。这样的日志对于调试Grafana问题可能很有用。使用配置的coordinator部分设置最大并发查询数。这可能有助于改善多个Grafana用户同时通过查询访问XDB的问题。您还可以设置查询超时，并记录查询运行缓慢时的时间。

“最大选择点”、“最大选择系列”和“最大选择存储桶”设置限制可以返回的结果数。这可以帮助阻止一个特别扩展的查询减慢或关闭XDB服务器。

Grafana的配置文件包括一些有用的设置，如http端口和路由器日志记录，加快了浏览器的加载时间。

Grafana的安全设置

每个Grafana实例都有一个默认的管理员用户和密码，您需要对其进行更改。默认情况下，Grafana的注册过程允许非管理员用户创建组织。因此，我们建议将“启用匿名访问”选项设置为“false”

如果您打算调试Grafana，那么您肯定会提高日志级别进行调试。Grafana将公布有关自身的指标。Telegraf有一个内置的普罗米修斯输入，所以你可以把它指向Grafana。这样，您可以收集内部指标，将它们放入XDB，然后在Grafana中绘制它们的图形。

如果您正在使用InfluxCloud，并且需要配置对Grafana上不同组和用户的访问权限，请查看以下简短的网络研讨会：“InfluxCloud与多租户Grafana”同样，要使用Grafana UI设置图形并利用InfluxDB查询生成器，请参阅“如何将Grafana与InfluxDB一起使用”

构建仪表板并设置图表

Grafana的仪表盘与上面的仪表盘一样，是一组行和面板，一旦选择XDB作为其数据源，就可以编辑这些行和面板。可以轻松更改图形显示为直线、条形或点的方式。在这些图中，您可以使用任何喜欢的聚合器，选择多个字段，或者使用移动平均等转换。

每个Grafana图实际上都是对InfluxDB的查询。如果您有一个包含30个图形的仪表板，那么您将向InfluxDB发送30个查询，以及需要由InfluxDB整理结果，然后通过Grafana发送回的30个查询。考虑过多的图表是否对你有用。

尽管Grafana对一个图表上显示的指标数量没有限制，但您仍希望跟踪对您监控性能、提取见解或启用预测最有用的指标。

这两个开源项目应该非常适合您的DevOps监控项目，并且不需要花时间进行设置和定制。

原文：https://thenewstack.io/visualize-time-series-data-open-source-grafana-i…

本文：https://jiagoushi.pro/node/1788