Add telemetry for Jenkins uptime

[daniel-beck]

@dwnusbaum and I noticed unexpected distribution of correlators (see JEP-214) in the submissions to our telemetry trials (my #8440 and #7470 and and Devin's #7342).

While most correlation IDs are submitted multiple times, up to once per day, there are outliers:

• A significant number of correlation IDs are only seen once, indicating very short-lived instances. JFR disables usage stats submission, so that's not it.
• A few correlation IDs are seen more than once per day during the collection period, sometimes many times per day. Our best guess so far is cloned Jenkins home directories, but some might also be frequently restarting instances.

In both cases (mostly the second though), collecting Jenkins uptime should be able to help understand what's going on.

This does not use jenkins.model.Uptime as data source, as that's not stable given system time changes (I filed JENKINS-72157).

Testing done

def tel = ExtensionList.lookupSingleton(jenkins.telemetry.impl.Uptime)
def json = tel.createContent()
println ((json.get('now') - json.get('start')) / 1000 / 1000 / 1000)

Changed system time by 5 minutes, re-ran this, no significant jump.

Also locally changed the start date to Oct 10 and manually triggered submission (ExtensionList.lookupSingleton(jenkins.telemetry.Telemetry.TelemetryReporter.class).run()), then checked it in Uplink.

Proposed changelog entries

• Add telemetry for Jenkins uptime.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. The Jira issue, if it exists, is well-described.
2. The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[daniel-beck]

Slightly different wording than in the screenshot.

[dwnusbaum]

Why collect both endpoints instead of just the difference? I guess this makes it easier to tell when a single correlator is somehow being used by multiple instances because of overlapping but non-equal endpoints. Are there any other reasons?

[daniel-beck]

I guess this makes it easier to tell when a single correlator is somehow being used by multiple instances because of overlapping but non-equal endpoints.

That's the idea. Multiple submissions will have the same start time if and only if Jenkins wasn't restarted in between.

[NotMyFault]

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[MarkEWaite]

@daniel-beck this seems to me like it might be a good candidate for backporting to the 2.426.1 LTS. Should it be an LTS candidate for 2.426.1 or would you prefer to wait for a later LTS release?

[daniel-beck]

@MarkEWaite Thanks for the reminder! I filed JENKINS-72248. I'm happy to wait if it's already late for 2.426.1.