在之前的帖子中，我展示了如何使用 pButtons 收集历史性能指标。 我首选 pButtons 是因为我知道它随每个数据平台实例（Ensemble、Caché、...）一起安装。 不过，还有其他方法可以实时收集、处理和显示 Caché 性能指标，以进行简单的监视，或进行更重要的并且复杂得多的运营分析和容量计划。 最常见的数据收集方法之一是使用 SNMP（简单网络管理协议）。
SNMP 是 Caché 向各种管理工具提供管理和监控信息的标准方式。 Caché 在线文档包含了 Caché 和 SNMP 之间接口的详细信息。 虽然 SNMP 应该可以直接与 Caché 配合工作，但仍有一些配置技巧和陷阱。 我经历了很多次错误的开始，并且在 InterSystems 其他同事的帮助下，才让 Caché 与操作系统 SNMP 主代理建立对话，所以我写了这篇帖子，希望您可以避免同样的痛苦。
嗨，开发者们！
今天我想谈谈一个让我感到困难的话题。我相信你们中的很多人一定已经遇到过这种情况（所谓的“瓶颈”）。由于这是一个广泛的主题，因此本文将仅重点关注识别可能导致缓慢问题的传入 HTTP 请求。我还将向您提供我开发的一个小工具来帮助识别它们。
我们的软件变得越来越复杂，处理来自不同来源的大量请求，无论是前端还是第三方后端应用程序。为了确保最佳性能，必须有一个能够记录一些关键测量的日志系统，例如响应时间、global引用的数量以及每个 HTTP 响应执行的代码行数。作为工作的一部分，我参与了 EMR 软件的开发以及事件分析。由于用户负载主要来自 HTTP 请求（REST API 或 CSP 应用程序），因此在发生普遍缓慢问题时进行此类测量的需求变得显而易见。
本文讨论了在使用或维护InterSystems产品中遇到问题时，试图确定问题时可能用到的思路和工具。
确定问题发生的地点和时间
审查日志中的警告、错误和警报
以下日志可能包含有关该问题的有用信息。可以尝试在以下日志中寻找问题开始前后的警告或报错。
检查实例是否可以访问足够的存储空间
检查CPU活动
cache数据库自身带有系统监控Portal界面，但需要运维人员定期主动查看才能获取监控信息。当系统故障发生时，容易出现由于没有及时获取故障信息而不能及时处理，从而导致造成的影响扩大。本文研究通过解析cache数据库控制台日志（cconsole.log）进行监控信息获取并主动推送微信或短信实现cache数据库主动实时监控。
cache数据库在运行时会将所有控制台消息包括一般消息、系统错误、某些操作系统错误和网络错误都会发送到控制台日志文件，通过操作员控制台工具从其他系统远程启动的作业的成功或失败等信息也会写入控制台日志，因此通过对控制台日志的解析即可获取所需要监控信息。具体步骤方法如下：
控制台日志默认存储在install-dir\mgr路径下。
根据cache版本不同，使用的读取方法也不同。对于cache2016版本以上，系统提供了EnsLib.SQL.Snapshot类，可以直接获取日志的行和列信息，非常方便。对于cache2010及以下版本则无此方法，需要使用%File文件读取方法。
InterSystems Production 监控是管理门户中的一个页面，用于显示当前运行的Production监控信息。我喜欢这个页面的样子，但这并不适合所有人。
2022年5月13日，我在开发者社区上看到这个帖子。
https://community.intersystems.com/post/creating-custom-monitoring-page
我同意马克的观点，Production监控很复杂。我想创建一个更漂亮干净的监控页面。
我开始着手制作一个利用类方法提供Production数据的 CSP（Cache Server Page）页面。
我与马克分享了我的第一次尝试。他根据自己的想法定制了这个页面。我喜欢他对页面的布局，使其在视觉上更有吸引力。我把他的设计整合到我的应用程序Production监控中。
我看到马克对业务服务的显示进行了过滤，只显示需要注意的服务。他在页面的底部添加了服务器的名称和它的镜像状态。
你可以在Open Exchange和当前的竞赛中找到我的Production监控器的应用。
https://openexchange.intersystems.com/package/production-monitor
nterSystems很高兴地宣布发布系统警报和监控（SAM）1.1版。
什么是SAM ?
SAM将IRIS基于标准的监控API和日志监控与熟悉的行业标准工具如Grafana和Prometheus结合起来，为IRIS集群创建一个基本的监控和告警解决方案。
关于SAM的更多信息，请参阅《系统告警和监控指南》。
SAM 1.1有什么新的内容?
你会注意到Grafana仪表盘图形的性能改进，特别是在处理大型数据集时。 如果你从SAM 1.0升级，你要确保你有足够的磁盘空间，因为SAM 1.1增加了额外的数据索引。
有关升级到SAM 1.1的更多信息，请参见发行说明。
SAM 主页
SAM 实例详细页面
1 磁盘空间不足的常见情形
1）Journal所在磁盘空间不足。造成这种情况的原因有多种，比如，Mirror中备机未处于宕机状态，因此主机保留了Journal文件。
2）数据库所在磁盘空间不足。比如，集成平台上Ensemble/Health Connect/IRIS for Health的消息从未清除过，导致消息数据库DAT文件不断增大，直至将磁盘空间用尽。
我们可以看到以上两种情形下，Mirror都帮不上忙，也就是说一旦问题出现，主机和备机都没有办法立即承担起业务系统的运行，
第1)种，备机可能在故障出现前就已经宕机很长一段时间而没被发现，备机的数据很可能已经与主机严重不一致。实际上，主机之所以保留了大量的journal文件没有删除，就是为了让备机同步数据时使用。
第2)种，虽然配置了Mirror，但是消息主库正常情况下都是镜像库，在一个健康的Mirror中，备机和主机的镜像库数据保持同步，镜像库大小应当是相同的，假设主备机的硬件配置相同（这也是我们推荐的方式）那么磁盘空间不足在备机上同样存在。
2 应急措施
切忌手动从文件系统中删除Journal文件！
以上两种情形我们都遇到过客户为了快速地腾出空间、恢复系统，第一时间手动从文件系统中将必要的Journal文件删除掉了，删除了这些Journal文件之后，尽管腾出了空间，但会造成系统无法启动，通常这个时候您会在日志文件中看到如下信息，
以下步骤展示如何显示 /api/monitor 服务提供的指标列表示例。
在上个帖子中，我概述了以 Prometheus 格式显示 IRIS 指标的服务。 该贴介绍了如何在容器中设置和运行 IRIS 预览版 2019.4，然后列出了指标。
本帖假定您已安装 Docker。 如果未安装，现在就为您的平台安装吧 :)
按照预览发行版的下载说明下载预览版许可证密钥和 IRIS Docker 映像。 例如，我选择了 InterSystems IRIS for Health 2019.4。
按照 Docker 容器中的 InterSystems 产品初见中的说明操作。 如果您熟悉容器，请跳转到标题为“下载 InterSystems IRIS Docker 映像”的部分。
以下终端输出说明了我用来加载 docker 映像的过程。 docker load 命令可能需要几分钟的时间才能运行；
注（2019 年 6 月）：许多内容发生了变化，最新的详细信息请参见此处 注（2018 年 9 月）：自本帖首次发布以来，内容已经有了很大改动，我建议使用 Docker 容器版本，以容器形式运行的项目以及详细信息仍然在 GitHub 的同一个地址发布，您可以下载、运行并根据需要进行修改。
与客户合作进行性能评估、容量规划和故障排除时，我经常解包和查看来自 pButtons 的 Caché 和操作系统指标。 我不久前发布了一个帖子，介绍了一个用来解包 pButtons 指标的实用工具（该实用工具使用 unix shell、perl 和 awk 脚本编写），而不是费力地浏览 html 文件，再将需要绘制的部分剪切并粘贴到 excel 中。 虽然这是一个有用的省时工具，但还不够完善... 我还使用脚本自动绘制指标图表，以便快速查看并包含在报告中。 但是，这些绘图脚本不容易维护，并且当需要站点特定的配置（例如 iostat 或 Windows perfmon 的磁盘列表）时会变得特别混乱，所以我从未公开发布过绘图实用工具。 不过我现在可以很高兴地说，已经有了简单得多的解决方案。
在上一篇文章《互操作消息统一管理系列：Message Bank》中，我们了解到在Message Bank中，消息均以半结构化（XML）或非结构化（Stream）的形式保存，因此无法与客户端的结构化消息一样，直接支持基于索引的检索。为此，需要在Message Bank中定义Search Table以支持查询。关于Search Table的定义和作用，请查阅https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=EEDI_search_tables。
大家如果使用过消息查看器，则能够了解IRIS自动持久化消息并提供界面让大家能够根据消息头中（如发生事件、来源、目标等）或消息体中（如患者姓名、诊断名称等消息的具体属性）来查询消息。
而在Message Bank上进行查询时，如果直接使用消息查看器，能够查询的是Message Bank的Production中传输的消息，而若不是在源系统中出现的消息，这一点一定不要混淆。
Message Bank提供了消息仓库查看器供大家查询源系统中的消息
企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：
这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。
客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。
为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。
对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。
对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。
如下所示：
大家好！
我想跟大家分享一个个人项目，该项目始于工作中的一个简单需求：“能否知道我们使用了多少个Caché许可证？”
在阅读社区的其他文章时，我发现了一篇David Loveluck写的非常棒的文章：APM——使用Caché History Monitor。
我根据David的这篇文章，开始使用Caché History Monitor并显示所有这些信息。
在面临“选择哪种很酷的技术”这个问题时，我决定使用简单而强大的CSP，这样我的客户可以认识到Caché不仅仅是MUMPS/终端。
在创建了页面以显示许可、数据库增长和CSP会话的历史记录后，我决定为System Dashboard和进程页面创建一个新设计。
我的Caché实例运行得良好。
但是，如果使用IRIS呢？
我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。
IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。
IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。
在最近的项目里，多方同时连接同一个数据库并执行增删改查等各项数据操作。研发人员不时发现一些数据在不合规的情况下被新增甚至删除。因此，在实际工作中会有监控数据操作以便识别和处理异常操作的需求。本文将以监控和识别删除操作为例，介绍如何通过IRIS的审计功能实现对数据操作的监控和查询。
在应用审计功能之前，必须注意的是：
自 Caché 2017 以后，SQL 引擎包含了一些新的统计信息。 这些统计信息记录了执行查询的次数以及运行查询所花费的时间。
对于想要对包含许多 SQL 语句的应用程序的性能进行监控和尝试优化的人来说，这是一座宝库，但访问数据并不像一些人希望的那么容易。
本文和相关的示例代码说明了如何使用这些信息，以及如何例行提取每日统计信息的摘要，并保存应用程序的 SQL 性能的历史记录。
每次执行 SQL 语句时，都记录花费的时间。 这是非常轻量的操作，无法关闭。 为了最大程度地降低开销，统计信息保留在内存中并定期写入磁盘。 数据包括一天中执行查询的次数以及所花费的平均时间和总时间。
数据不会立即写入磁盘，并且在写入之后，统计信息将由“更新 SQL 查询统计信息”任务更新，该任务通常计划为每小时运行一次。 该任务可以手动触发，但是如果你希望在测试查询时实时查看统计信息，则整个过程需要一点耐心。
警告：在 InterSystems IRIS 2019 及更早版本中，不会针对已使用 %Studio.Project:Deploy 机制部署的类或例程中的嵌入式 SQL 收集这些统计信息。 示例代码不会有任何中断，但这可能会使你产生误导（我被误导过），让你以为一切正常，因为没有查询显示为高开销。
现在，InterSystems 系统警报和监视（简称 InterSystems SAM）第 1 版 (v1.0) 发布了预览版本。
InterSystems SAM v1.0 为基于 InterSystems IRIS 的产品提供现代化的监视解决方案。 其可对集群进行高级别查看，并且能够以单节点方式可视化深入探视指标，同时提供警报通知。 该第 1 个版本提供对一百多个 InterSystems IRIS 内核指标的可视化，并且用户可以根据自己的喜好扩展默认提供的 Grafana 模板。
V1.0 旨在成为简单直观的基准。 请进行尝试并向我们发送反馈，帮助我们使其变得更棒！
从版本 2019.4 开始，SAM 可以显示来自基于 InterSystems 的实例中的信息
SAM 仅以容器格式提供。 您将需要 SAM 管理器容器，以及一小组额外的开源_组件_（Prometheus 和 Grafana），它们由组合文件自动添加。
可从以下位置获取 SAM 组件和 SAM 管理器社区版
如果您正在旅行，或偏爱通过语音收听有关什么是 SAM 方面的提问与回答，我们为您准备了以下播客：
<iframe class="castos-iframe-player" frameborder="0" height="160" scrolling="no" src="https://5e18edf067eb59-03854285.castos.com/player/198587" width="100%"></iframe>
在本文中，我们将讨论孤立消息。
每个消息正文都与一个保存元数据的消息标头相关联。 标头保存源配置名称、目标配置名称、创建时间、处理时间、关联的消息正文引用、会话信息、消息正文类名、消息状态等信息。 当有消息正文记录没有相应的标头记录时，这些消息正文称为孤立消息正文。 我们将讨论可能导致孤立消息正文产生的原因。
在清除任务设置中，BodiesToo 设置用于指定是否将消息正文与消息标头一起清除。 如果关闭此设置，清除任务将只删除消息标头，而保留消息正文。 这些消息正文将成为孤立记录，因为所引用的标头已被删除。 如果清除消息标头但保留消息正文，则管理门户将无法清除孤立消息正文。 在这种情况下，必须以编程方式清除消息正文。
请参阅有关清除任务的文档
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EGMG_purge#EGMG_purge_basic
当 Ensemble 清除某条消息正文时，不一定删除该消息正文的对象值属性。 具体来说，只有当其他对象是序列对象或子对象（由关系定义）时，才会删除这些对象。 对于其他对象，必须通过在消息正文类中定义删除触发器或实现 %OnDelete() 方法来适当地处理删除。
OnDelete 实现的示例代码
各位开发者们大家好！
此前，我向各位介绍了一个非常好用的运行分析监控面板，它能使消息处理过程中的关键指标可视化，例如入站/出站消息的数量和平均处理时间等。
现在，我想用一项许多人已熟悉的工作流程，来展示一个增强型日志监视器——将警告信息作为Production中的消息来处理。我们可以通过创建路由规则来实现对告警消息的过滤和路由，并运用预先构建的组件（例如电子邮件适配器等）来发送粒度级别的通知。
如你所知，监视和管理警告信息是确保任何应用程序平稳运行的关键。对诸如HealthShare和IRIS医疗版这样支撑医疗系统运转的一级应用程序和集成引擎来说对告警信息的处理更显得尤为重要。
让我们先来梳理一下InterSystems产品中已经附带的警告信息监视和管理工具: