63eabdbc19
* Move Uptime content from Kibana doc * Fix doc build * Committing deleted image files * Updates following review * Change attribute name * Update Uptime doc link in UI * Update doc url * Doc url update * Update alert images and further edits Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
52 lines
2.6 KiB
Plaintext
52 lines
2.6 KiB
Plaintext
[role="xpack"]
|
|
[[uptime-settings]]
|
|
|
|
=== Settings
|
|
|
|
The Uptime settings page lets you change which Heartbeat indices are displayed
|
|
by the uptime app. Users must have the 'all' permission to modify items on this page.
|
|
Uptime settings apply to the current space only. Use different settings in different
|
|
spaces to segment different uptime use cases and domains.
|
|
|
|
==== Indices
|
|
|
|
Imagine your organization has one team for internal IT services, and another
|
|
for public services. Each team operates independently and is only responsible for its
|
|
own services. In this scenario, you might set up separate Heartbeat instances for each team,
|
|
writing out to index patterns named `it-heartbeat-\*`, and `external-heartbeat-\*`. You would
|
|
create separate roles and users for each in Elasticsearch, each with access to their own spaces,
|
|
named `it` and `external` respectively. Within each space you would navigate to the settings page
|
|
and set the correct index pattern to match only the indices that space is allowed to access.
|
|
|
|
Note: The pattern set here only restricts what the Uptime app shows. Users may still be able
|
|
to manually query Elasticsearch for data outside this pattern.
|
|
|
|
[role="screenshot"]
|
|
image::images/indices.png[Heartbeat indices]
|
|
|
|
See the {kibana-ref}/uptime-security.html[Uptime security] and {heartbeat-ref}/securing-heartbeat.html[Heartbeat security]
|
|
docs for more information.
|
|
|
|
==== Certificate thresholds
|
|
|
|
You can modify settings in this section to control how Uptime will visualize your TLS values in
|
|
the <<uptime-certificates, Certificates page>>. These settings also determine which certificates will be
|
|
selected by any TLS alert you define.
|
|
|
|
There are two fields, `age` and `expiration`. Use the `age` threshold to specify when Uptime should warn
|
|
you about certificates that have been valid for too long. Use the `expiration` threshold to specify when Uptime should warn you
|
|
about certificates that have approaching expiration dates.
|
|
|
|
For example, a common security requirement is to make sure that none of your organization's TLS certificates have been
|
|
valid for longer than one year. Modifying the `Age limit` field's value to 365 days will help you keep track of which
|
|
certificates you may want to refresh.
|
|
|
|
Likewise, to see which of your TLS certificates are close to expiring ahead of time, specify
|
|
an `Expiration threshold` on this page. When the count of a certificate's remaining valid days falls
|
|
below this threshold, Uptime will consider it in a warning state. When you define a TLS alert, you receive a
|
|
notification from Uptime about the certificate.
|
|
|
|
[role="screenshot"]
|
|
image::images/cert-exp.png[Certification expiration thresholds]
|
|
|