How to set TZ Offset value in the program configuration

[abudavis]

We are using the latest mq-metrics-sample (v5.6.0) that is compiled to extract metrics from an MQ QMGR on v9.3 running on a RHEL v8 VM. We send the prometheus metrics to Grafana SaaS Cloud instance from metrics pod setup on Openshift.

On Grafana, we have a dashboard with a panel configured with query: last_over_time(ibmmq_queue_time_since_get[$__range])

The issue is that the metrics pod on Openshift is naturally on UTC, whereas the MQ server is on CEST timezone. I tried to set the metrics pod to an environment variable 'TZ' to 'CET-1CEST,M3.5.0/2,M10.5.0/3', but this only changed the date (command) inside the metrics pod but it kept giving this error, how can we fix this? How do we set the TZ Offset value in the program configuration?

IBM MQ metrics exporter for Prometheus monitoring
Build : 20220412-112013
Commit Level : d84f842
Build Platform: Linux/x86_64
time="2024-07-01T08:26:47Z" level=error msg="Status reports appear to be from the future. Difference is approximately 7199 seconds. Check the TZ Offset value in the program configuration
--
time="2024-07-01T08:25:51Z" level=info msg="Connected to queue manager QMGR15"
time="2024-07-01T08:25:53Z" level=info msg="IBMMQ Describe started"
time="2024-07-01T08:25:53Z" level=info msg="Platform is UNIX"
time="2024-07-01T08:25:53Z" level=info msg="Listening on http address :9157"

[ibmmqmet]

Look at the global.tzOffset config parameter

[abudavis]

Look at the global.tzOffset config parameter

I got it to work with this: `oc create configmap metrics-configuration --from-literal=IBMMQ_GLOBAL_TZOFFSET='2h'

Our QMGR is on Europe/Frankfurt TZ while Openshift metric pod is on UTC. Most importantly, how do we also ensure this is automatically adjusted in DST cutovers?

[abudavis]

@ibmmqmet Would it work if I add the docker instruction [ENV TZ='Europe/Oslo'] or [ENV TZ='CET-1CEST,M3.5.0/2,M10.5.0/3'] to here? https://github.com/ibm-messaging/mq-metric-samples/blob/master/Dockerfile.run

[ibmmqmet]

Certainly setting TZ modifies the reported time for a container - at least the output from the date command.

docker run -it img bash
$ date
Mon Sep 23 10:32:15 UTC 2024

and

docker run -e TZ="Europe/Oslo" img bash
$ date
Mon Sep 23 12:32:56 CEST 2024

Rather than modifying the Dockerfile, I might set TZ externally. `docker run -e TZ="Europe/Oslo ..." might be simpler. But it'd be worth trying it, as timezones and offsets get reported in different ways by different APIs.

[abudavis]

@ibmmqmet I am running the collector/metrics as a pod and the OS seems to be the one shown below, setting the TZ as an environment on the Openshift deployment (similar to your docker command I guess) did change the time on the pod terminal but the metrics pod still reported the time difference, so this clearly does not work. Any other suggestions? We want something that will continue to work with DST cutovers so that we dont have to manually change the IBMMQ_GLOBAL_TZOFFSET/global.tzOffset twice a year.

$ uname -a
Linux mq-metric-qmgr1-578cdc95d8-wjjwg 5.14.0-284.82.1.el9_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug 22 12:25:01 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux

[alexisph]

What worked for me on OpenShift was setting the TZ envvar and in addition mounting the correct timezone data file over /etc/localtime

Ref: https://access.redhat.com/solutions/2567961

[abudavis]

@alexisph What is the base docker image you used to deploy the MQ client + metric sample? Coz the one I am using does not have a zone file, the /etc/localtime must point to one.

[alexisph]

UBI minimal, as defined in https://github.com/ibm-messaging/mq-metric-samples/blob/master/scripts/buildBuildah.sh

/etc/localtime does not have to point to anything. It can be a "fat" timezone file, mounted from a configmap, which is what i am doing. See also the redhat article i linked above for more info.

[abudavis]

@alexisph I did read the redhat page, it says the tzdata isn't installed on the UBI 8 minimal image, did you do that? I have an /etc/localtime for CEST timezone on my RHEL VM, could you I use that for the ConfigMap on Openshift?

[alexisph]

No, i did not install anything. The commands in "Workaround 3" are all you need to set this up by hand. The timezone files are usually in /usr/share/zoneinfo and you can pull them from an Openshift node or any Linux VM. /etc/localtime is just a link to a file in that directory. Do not use /etc/localtime to create your configmap. use the full file in /usr/share/zoneinfo

[abudavis]

Thanks, I only had to apply "Workaround 3" and that solved the problem, thank you!

@ibmmqmet You might want to mention this permanent fix (that supports DST changes) somewhere for those customers with MQ servers on non-UTC timezone.