监视用于 Redis 的 Azure 缓存
本文介绍:
- 可以为此服务收集的监视数据的类型。
- 如何分析这些数据。
如果具有依赖于 Azure 资源的关键应用程序和业务流程,则需要监视并获取系统的警报。 Azure Monitor 服务会从系统的每个组件收集并聚合指标和日志。 Azure Monitor 提供可用性、性能和复原能力视图,并在出现问题时向你发送通知。 可以使用 Azure 门户、PowerShell、Azure CLI、REST API 或客户端库来设置和查看监视数据。
- 有关 Azure Monitor 的详细信息,请参阅 Azure Monitor 概述。
- 有关监视 Azure 资源的常规方法的详细信息,请参阅使用 Azure Monitor 监视 Azure 资源。
https://docs.azure.cn/azure-monitor/logs/logs-ingestion-api-overview
洞察力
Azure 中的某些服务在 Azure 门户中具有内置的监视仪表板,可以从此入手来监视服务。 这些仪表板称为“见解”,可以在 Azure 门户的 Azure Monitor 的“见解中心”找到它们。
适用于 Azure Cache for Redis 的见解提供以下体验:
- 大规模查看所有订阅中的 Azure Cache for Redis 资源。 可以选择将范围限制为仅要评估的订阅和资源。
- Azure Cache for Redis 资源的向下钻取分析。 若要诊断问题,可以查看对利用率、故障、容量和操作的详细分析,或查看相关信息的详细视图。
- 在 Azure Monitor 工作簿模板基础上自定义。 可以更改显示的指标,并修改或设置与限制一致的阈值。 可以将更改保存在自定义工作簿中,然后将工作簿图表固定到 Azure 仪表板。
适用于 Azure Cache for Redis 的见解无需你启用或配置任何内容。 系统默认收集 Azure Cache for Redis 信息,无需额外付费即可获得见解。
若要了解如何查看、配置和自定义 Azure Cache for Redis,请参阅适用于 Azure Cache for Redis 的 Azure Monitor 见解。
资源类型
Azure 使用资源类型和 ID 的概念来标识订阅中的所有内容。 同样的,Azure Monitor 根据资源类型(也称为“命名空间”)将核心监视数据组织为指标和日志。 不同的指标和日志可用于不同的资源类型。 服务可能与多种资源类型关联。
资源类型也是 Azure 中运行的每个资源的资源 ID 的一部分。 例如,虚拟机的一种资源类型是 Microsoft.Compute/virtualMachines
。 有关服务及其关联资源类型的列表,请参阅资源提供程序。
有关 Azure Cache for Redis 的资源类型的详细信息,请参阅 Azure Cache for Redis 监视数据参考。
数据存储
对于 Azure Monitor:
- 指标数据存储在 Azure Monitor 指标数据库中。
- 日志数据存储在 Azure Monitor 日志存储中。 Log Analytics 是 Azure 门户中可以查询此存储的工具。
- Azure 活动日志是一个单独的存储区,在 Azure 门户中有自己的接口。
- 可选择将指标和活动日志数据路由到 Azure Monitor 日志数据库存储,以便可使用 Log Analytics 查询数据并将其与其他日志数据关联。
有关 Azure Monitor 如何存储数据的详细信息,请参阅 Azure Monitor 数据平台。
Azure Monitor 平台指标
Azure Monitor 为大多数服务提供平台指标。 这些指标是:
- 针对每个命名空间单独定义。
- 存储在 Azure Monitor 时序指标数据库中。
- 是轻型数据,并且能够支持准实时警报。
- 用于跟踪资源随时间推移的性能变化。
集合:Azure Monitor 会自动收集平台指标。 不需要任何配置。
路由:通常还可将平台指标路由到 Azure Monitor 日志/Log Analytics,从而可以使用其他日志数据对其进行查询。 有关详细信息,请参阅指标诊断设置。 有关如何为服务配置诊断设置,请参阅在 Azure Monitor 中创建诊断设置。
有关可以为 Azure Monitor 中所有资源收集的所有指标的列表,请参阅 Azure Monitor 中支持的指标。
有关 Azure Cache for Redis 的可用指标列表,请参阅 Azure Cache for Redis 监视数据参考。
Azure Monitor 资源日志
借助资源日志,可以深入了解 Azure 资源已执行的操作。 日志是自动生成的,但必须将日志路由到 Azure Monitor 日志以保存或查询它们。 日志按类别组织。 给定的命名空间可能具有多个资源日志类别。
收集:在创建诊断设置并将日志路由到一个或多个位置之前,不会收集和存储资源日志。 创建诊断设置时,请指定要收集的日志类别。 可以通过多种方式创建和维护诊断设置,包括 Azure 门户、编程方式以及通过 Azure Policy。
路由:建议的默认设置是将资源日志路由到 Azure Monitor 日志,以便可以使用其他日志数据查询它们。 其他位置(例如 Azure 存储、Azure 事件中心和某些 Azure 监视合作伙伴)也可用。 有关详细信息,请参阅 Azure 资源日志和资源日志目标。
有关收集、存储和路由资源日志的详细信息,请参阅 Azure Monitor 中的诊断设置。
有关 Azure Monitor 中所有可用资源日志类别的列表,请参阅 Azure Monitor 中支持的资源日志。
Azure Monitor 中的所有资源日志都具有相同的标头字段,后跟特定于服务的字段。 Azure Monitor 资源日志架构概述了常见架构。
有关可用的资源日志类别、其关联的 Log Analytics 表和 Azure Cache for Redis 的日志架构,请参阅 Azure Cache for Redis 监视数据参考。
Azure Cache for Redis 资源日志
在 Azure Cache for Redis 中,有两个选项可用于记录:
- 缓存指标(“AllMetrics”)记录 Azure Monitor 中的指标
- 连接日志出于安全和诊断目的记录与高速缓存的连接。
缓存度量值
Azure Cache for Redis 会发出许多指标,例如 Server Load
和 Connections per Second
,这些指标对记录很有用。 选择 AllMetrics 选项可以记录上述及其他缓存指标。 可以配置指标的保留时长。
连接日志
Azure Cache for Redis 使用 Azure 诊断设置来记录有关与缓存建立的客户端连接的信息。 记录并分析此诊断设置可帮助你了解谁正在连接到你的缓存,以及这些连接的时间戳。 日志数据可用于识别安全漏洞的范围以及进行安全审核。
对于不同的 Azure Cache for Redis 层,连接日志的实现、内容和设置过程略有不同。 有关详细信息,请参阅 Azure Monitor 诊断设置。
Azure 活动日志
活动日志包含订阅级事件,这些事件跟踪从资源外部看到的每个 Azure 资源的操作;例如,创建新资源或启动虚拟机。
收集:活动日志事件会自动生成并收集在单独的存储中,以便在 Azure 门户中查看。
路由:可将活动日志数据发送到 Azure Monitor 日志,以便可以将它们与其他日志数据一起进行分析。 其他位置(例如 Azure 存储、Azure 事件中心和某些 Azure 监视合作伙伴)也可用。 有关如何路由活动日志的详细信息,请参阅 Azure 活动日志概述。
分析监视数据
有许多工具可用于分析监视数据。
Azure Monitor 工具
Azure Monitor 支持以下基本工具:
指标资源管理器,它是 Azure 门户中的工具,可用于查看和分析 Azure 资源的指标。 有关详细信息,请参阅使用 Azure Monitor 指标资源管理器分析指标。
Log Analytics,它是 Azure 门户中的一种工具,支持使用 Kusto 查询语言 (KQL) 来查询和分析日志数据。 有关详细信息,请参阅 Azure Monitor 日志查询入门。
活动日志,它在 Azure 门户中具有用于执行查看和基本搜索的用户界面。 要进行更深入的分析,必须将数据路由到 Azure Monitor 日志,并在 Log Analytics 中运行更复杂的查询。
支持更复杂可视化效果的工具包括:
- 仪表板,它支持将不同类型的数据合并到 Azure 门户的单个窗格中。
- 工作簿,它们是可在 Azure 门户中创建的可自定义报表。 工作簿可以包括文本、指标和日志查询。
- Power BI,它是一项业务分析服务,可提供跨各种数据源的交互式可视化效果。 可将 Power BI 配置为自动从 Azure Monitor 导入日志数据,以利用这些可视化效果。
Azure Monitor 导出工具
可以使用以下方法将数据从 Azure Monitor 中提取到其他工具中:
指标:使用适用于指标的 REST API 从 Azure Monitor 指标数据库提取指标数据。 API 支持使用筛选表达式优化检索到的数据。 有关详细信息,请参阅 Azure Monitor REST API 参考。
日志:使用 REST API 或关联的客户端库。
要开始使用适用于 Azure Monitor 的 REST API,请参阅 Azure 监视 REST API 演练。
Azure Cache for Redis 指标
Azure Cache for Redis 实例的指标是使用 Redis INFO
命令收集的。 指标每分钟大约收集两次,因此,它们可以显示在指标图表中,并根据警报规则进行评估。 若要了解数据的保留时间以及如何配置其他保留策略,请参阅 Azure Monitor 日志中的数据保留和存档。
将使用多个报告间隔报告指标,其中包括“前一小时”、“今天”、“前一周”和“自定义”。 每个指标图表会在图表中显示每个指标的平均值、最小值和最大值,并且一些指标会显示总报告间隔。
每个指标包括两种版本:一个指标衡量整个缓存的性能,以及使用群集的缓存群集。 该指标的第二种版本(名称中包含 (Shard 0-9)
)衡量缓存中单个分片的性能。 例如,如果缓存有四个分片,Cache Hits
就是整个缓存的命中总数,而 Cache Hits (Shard 3)
只衡量该缓存分片的命中数。
查看缓存指标
可以直接从Azure 门的 Azure Cache for Redis 资源中查看 Azure Cache for Redis 的 Azure Monitor 指标。
在门户中选择 Azure Cache for Redis 实例。 概述页显示了预定义的内存使用情况和Redis 服务器负载监视图表。 这些图表是有用的摘要,可支持快速查看缓存的状态。
有关更深入的信息,可以从资源菜单的监视 部分监视以下有用的 Azure Cache for Redis 指标。
Azure Redis 缓存指标 | 详细信息 |
---|---|
网络带宽使用率 | 缓存性能 - 可用带宽 |
连接的客户端数 | 默认 Redis 服务器配置 - 最大客户端数 |
服务器负载 | Redis 服务器负载 |
内存使用率 | 缓存性能 - 大小 |
创建自己的指标
可以创建自己的自定义图表来跟踪要查看的指标。 将使用多个报告间隔报告缓存指标,其中包括“前一小时” 、“今天” 、“前一周” 和“自定义” 。 在左侧,在“监视”部分中选择“指标”。 每个指标图表会在图表中显示每个指标的平均值、最小值和最大值,并且一些指标会显示总报告间隔。
每个指标包括两种版本:一个指标衡量整个缓存的性能,以及使用群集的缓存群集。 该指标的第二种版本(名称中包含 (Shard 0-9)
)衡量缓存中单个分片的性能。 例如,如果缓存有四个分片,Cache Hits
就是整个缓存的命中总数,而 Cache Hits (Shard 3)
只衡量该缓存分片的命中数。
在左侧的“资源”菜单中,选择“监视”下的“指标”。 在这里,你会为缓存设计自己的图表,并定义指标类型和聚合类型。
聚合类型
有关聚合类型的常规信息,请参阅配置聚合。
在正常缓存情况下,“平均值”和“最大值”相似,因为只有主节点发出这些指标。 如果连接的客户端数快速变化,“最大值”、“平均值”和“最小值”将显示不同的值,这也是预期的行为。
“计数”和“总和”类型对于某些指标(包括连接的客户端数)而言可能有误导性。 最好改为查看“平均值”指标,而不是“总和”指标。
注意
即使在缓存处于空闲状态,且没有连接的活动客户端应用程序时,也可能会看到一些缓存活动,例如连接的客户端、内存使用率以及正在执行的操作。 在缓存的操作中,活动是正常的。
对于非聚集缓存,最好使用不带后缀 Instance Based
的指标。 例如,要检查缓存实例的服务器负载,请使用指标服务器负载。
相比之下,对于群集缓存,请使用带有后缀 Instance Based
的指标。 然后,在 ShardId
上添加拆分或筛选器。 例如,要检查分片 1 的服务器负载,请使用指标服务器负载(基于实例),然后应用筛选器 ShardId = 1。
Kusto 查询
可使用 Kusto 查询语言 (KQL) 来分析 Azure Monitor 日志/Log Analytics 存储中的监视数据。
重要
在门户的服务菜单中选择“日志”时,会打开 Log Analytics,并且其查询范围设置为当前服务。 此范围意味着日志查询将仅包含来自该资源类型的数据。 如果希望运行的查询包含来自其他 Azure 服务的数据,请从“Azure Monitor”菜单中选择“日志”。 有关详细信息,请参阅 Azure Monitor Log Analytics 中的日志查询范围和时间范围。
有关任何服务的常见查询的列表,请参阅 Log Analytics 查询界面。
Log Analytics 查询
注意
有关如何使用 Azure Log Analytics 的教程,请参阅 Azure Monitor 中的 Log Analytics 概述。 请记住,日志最多可能需要 90 分钟才能显示在 Log Analtyics 中。
下面是一些用作模型的基本查询。