Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to set TZ Offset value in the program configuration #314

Closed
abudavis opened this issue Jul 1, 2024 · 11 comments
Closed

How to set TZ Offset value in the program configuration #314

abudavis opened this issue Jul 1, 2024 · 11 comments

Comments

@abudavis
Copy link

abudavis commented Jul 1, 2024

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
Copy link
Collaborator

ibmmqmet commented Jul 1, 2024

Look at the global.tzOffset config parameter

@abudavis
Copy link
Author

abudavis commented Jul 1, 2024

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
Copy link
Author

@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
Copy link
Collaborator

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
Copy link
Author

@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
Copy link

alexisph commented Sep 23, 2024

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
Copy link
Author

@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
Copy link

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
Copy link
Author

@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
Copy link

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
Copy link
Author

abudavis commented Sep 24, 2024

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.

@abudavis abudavis closed this as completed Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants