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

Added local_time metric with time_zone label to OS collector #67

Merged
merged 1 commit into from
Apr 3, 2017

Conversation

atezs82
Copy link

@atezs82 atezs82 commented Mar 31, 2017

Added a new metric called wmi_os_local_time to the exporter, with which OS time on Windows can be also scraped from Prometheus (and, for instance alerts can be generated when it does not match the time of the server). The metric also contains a label called time_zone in which the time zone on Windows is stored (and can be compared accordingly with any value in Prometheus).

collector/os.go Outdated
ch <- prometheus.MustNewConstMetric(
c.LocalDateTime,
prometheus.GaugeValue,
float64(time.Unix()),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you clarify, is this local time or is it unix time? If local time, what does that mean?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is Unix time (as described in https://golang.org/pkg/time/#Time.Unix).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Local time implies that timezones are involved, which is not the case for unixtime. This should be just called "time".

The timezone should go on a separate 1-valued metric.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, see the latest updated code below. Can you do a review for that as well?

collector/os.go Outdated
nil,
),
TimeZone: prometheus.NewDesc(
prometheus.BuildFQName(Namespace, subsystem, "time_zone"),
Copy link

@brian-brazil brian-brazil Mar 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'd spell it as timezone

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with brian

@brian-brazil
Copy link

This seems fine from a metrics standpoint, but I'll leave on of the WMI people to review and merge.

Copy link
Collaborator

@martinlindhe martinlindhe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just minor nitpick about the naming,
please use "timezone" rather than "time_zone".
Apart from this, it looks great!

collector/os.go Outdated
@@ -26,6 +27,8 @@ type OSCollector struct {
PagingLimitBytes *prometheus.Desc
VirtualMemoryBytes *prometheus.Desc
VisibleMemoryBytes *prometheus.Desc
Time *prometheus.Desc
TimeZone *prometheus.Desc
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Timezone

collector/os.go Outdated
nil,
),
TimeZone: prometheus.NewDesc(
prometheus.BuildFQName(Namespace, subsystem, "time_zone"),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with brian

collector/os.go Outdated
TimeZone: prometheus.NewDesc(
prometheus.BuildFQName(Namespace, subsystem, "time_zone"),
"OperatingSystem.LocalDateTime",
[]string{"time_zone"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

timezone

@carlpett
Copy link
Collaborator

carlpett commented Apr 1, 2017

Implementation-wise, this looks fine to me. Thanks @atezs82!
One point of discussion would be if it could possibly be better to use the UTC offset in minutes rather than the name of the timezone? Seems less likely to cause localization issues and similar.

@brian-brazil
Copy link

UTC offset in minutes

Seconds is the convention in Prometheus.

Seems less likely to cause localization issues and similar.

There are multiple timezones that can result in the same offsets at various times of the year. For example, I'm in UTC for half the year. The full timezone name is what you need.

@carlpett
Copy link
Collaborator

carlpett commented Apr 1, 2017

UTC offset in minutes

Seconds is the convention in Prometheus.

Right, sloppy phrasing on my part. What I meant was that what WMI exposes is the offset in minutes. It should be exposed as seconds, as you say.

Seems less likely to cause localization issues and similar.

There are multiple timezones that can result in the same offsets at various times of the year. For example, I'm in UTC for half the year. The full timezone name is what you need.

After re-reading the code and trying a few zone/dst changes locally, I can agree to this. I had two concerns, which both seem to have been wrong:

  • I initially misread as the timezone name being read from WMI. Windows localizes the timezone name, so that seemed like it would be likely to create issues for deployments in multiple languages. Go's time.zone() does the reasonable thing, of course.
  • In the same vein of experience with poor implementations of time zones, I wasn't sure that DST changes would result in different zones. Again, Go seems to do the right thing.

So, in short, I'm fine with this.

"time" for the Unix time
"timezone" for the name of the timezone
@atezs82
Copy link
Author

atezs82 commented Apr 3, 2017

Thanks for all the comments! I did my best to incorporate them.
Also squashed the commit not to mess up the repository.
Let me know if anything else is required!

@martinlindhe martinlindhe merged commit b6d5367 into prometheus-community:master Apr 3, 2017
@martinlindhe
Copy link
Collaborator

@atezs82 Thank you very much for this contribution!

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

Successfully merging this pull request may close these issues.

5 participants