influxdb and grafana timezone mismatch - time

I'm trying to use curl to write datapoints into to influxdb and then display with grafana.
The following successfully writes to influxdb, but the time is in UTC
# curl -i -XPOST "http://localhost:8086/write?db=db_fio" --data-binary "test result=22"
HTTP/1.1 204 No Content
Request-Id: a333902d-7c69-11e5-802d-000000000000
X-Influxdb-Version: 0.9.4.1
Date: Tue, 27 Oct 2015 05:14:45 GMT
# date
Mon Oct 26 22:17:40 PDT 2015
When I try to display the datapoints in grafana I can not as they are in the future for my timezone (PDT), even thought both services are running on the same server.
What am I doing wrong? How do I get grafana and influxdb to be on the same time?

You can set UTC timezone per dashboard.
http://play.grafana.org/dashboard/db/new-features-in-v20?editview=settings

InfluxDB only supports UTC. There is no way to write or query points in any other timezone. The feature request for timezone support describes some of the challenges that make this a difficult feature to implement.
I am not familiar enough with Grafana to know if it can do timezone translation on the results from InfluxDB.

Related

How to receive Event Key value from Bitbucket to Jenkins Multibranch Pipeline using Bitbucket Server Integration plugin

I installed the plugin Bitbucket Server Integration in jenkins & able to receive webhook to trigger build jobs with this setup.
From the logs also I can see different event key is received.
Processed 4 branches (query complete)
[Mon Jan 16 13:23:53 IST 2023] com.atlassian.bitbucket.jenkins.internal.trigger.BitbucketWebhookConsumer$BitbucketSCMHeadPullRequestEvent UPDATED event from code-repository with timestamp Mon Jan 16 13:23:52 IST 2023 processed in 0.55 sec
[Mon Jan 16 16:23:04 IST 2023] Received com.atlassian.bitbucket.jenkins.internal.trigger.BitbucketWebhookConsumer$BitbucketSCMHeadEvent UPDATED event from code-repository with timestamp Mon Jan 16 16:23:04 IST 2023
git rev-parse --resolve-git-dir /var/lib/jenkins/caches/git-deb6ea23f7071e9d585c1b40bdf92144/.git
Now I want to perform different actions based on the received eventKey. Like doing extra validation if received event is for a Pull Request.
I understand we can read the JSON payload for the webhook trigger (from ${JENKINS_URL}/bitbucket-server-webhook/trigger). There is also a way to read it from Request Header: X-Event-Key.
Bitbucket Webhook request
But I cannot find a way to read/print it in Jenkins console.
Can anyone help with it please?

Can the istio log output time zone be modified?

[2020-11-27T03:53:09.046Z] "HEAD /productpage HTTP/1.1" 200 - "-" 0 0 27 27 "10.244.11.0" "curl/7.47.0" "ef48c206-422a-9d0d-ac56-9be531b190f7" "10.22.24.5:31695" "10.244.6.18:9080" outbound|9080||productpage.istio-web.svc.cluster.local 10.244.6.251:41376 10.244.6.251:8080 10.244.11.0:54697 - -
How to change istio log time zone to 'Asia/Shanghai'?
This topic has already been discussed on envoy github as istio uses envoy access log.
As far as I know currently it's not possible. There are github issues I mentioned above about that which says that it's designed in UTC by default.
Access log's timestamps are still in UTC regardless a containter's timezone
How to change the log time zone of each component of Istio to CST format
It's not even possible to persuade the image to use your timezone as envoy will use the UTC anyway.

Cadence cron schedule according to timezone

What is the timezone used by cadence by default?
How can we change cron expression according to timezone? eg if a user enters a cron schedule from a different timezone than the cadence's server timezone let say the user enters 1 pm every day in GMT + 5 then it should run at 9 am in the server( assuming cadence's server timezone is GMT only ).
I am using golang cadence client to write the workflows.
Any help is appreciated.
You'll have to rewrite the cron expression yourself before passing it to Cadence. Consider using an existing library like cron-utils for this.

How do I update Elasticsearch timezone data?

In Brazil we are having a huge problem related with daylight saving time, because the start date was delayed by the President.
Apparently, my cluster thinks that we are in -0200 at America/Sao_Paulo, but actually we are in -0300 yet.
How can I update timezone data? The linux server timezone data is correct.
The Brazil change you mentioned was recorded in version 2018a of the time zone data. You likely have an older version installed.
This isn't related to elasticsearch. You simply need to make sure the time zone data on your operating system is up to date. This is in the tzdata package for most Linux distributions.

ElasticSearch 5.1.1 + Grafana 4.1.0 Time seems offset by UTC difference

I'm running Grafana 4.1.0_beta1 and Elasticsearch 5.1.1.
All my servers are setup for Mountain Time, I seem to be running into an issue where Grafana attempts to "account" for UTC, and offsets search parameters by 7 hours.
As an example;
date result from server; Wed Jan 4 20:10:54 MST 2017
But when I try to add and test a data source in Grafana, I get this error:
{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"metricbeat-2017.01.05","index_uuid":"_na_","index":"metricbeat-2017.01.05"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"metricbeat-2017.01.05","index_uuid":"_na_","index":"metricbeat-2017.01.05"}
While metricbeat-2017.01.05 does not exist, metricbeat-2017.01.04 does as it should.
When on a dashboard, I don't see any data, until I set the time, to anything over 7h prior.
I didn't see anything regarding timezone in the elasticsearch, or grafana config files.
Am I missing something?
Classic case of over analyzing.
It looked like everything was correct because it was, except for my client timezone.
Correct Timezone on local client
Ensure time is updated correctly
Restart web browser
You should be able to time shift the data back into range by 7h by going into added panel widget -> Time range -> Add time shift.
--If nothing else works that is.

Resources