This is a self contained class that can be run from the Intersystems Task Scheduler which records peak usage details for databases and licenses built up throughout the day and retaining 30 days history.
To schedule the task to run every hour:
You can also specify your own start time, stop time, and run interval:
d ##class(Metrics.Task).Schedule(startTime, stopTime, intervalMins)
Metrics are stored in ^Metrics in the namespace that the class resides in/is run from.
In this InterSystems IRIS 2020.1 Tech Talk, we focus on DevOps. We'll talk about InterSystems System Alerting and Monitoring, which offers unified cluster monitoring in a single pane for all your InterSystems IRIS instances. It is built on Prometheus and Grafana, two of the most respected open source offerings available.
Next, we'll dive into the InterSystems Kubernetes Operator, a special controller for Kubernetes that streamlines InterSystems IRIS deployments and management. It's the easiest way to deploy an InterSystems IRIS cluster on-prem or in the Cloud, and we'll show how you can configure mirroring, ECP, sharding and compute nodes, and automate it all.
Finally, we'll discuss how to speed test InterSystems IRIS using the open source Ingestion Speed Test. This tool is available on InterSystems Open Exchange for your own testing and benchmarking.
Currently we are using an older Healthshare instance but I am not opposed to using IRIS as we will upgrade eventually.
Currently for monitoring productions we have a Montior screen. We have both the Queues page and a Deepsee dashboard which has current status of our services. The issue with the Deepsee method we currently have with traffic lights is 1) the page is a bit slow to load the metrics 2) any new services from the team a new widget needs created and although this is easy enough to do it just is time consuming.
The current version of SAM creates Prometheus metric endpoints which appear to be handled correctly by the current prometheus scraper, however the metrics do not confirm to the current prometheus standard. The standard states:
The MONITOR process (also called the Caché Monitor) scans the messages in your cconsole.log file and sends you emails based on the severity of those messages. The MONITOR is configured using the ^MONMGR utility in terminal.
The MONITOR should not be confused with the similarly named System Monitor, which checks a variety of system health and performance metrics and can log messages regarding them to the cconsole.log, where they can then be scanned by the MONITOR.
Im trying configure the Caché Monitor Manager (^MONMGR) utility for send alert e-mails. Following the steps I have doubs to configure the options in "Set Server" to send e-mails for hotmail or outlook (smtp-mail.outlook.com). I dont know how can I configure Mail server SSLConfiguration for hotmail or outlook. Could you give me help? Thank you!
I installed a community version of Intersystems IRIS in a Large AWS EC2 instance to do some testing. I installed SAM and when I try to "Add a new cluster" I receive the following: "ERROR #5005: Cannot open file '/config/prometheus/isc_tmp_yml_file.yml'"
Released with no formal announcement in IRIS preview release 2019.4 is the /api/monitor service exposing IRIS metrics in Prometheus format. Big news for anyone wanting to use IRIS metrics as part of their monitoring and alerting solution. The API is a component of the new IRIS System Alerting and Monitoring (SAM) solution that will be released in an upcoming version of IRIS.
InterSystems Global Summit (or Virtual Summit this year) is traditionally a time of big announcements, and I'm sure our friends from InterSystems have quite a lot of new and exciting things to share with us this year. Here at Banksia Global, we have a big announcement for you as well. Please meet our new website built to make IRIS-based software distribution a breeze: ZpmHub.com!
UPDATE: It turns out it was just me being a dummy, and the snmpd was correctly telling me there is no value associated with that exact key. I should have used snmpwalk instead of snmpget to display the whole tree.
Original Post follows:
Hello! I'm trying to set up SNMP monitoring on Caché, using documentation and this article
I believe most of you have encounted this problem: a healthconnect/ensemble user get a slow response and ask measurement on how long it takes ensmeble to process this request, the ensemble 'activity data' gives no clue of the delay.
The reason is HealthConnect message measurement was based on ensemble message, which can’t give a correct answer on when ensmeble recevie the request and what time it send back response. when there is delay on inbound/outbound adpter, or csp gateway, there is no way to find out the delay from "activity data" .
When you have been using cubes for business intelligence in a namespace for some time, you may find that there are many cubes in the namespace, only some of which are actively being used. However, it can be difficult to tell which cubes users are or are not querying, and maintaining unused cubes can be costly both in terms of storage and of computation to keep them up to date. This article provides some suggestions and examples for monitoring which cubes are in active use, and for removing cubes that you determine are no longer necessary.