2024 年 12 月 4 日，系统警报和监视 (SAM) 已从 InterSystems 下载网站、容器注册表和文档网站移除。

InterSystems 去年宣布停止进一步开发 SAM，并同时将其标记为已弃用。InterSystems 将继续按照与超出最低支持版本窗口的产品版本相同的方式为使用此技术的现有客户提供支持。

Intersystems 发现，大多数对 SAM 提供的可观察性类型感兴趣的客户已选择将 InterSystems IRIS 指标 API 和结构化日志记录连接到其组织现有的可观察性平台，以便更全面地了解其运行平台。

如果您对 SAM 当前的使用方式或今后的使用计划有任何疑问，请联系您的客户团队或 dbpprodmgrs@intersystems.com。

Cache锁的异常直接影响数据库进程运行，堆积的锁如果处理不及时会造成Cache性能异常，导致数据库访问受限或严重卡顿。本文主要以实例分析介绍Cache中常见锁的作用及其对应的处理方式，包括：系统锁、数据锁、Session锁、仪器锁、程序文件锁。其中数据锁异常需要及时处理。

查询Cache锁有两种方式：

1>可在System Management Protal的[Home]>[Locks]中查看；

2>可在terminal端使用Do ^LOCKTAB命令下查看，如下图所示，此方式适用于锁表量达到10000条以上，Protal页面HTTP响应超时无法显示锁表时使用。

一、【系统锁】

此类锁在数据库初次搭建时就存在，例如：

1>^%SYS("CSP","Daemon") ---调度锁

2>^TASKMGR  ---守护进程

3>^DBACK ---数据库备份锁

4>^SYS("Task","TaskD",1058) ---执行系统任务锁

主要作用

cache数据库自身带有系统监控Portal界面，但需要运维人员定期主动查看才能获取监控信息。当系统故障发生时，容易出现由于没有及时获取故障信息而不能及时处理，从而导致造成的影响扩大。本文研究通过解析cache数据库控制台日志（cconsole.log）进行监控信息获取并主动推送微信或短信实现cache数据库主动实时监控。

cache数据库在运行时会将所有控制台消息包括一般消息、系统错误、某些操作系统错误和网络错误都会发送到控制台日志文件，通过操作员控制台工具从其他系统远程启动的作业的成功或失败等信息也会写入控制台日志，因此通过对控制台日志的解析即可获取所需要监控信息。具体步骤方法如下：

解析控制台日志

控制台日志默认存储在install-dir\mgr路径下。

根据cache版本不同，使用的读取方法也不同。对于cache2016版本以上，系统提供了EnsLib.SQL.Snapshot类，可以直接获取日志的行和列信息，非常方便。对于cache2010及以下版本则无此方法，需要使用%File文件读取方法。

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 实例详细页面

IRIS 2019.4 预览版中发布了/api/monitor服务，以Prometheus格式展示IRIS指标，但没有正式公布。对于任何想要使用IRIS指标作为其监控和警报解决方案的一部分的人来说，这是一个大新闻。该API是新的IRIS 系统警报和监控（SAM）解决方案的一个组成部分，将在IRIS的一个即将到来的版本中发布。

然而，你不必等待SAM开始规划和试用这个API来监控你的IRIS实例。在未来的文章中，我将深入挖掘可用的指标和它们的含义，并提供交互式仪表盘的例子。但首先，让我从一些背景和一些问题和答案开始。

IRIS（和Caché）总是在收集关于它自己和它所运行的平台的几十个指标。一直以来都有多种收集这些指标的方法来监控Caché和IRIS。我发现，很少有安装使用IRIS和Caché内置的解决方案。例如，History Monitor仪表盘作为性能和系统使用指标的历史数据库已经存在很长时间了。然而，没有明显的方法来展现这些指标，并实时监测系统。

IRIS平台的解决方案正在从运行在几个企业内部的实例上的单体应用程序，转向分布式解决方案部署在 "任何地方"。对于许多用例，现有的IRIS监控选项并不适合这些新的模式。InterSystems没有使用陈旧的方法，而是寻找当前流行的、经过验证的开源解决方案进行监控和警报。

普罗米修斯？

1 磁盘空间不足的常见情形
1）Journal所在磁盘空间不足。造成这种情况的原因有多种，比如，Mirror中备机未处于宕机状态，因此主机保留了Journal文件。
2）数据库所在磁盘空间不足。比如，集成平台上Ensemble/Health Connect/IRIS for Health的消息从未清除过，导致消息数据库DAT文件不断增大，直至将磁盘空间用尽。

我们可以看到以上两种情形下，Mirror都帮不上忙，也就是说一旦问题出现，主机和备机都没有办法立即承担起业务系统的运行，
第1)种，备机可能在故障出现前就已经宕机很长一段时间而没被发现，备机的数据很可能已经与主机严重不一致。实际上，主机之所以保留了大量的journal文件没有删除，就是为了让备机同步数据时使用。
第2)种，虽然配置了Mirror，但是消息主库正常情况下都是镜像库，在一个健康的Mirror中，备机和主机的镜像库数据保持同步，镜像库大小应当是相同的，假设主备机的硬件配置相同（这也是我们推荐的方式）那么磁盘空间不足在备机上同样存在。

2 应急措施 
切忌手动从文件系统中删除Journal文件！

以上两种情形我们都遇到过客户为了快速地腾出空间、恢复系统，第一时间手动从文件系统中将必要的Journal文件删除掉了，删除了这些Journal文件之后，尽管腾出了空间，但会造成系统无法启动，通常这个时候您会在日志文件中看到如下信息，

为Caché 进行 Prometheus 监控时，配置好应用程序/metrics， Prometheus配置文件配置完成后，抓取不到cache监控数据，提示“server returned HTTP status 404 Not Found”。请问是什么原因？