I recently got an answer from the WRC confirming that In the YYYY.R docker image is always the latest release of the given version.
So we only have to lookup which is the latest release of a version to know which exact version to expect when pulling an image.

Already some time since the last post...
I appreciate the way of dealing with the tags although I'm used to the way this is done i.E. in docker hub where every provided image is listed with its actual build-number so you can see, which image exactly is "latest" or which version is delivered when you only ask for a mayor-release-tag.

If there is a bug in a certain minor-version I cannot see easily if there is a never minor version provided with a docker image. Therefore I have to search through the release notes to see if / when an image of the new version is released or I have to pull the last image of the mayor-version (some GB!) and inspect it.
Perhaps this scenario seems a little "constructed"? We just had to deal with it .

In short: With only mayor-version-tags we have to rely in Intersystems that

1. there is always the latest release of an application provided as docker image as well and

2. that there are no new bugs in a newer version (because we can't stick to a certain build).

For production environments with high availability I recommend to use a private registry for Iris etc. and tag the images so we can determine when to upgrade.

How do other deal with this (or am I just paranoid?)

Hello,

I had the same question not knowing how to install the plugin to my grafana instance. I figured out from the docker-compose.yml that Dmitry just mounts the whole repository to a subdirectory of the grafana plugins-directory ( /var/lib/grafana/plugins/grafana-intersystems-datasource ) so I copied the whole repo to my grafana instance and could use the plugin (although I have some more issues which I didn't try to resolve yet).
If you are familiar with prometheus you can gather metrics from the metrics api like the (deprecated) SAM " System Altert and Monitoring" does. A look at the SAM-Repo could help to configure Prometheus and Grafana correctly. 

Regards, Thomas

Hi @Krista Koljonen , I followed the recommendations in this post: https://community.intersystems.com/post/how-write-event-log-text-file
, so SELECT * FROM Ens_Util.Log; will return the content of the eventlog . You just have to remeber the last id to be able to extract only the rows you haven't already got earlier.

Since it's only SAM which will be deprecated but the tools which actually "do the work" will still exist and the metrics api as well, we will use the SAM-stack without SAM, just Prometheus and Grafana which can be complemented by grafana-loki for log-aggregation.
This tool stack is very versatile and you can create beautyful dashboards for different purposes.
The only downside I see compared to SAM is, you have to configure some tools by configuration file.

Hi, I'm working on this as well but as for now I'm not sure if I'm going the best way: Trying to extract event-logs via SQL on a regular base and feed them to grafana. There I would be able to configure alerts. 
Feeding log to grafana works pretty well with promtail and loki from grafana.
Does anyone have a better solution especially to get the eventlogs out of iris?

Btw: since SAM is deprecated I just use grafana and prometheus without SAM. The monitoring api will still exist.

Okay, I've been waiting for this. SAM has shown us what is already possible related to monitoring IRIS and the extension with custom metrics is great but it indeed did not integrate very well in existing monitoring solutions. 
I would like to see a growing community around enhancing IRIS-monitoring. I'm especially interested in getting all the different logs from IRIS into Grafana.
Maybe the Grafana-Intersystems-Plugin by Dmitri Maslennikow or an Intersystems-Plugin for Loki might do the trick? Has somebody already achieved this?

Not sure if I understand where you are stuck. Looks like you are trying to proxy the PWS instead of avoiding it.
What the webgateway does and what intersystems recommends is using the webgateway which does not connect to the PWS on IRIS but to the superserver-port (default: port 1972).
The general configuration of the connection between Webgateway and IRIS is done via web-based management-interface of the webgateway. The articles Luis Angel is referring to include the configuration of which sorts or requests are linked to the Webgateway and forwarded to Iris (via superserver-port).
Hope this will help....
 

Is there a good documentation for setup IIS with Web-Gateway and Kerberos? 
I want to achieve SSO for Caché. Integrated authentication works for IIS, Kerberos works between Web-Gateway and SuperServer but when opening the management portal in Edge I always get the Caché logon-screen which I thought should not be shown if SSO worked.
I think this is an issue with the IIS configuration but spent hours to find out...