Uptime 7.7 docs

docs/uptime-guide/security.asciidoc

@@ -2,18 +2,20 @@
 == Elasticsearch Security
 
 If you use Elasticsearch security, you'll need to enable certain privileges for users
-that would like to access the Uptime app. For example, create user and support roles to implement the privileges:
+that would like to access the Uptime app and for Heartbeat as well. See the [Heartbeat Docs](https://www.elastic.co/guide/en/beats/heartbeat/current/feature-roles.html) for information on configuring Heartbeat roles. 
+For example, create user and support roles for both Heartbeat and Uptime users to implement the privileges:
 
 [float]
-=== Create a role
+=== Create a role for privileged Uptime users
 
-You'll need a role that lets you access the Heartbeat indices, which by default are `heartbeat-*`.
+You'll need a role that lets you access the Heartbeat indices and adjust Uptime settings. Heartbeat indices match the pattern `heartbeat-*` by default.
 You can create this with the following request:
 
 ["source","sh",subs="attributes,callouts"]
 ---------------------------------------------------------------
-PUT /_security/role/uptime
-{ "indices" : [
+PUT /_security/role/uptime_all
+{ 
+  "indices" : [
     {
       "names" : [
         "heartbeat-*"
@@ -30,6 +32,13 @@ PUT /_security/role/uptime
       "allow_restricted_indices" : false
     }
   ],
+  "applications": [
+    {
+      "application": "uptime",
+      "privileges": [ "all" ],
+      "resources": [ "*" ]
+    }
+  ],
   "transient_metadata" : {
     "enabled" : true
   }
@@ -38,7 +47,7 @@ PUT /_security/role/uptime
 // CONSOLE
 
 [float]
-=== Assign the role to a user
+=== Assign the role to a privileged user
 
 Next, you'll need to create a user with both the `uptime` role, and another role with sufficient {kibana-ref}/kibana-privileges.html[Kibana privileges],
 such as the `kibana_admin` role.
@@ -49,7 +58,7 @@ You can do this with the following request:
 PUT /_security/user/jacknich
 {
   "password" : "j@rV1s",
-  "roles" : [ "uptime", "kibana_admin" ],
+  "roles" : [ "uptime_all", "kibana_admin" ],
   "full_name" : "Jack Nicholson",
   "email" : "[email protected]",
   "metadata" : {
@@ -58,3 +67,71 @@ PUT /_security/user/jacknich
 }
 ---------------------------------------------------------------
 // CONSOLE
+
+[float]
+=== Create a role for read-only Uptime users
+
+You'll need a role that lets users who are allowed to access the Heartbeat indices, but are not allowed to adjust Uptime settings. These users must have
+their `application` privileges set to `read`, instead of `all`, as in the
+example below.
+
+You can create this with the following request:
+
+
+["source","sh",subs="attributes,callouts"]
+---------------------------------------------------------------
+PUT /_security/role/uptime_read
+{ 
+  "indices" : [
+    {
+      "names" : [
+        "heartbeat-*"
+      ],
+      "privileges" : [
+        "read",
+        "view_index_metadata"
+      ],
+      "field_security" : {
+        "grant" : [
+          "*"
+        ]
+      },
+      "allow_restricted_indices" : false
+    }
+  ],
+  "applications": [
+    {
+      "application": "uptime",
+      "privileges": [ "read" ],
+      "resources": [ "*" ]
+    }
+  ],
+  "transient_metadata" : {
+    "enabled" : true
+  }
+}
+---------------------------------------------------------------
+// CONSOLE
+
+[float]
+=== Assign the role to a privileged user
+
+Next, you'll need to create a user with both the `uptime` role, and another role with sufficient {kibana-ref}/kibana-privileges.html[Kibana privileges],
+such as the `kibana_admin` role.
+You can do this with the following request:
+
+["source","sh",subs="attributes,callouts"]
+---------------------------------------------------------------
+PUT /_security/user/uptime_reader
+{
+  "password" : "j@rV1s",
+  "roles" : [ "uptime_read" ],
+  "full_name" : "Jack Nicholson",
+  "email" : "[email protected]",
+  "metadata" : {
+    "intelligence" : 7
+  }
+}
+---------------------------------------------------------------
+// CONSOLE
+

docs/uptime/index.asciidoc

@@ -12,8 +12,10 @@ To get started with Elastic Uptime, refer to {uptime-guide}/install-uptime.html[
 
 * <<uptime-overview>>
 * <<uptime-monitor>>
+* <<uptime-settings>>
 
 --
 
 include::overview.asciidoc[]
 include::monitor.asciidoc[]
+include::settings.asciidoc[]

docs/uptime/monitor.asciidoc

@@ -5,21 +5,24 @@
 The Monitor page will help you get further insight into the performance
 of a specific network endpoint. You'll see a detailed visualization of
 the monitor's request duration over time, as well as the `up`/`down`
-status over time.
+status over time. You can also also detect anomalies in response time data
+by configuring Machine Learning jobs on this page.
 
 [float]
-=== Status bar
+=== Status panel
 
 [role="screenshot"]
 image::uptime/images/status-bar.png[Status bar]
 
-The Status bar displays a quick summary of the latest information
+The Status panel displays a quick summary of the latest information
 regarding your monitor. You can view its latest status, click a link to
 visit the targeted URL, see its most recent request duration, and determine the
 amount of time that has elapsed since the last check.
 
-You can use the Status bar to get a quick summary of current performance,
-beyond simply knowing if the monitor is `up` or `down`.
+When two Heartbeat instances are configured in different geographic locations
+the map will show each location as a pinpoint on the map, along with the
+amount of time elapsed since data was last received from that location.
+
 
 [float]
 === Monitor charts
@@ -32,12 +35,14 @@ date range. These charts can help you gain insight into how quickly requests are
 by the targeted endpoint, and give you a sense of how frequently a host or endpoint
 was down in your selected timespan.
 
-The first chart displays request duration information for your monitor.
+The Monitor duration chart displays request duration information for your monitor.
 The area surrounding the line is the range of request time for the corresponding
-bucket. The line is the average time.
+bucket. The line is the average time. Anomaly detection using Machine Learning
+can be configured in the upper right hand of this panel. When response times change
+in an unexpected way the time range in which they occurred will be given filled with a color.
 
-Next, is a graphical representation of the check statuses over time. Hover over
-the charts to display crosshairs with more specific numeric data.
+The pings over time chart is a graphical representation of the check statuses over time. 
+Hover over the charts to display crosshairs with more specific numeric data.
 
 [role="screenshot"]
 image::uptime/images/crosshair-example.png[Chart crosshair]
@@ -49,6 +54,6 @@ image::uptime/images/crosshair-example.png[Chart crosshair]
 image::uptime/images/check-history.png[Check history view]
 
 The Check history displays the total count of this monitor's checks for the selected
-date range. You can additionally filter the checks by `status` to help find recent problems
+date range. You can additionally filter the checks by status and location to help find recent problems
 on a per-check basis. This table can help you gain some insight into more granular details
 about recent individual data points Heartbeat is logging about your host or endpoint.

docs/uptime/overview.asciidoc

@@ -21,12 +21,12 @@ This control allows you to use automated filter options, as well as input custom
 text to select specific monitors by field, URL, ID, and other attributes.
 
 [float]
-=== Snapshot view
+=== Snapshot panel
 
 [role="screenshot"]
 image::uptime/images/snapshot-view.png[Snapshot view]
 
-This view is intended to quickly give you a sense of the overall
+This panel is intended to quickly give you a sense of the overall
 status of the environment you're monitoring, or a subset of those monitors.
 Here, you can see the total number of detected monitors within the selected
 Uptime date range. In addition to the total, the counts for the number of monitors
@@ -49,6 +49,17 @@ way to navigate to a more in-depth visualization for interesting hosts or endpoi
 This table includes information like the most recent status, when the monitor was last checked, its
 ID and URL, its IP address, and a dedicated sparkline showing its check status over time.
 
+[float]
+=== Creating and managing alerts
+
+[role="screenshot"]
+image::uptime/images/alert-flyout.png[Create alert flyout]
+
+To receive alerts when a monitor goes down use the alerting menu at the top of the 
+overview page. Use a query in the alert flyout to determine which monitors to check
+with your alert. If you already have a query in the overvew page search bar it will
+be carried over into this box.
+
 [float]
 === Observability integrations
 
@@ -59,15 +70,4 @@ The Monitor list also contains a menu of possible integrations. If Uptime detect
 Docker related host information, it will provide links to open the Metrics app or Logs app pre-filtered
 for this host. Additionally, this feature supplies links to simply filter the other views on the host's
 IP address, to help you quickly determine if these other solutions contain data relevant to your current
-interest.
-
-[float]
-=== Error list
-
-[role="screenshot"]
-image::uptime/images/error-list.png[Error list]
-
-The Error list displays aggregations of errors that Heartbeat has logged. Errors are
-displayed by Error type, monitor ID, and message. Clicking a monitor's ID will take you
-to the corresponding Monitor view, which can provide you richer information about the individual
-data points that are resulting in the displayed errors.
+interest.

docs/uptime/settings.asciidoc

@@ -0,0 +1,27 @@
+[role="xpack"]
+[[uptime-settings]]
+
+== Settings
+
+[role="screenshot"]
+image::uptime/images/settings.png[Filter bar]
+
+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.
+
+As an example, imagine your organization one team for internal IT services, and another
+for public services. Each team operates independently and is only responsible for their
+own services. In this scenario you might setup 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 that 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!
+
+See the https://www.elastic.co/guide/en/uptime/current/uptime-security.html[Uptime Elasticsearch Security]
+and [Heartbeat security](https://www.elastic.co/guide/en/beats/heartbeat/current/feature-roles.html)
+docs for more information.