diff --git a/docs/en/observability/images/icons/apmTrace.svg b/docs/en/observability/images/icons/apmTrace.svg new file mode 100644 index 0000000000..800b8e51a4 --- /dev/null +++ b/docs/en/observability/images/icons/apmTrace.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/arrowLeft.svg b/docs/en/observability/images/icons/arrowLeft.svg new file mode 100644 index 0000000000..d5956d01bb --- /dev/null +++ b/docs/en/observability/images/icons/arrowLeft.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/arrowRight.svg b/docs/en/observability/images/icons/arrowRight.svg new file mode 100644 index 0000000000..b2d76bddc2 --- /dev/null +++ b/docs/en/observability/images/icons/arrowRight.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/beaker.svg b/docs/en/observability/images/icons/beaker.svg new file mode 100644 index 0000000000..05eb97809c --- /dev/null +++ b/docs/en/observability/images/icons/beaker.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/calendar.svg b/docs/en/observability/images/icons/calendar.svg new file mode 100644 index 0000000000..ed311de10c --- /dev/null +++ b/docs/en/observability/images/icons/calendar.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/inspect.svg b/docs/en/observability/images/icons/inspect.svg new file mode 100644 index 0000000000..43374b4aa4 --- /dev/null +++ b/docs/en/observability/images/icons/inspect.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/minus.svg b/docs/en/observability/images/icons/minus.svg new file mode 100644 index 0000000000..763922a916 --- /dev/null +++ b/docs/en/observability/images/icons/minus.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/pencil.svg b/docs/en/observability/images/icons/pencil.svg new file mode 100644 index 0000000000..cb16b5d2f0 --- /dev/null +++ b/docs/en/observability/images/icons/pencil.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/popout.svg b/docs/en/observability/images/icons/popout.svg new file mode 100644 index 0000000000..875bf6662d --- /dev/null +++ b/docs/en/observability/images/icons/popout.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/sortDown.svg b/docs/en/observability/images/icons/sortDown.svg new file mode 100644 index 0000000000..7efa30e917 --- /dev/null +++ b/docs/en/observability/images/icons/sortDown.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/icons/sortUp.svg b/docs/en/observability/images/icons/sortUp.svg new file mode 100644 index 0000000000..c5d0f004ad --- /dev/null +++ b/docs/en/observability/images/icons/sortUp.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/docs/en/observability/images/private-locations-monitor-locations.png b/docs/en/observability/images/private-locations-monitor-locations.png index 3c9ab2f9b2..fc4dad9414 100644 Binary files a/docs/en/observability/images/private-locations-monitor-locations.png and b/docs/en/observability/images/private-locations-monitor-locations.png differ diff --git a/docs/en/observability/images/synthetics-analyze-individual-monitor-details.png b/docs/en/observability/images/synthetics-analyze-individual-monitor-details.png new file mode 100644 index 0000000000..08349dabf5 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-individual-monitor-details.png differ diff --git a/docs/en/observability/images/synthetics-analyze-individual-monitor-errors.png b/docs/en/observability/images/synthetics-analyze-individual-monitor-errors.png new file mode 100644 index 0000000000..a478f3408b Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-individual-monitor-errors.png differ diff --git a/docs/en/observability/images/synthetics-analyze-individual-monitor-header.png b/docs/en/observability/images/synthetics-analyze-individual-monitor-header.png new file mode 100644 index 0000000000..0e8d3a6d8c Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-individual-monitor-header.png differ diff --git a/docs/en/observability/images/synthetics-analyze-individual-monitor-history.png b/docs/en/observability/images/synthetics-analyze-individual-monitor-history.png new file mode 100644 index 0000000000..bf3d325b3c Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-individual-monitor-history.png differ diff --git a/docs/en/observability/images/synthetics-analyze-journeys-over-time.png b/docs/en/observability/images/synthetics-analyze-journeys-over-time.png new file mode 100644 index 0000000000..b9acdffd23 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-journeys-over-time.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-run-code-executed.png b/docs/en/observability/images/synthetics-analyze-one-run-code-executed.png new file mode 100644 index 0000000000..f65f26934d Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-run-code-executed.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-run-compare-steps.png b/docs/en/observability/images/synthetics-analyze-one-run-compare-steps.png new file mode 100644 index 0000000000..28a663c74b Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-run-compare-steps.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-step-metrics.png b/docs/en/observability/images/synthetics-analyze-one-step-metrics.png new file mode 100644 index 0000000000..d9d0d1bc83 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-step-metrics.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-step-network.png b/docs/en/observability/images/synthetics-analyze-one-step-network.png new file mode 100644 index 0000000000..b448e474b1 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-step-network.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-step-object.png b/docs/en/observability/images/synthetics-analyze-one-step-object.png new file mode 100644 index 0000000000..4846992088 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-step-object.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-step-screenshot.png b/docs/en/observability/images/synthetics-analyze-one-step-screenshot.png new file mode 100644 index 0000000000..97a687d6f7 Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-step-screenshot.png differ diff --git a/docs/en/observability/images/synthetics-analyze-one-step-timing.png b/docs/en/observability/images/synthetics-analyze-one-step-timing.png new file mode 100644 index 0000000000..0bd844384f Binary files /dev/null and b/docs/en/observability/images/synthetics-analyze-one-step-timing.png differ diff --git a/docs/en/observability/images/synthetics-get-started-projects.png b/docs/en/observability/images/synthetics-get-started-projects.png index 1734403bc1..fff6175555 100644 Binary files a/docs/en/observability/images/synthetics-get-started-projects.png and b/docs/en/observability/images/synthetics-get-started-projects.png differ diff --git a/docs/en/observability/images/synthetics-get-started-ui.png b/docs/en/observability/images/synthetics-get-started-ui.png index 4cf395704a..3be1e0278c 100644 Binary files a/docs/en/observability/images/synthetics-get-started-ui.png and b/docs/en/observability/images/synthetics-get-started-ui.png differ diff --git a/docs/en/observability/images/synthetics-monitor-management-api-key.png b/docs/en/observability/images/synthetics-monitor-management-api-key.png index 6b93a47fa9..bdaac7d67c 100644 Binary files a/docs/en/observability/images/synthetics-monitor-management-api-key.png and b/docs/en/observability/images/synthetics-monitor-management-api-key.png differ diff --git a/docs/en/observability/images/synthetics-monitor-page.png b/docs/en/observability/images/synthetics-monitor-page.png new file mode 100644 index 0000000000..e5a79c1d6a Binary files /dev/null and b/docs/en/observability/images/synthetics-monitor-page.png differ diff --git a/docs/en/observability/images/synthetics-settings-alerting.png b/docs/en/observability/images/synthetics-settings-alerting.png new file mode 100644 index 0000000000..ed22aaa52b Binary files /dev/null and b/docs/en/observability/images/synthetics-settings-alerting.png differ diff --git a/docs/en/observability/images/synthetics-settings-api-keys.png b/docs/en/observability/images/synthetics-settings-api-keys.png new file mode 100644 index 0000000000..8b102a7d04 Binary files /dev/null and b/docs/en/observability/images/synthetics-settings-api-keys.png differ diff --git a/docs/en/observability/images/synthetics-settings-data-retention.png b/docs/en/observability/images/synthetics-settings-data-retention.png new file mode 100644 index 0000000000..74ac7d7276 Binary files /dev/null and b/docs/en/observability/images/synthetics-settings-data-retention.png differ diff --git a/docs/en/observability/images/synthetics-settings-global-parameters.png b/docs/en/observability/images/synthetics-settings-global-parameters.png new file mode 100644 index 0000000000..ce0ef86ebf Binary files /dev/null and b/docs/en/observability/images/synthetics-settings-global-parameters.png differ diff --git a/docs/en/observability/images/synthetics-settings-private-locations.png b/docs/en/observability/images/synthetics-settings-private-locations.png new file mode 100644 index 0000000000..17571d3a90 Binary files /dev/null and b/docs/en/observability/images/synthetics-settings-private-locations.png differ diff --git a/docs/en/observability/images/synthetics-ui-inline-script.png b/docs/en/observability/images/synthetics-ui-inline-script.png new file mode 100644 index 0000000000..68b24d3adc Binary files /dev/null and b/docs/en/observability/images/synthetics-ui-inline-script.png differ diff --git a/docs/en/observability/images/uptime-app-inline-script.png b/docs/en/observability/images/uptime-app-inline-script.png deleted file mode 100644 index 3e6ce4ffb1..0000000000 Binary files a/docs/en/observability/images/uptime-app-inline-script.png and /dev/null differ diff --git a/docs/en/observability/images/uptime-set-up-ui.asciidoc.png b/docs/en/observability/images/uptime-set-up-ui.asciidoc.png index 6476e7a7cf..f9a47d9569 100644 Binary files a/docs/en/observability/images/uptime-set-up-ui.asciidoc.png and b/docs/en/observability/images/uptime-set-up-ui.asciidoc.png differ diff --git a/docs/en/observability/index.asciidoc b/docs/en/observability/index.asciidoc index c9706882fd..b5669902dc 100644 --- a/docs/en/observability/index.asciidoc +++ b/docs/en/observability/index.asciidoc @@ -29,6 +29,10 @@ include::{docs-root}/shared/attributes.asciidoc[] :kibana-repo-dir: {kibana-root}/docs :synthetics_version: v1.0.0-beta.40 +:project-monitors: project monitors +:project-monitors-cap: Project monitors +:synthetics-app: Synthetics app +:private-location: Private Location // What is Observability? include::observability-introduction.asciidoc[leveloffset=+1] @@ -100,14 +104,27 @@ include::inspect-metric-anomalies.asciidoc[leveloffset=+2] include::configure-metrics-sources.asciidoc[leveloffset=+2] -// Uptime & Synthetic monitoring -include::monitor-uptime-synthetics.asciidoc[leveloffset=+1] +// Uptime +include::uptime-intro.asciidoc[leveloffset=+1] + +include::uptime-get-started-heartbeat.asciidoc[leveloffset=+2] + +include::uptime-analyze.asciidoc[leveloffset=+2] +include::uptime-view-monitor-status.asciidoc[leveloffset=+3] +include::uptime-analyze-monitors.asciidoc[leveloffset=+3] +include::uptime-inspect-duration-anomalies.asciidoc[leveloffset=+3] + +include::configure-uptime-settings.asciidoc[leveloffset=+2] + +include::troubleshoot-uptime-mapping-issues.asciidoc[leveloffset=+2] + +// Synthetics +include::synthetics-intro.asciidoc[leveloffset=+1] :playwright-url: https://playwright.dev/ :playwright-api-docs: https://playwright.dev/docs/api/class-playwright include::synthetics-get-started.asciidoc[leveloffset=+2] -include::synthetics-get-started-heartbeat.asciidoc[leveloffset=+3] include::synthetics-get-started-project.asciidoc[leveloffset=+3] include::synthetics-get-started-ui.asciidoc[leveloffset=+3] @@ -121,11 +138,7 @@ include::synthetics-lightweight.asciidoc[leveloffset=+2] include::synthetics-manage-monitors.asciidoc[leveloffset=+2] -include::uptime-analyze.asciidoc[leveloffset=+2] -include::view-monitor-status.asciidoc[leveloffset=+3] -include::synthetics-visualize.asciidoc[leveloffset=+3] -include::analyze-monitors.asciidoc[leveloffset=+3] -include::inspect-uptime-duration-anomalies.asciidoc[leveloffset=+3] +include::synthetics-analyze.asciidoc[leveloffset=+2] include::synthetics-private-location.asciidoc[leveloffset=+2] @@ -133,12 +146,10 @@ include::synthetics-command-reference.asciidoc[leveloffset=+2] include::synthetics-configuration.asciidoc[leveloffset=+2] -include::configure-uptime-settings.asciidoc[leveloffset=+2] +include::synthetics-settings.asciidoc[leveloffset=+2] include::synthetics-manage-retention.asciidoc[leveloffset=+2] -include::troubleshoot-uptime-mapping-issues.asciidoc[leveloffset=+2] - include::synthetics-migrate-integration.asciidoc[leveloffset=+2] // User experience diff --git a/docs/en/observability/redirects.asciidoc b/docs/en/observability/redirects.asciidoc index d5f79117e8..50268d1159 100644 --- a/docs/en/observability/redirects.asciidoc +++ b/docs/en/observability/redirects.asciidoc @@ -42,7 +42,12 @@ Refer to <>. [role="exclude" id="uptime-set-up-choose-heartbeat"] === Use lightweight monitors with {heartbeat} -Refer to <>. +Refer to <>. + +[role="exclude" id="synthetics-get-started-heartbeat"] +=== Create monitors with {heartbeat} + +Refer to <>. [role="exclude" id="uptime-set-up-choose-agent"] === Use lightweight monitors with the {uptime-app} @@ -59,4 +64,9 @@ Refer to <>. [[synthetic-monitor-choose-project]] -Refer to <>. \ No newline at end of file +Refer to <>. + +[role="exclude" id="synthetics-visualize"] +=== Visualize journeys + +Refer to <>. diff --git a/docs/en/observability/synthetics-analyze.asciidoc b/docs/en/observability/synthetics-analyze.asciidoc new file mode 100644 index 0000000000..fc3e99cf12 --- /dev/null +++ b/docs/en/observability/synthetics-analyze.asciidoc @@ -0,0 +1,357 @@ +[[synthetics-analyze]] += Analyze data from synthetic monitors + +++++ +Analyze monitor data +++++ + +The {synthetics-app} in {kib} both gives you a high-level overview of your service's +availability and allows you to dig into details to diagnose what caused downtime. + +[discrete] +[[synthetics-analyze-overview]] += Overview + +The Synthetics *Overview* tab provides you with a high-level view of all the services you are monitoring +to help you quickly diagnose outages and other connectivity issues within your network. + +To access this page, go to *{observability}* -> *Synthetics* and make sure you're on the *Overview* tab. + +This overview includes a snapshot of the current status of all monitors, the number of errors that +occurred over the last 6 hours, and the number of alerts over the last 12 hours. +All monitors created using projects or using the {synthetics-app} will be listed below with information +about the location, current status, and duration average. + +[NOTE] +==== +When you use a single monitor configuration to create monitors in multiple locations, each location +is listed as a separate monitor as they run as individual monitors and the status and duration average +can vary by location. +==== + +[role="screenshot"] +image::images/synthetics-monitor-page.png[{synthetics-app} in {kib}] + +To get started with your analysis in the Overview tab, you can search for monitors or +use the filter options including current status (up, down, or disabled), +monitor type (for example, journey or HTTP), location, and more. + +Then click an individual monitor to see some details in a flyout. +From there, you can click *Go to monitor* to go to an individual monitor's page +to see more details (as described below). + +[discrete] +[[synthetics-analyze-individual-monitors]] += All monitor types + +When you go to an individual monitor's page, you'll see much more detail about the monitor's +performance over time. The details vary by monitor type, but for every monitor at the top of the +page you'll see: + +* The monitor's *name* with a down arrow icon that you can use to quickly move between monitors. +* The *location* of the monitor. If the same monitor configuration was used to create monitors in + multiple locations, you'll also see a down arrow icon that you can use to quickly move between + locations that use the same configuration. +* The latest *status* and when the monitor was *last run*. +* The *image:images/icons/beaker.svg[Beaker icon] Run test manually* button that allows you to run the test on +demand before the next scheduled run. ++ +[NOTE] +==== +This is only available for monitors running on Elastic's global managed testing infrastructure. +It is not available for monitors running on {private-location}s. +==== + +* The *image:images/icons/pencil.svg[Pencil icon] Edit monitor* button that allows you to edit the monitor's + configuration. + +[role="screenshot"] +image::images/synthetics-analyze-individual-monitor-header.png[Header at the top of the individual monitor page for all monitor types in the {synthetics-app}] + +Each individual monitor's page has three tabs: Overview, History, and Errors. + +[discrete] +[[synthetics-analyze-individual-monitors-overview]] +== Overview + +The *Overview* tab has information about the monitor availability, duration, and any errors +that have occurred since the monitor was created. +The _Duration trends_ chart displays the timing for each check that was performed in the last 30 days. +This visualization helps you to gain insights into how quickly requests resolve by the targeted endpoint +and gives you a sense of how frequently a host or endpoint was down. + +[role="screenshot"] +image::images/synthetics-analyze-individual-monitor-details.png[Details in the Overview tab on the individual monitor page for all monitor types in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-individual-monitors-history]] +== History + +The *History* tab has information on every time the monitor has run. +It includes some high-level stats and a complete list of all test runs. +Use the calendar icon (image:images/icons/calendar.svg[Calendar icon]) and search bar +to filter for runs that occurred in a specific time period. + +// What you might do with this info +// ... + +For browser monitors, you can click on any run in the *Test runs* list +to see the details for that run. Read more about what information is +included the in <> section below. + +[role="screenshot"] +image::images/synthetics-analyze-individual-monitor-history.png[The History tab on the individual monitor page for all monitor types in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-individual-monitors-errors]] +== Errors + +The *Errors* tab has information on every time a run has failed. +It includes a high-level overview of all alerts and a complete list of all run failures. +Use the calendar icon (image:images/icons/calendar.svg[Calendar icon]) and search bar +to filter for runs that occurred in a specific time period. + +// What you might do with this info +// ... + +For browser monitors, you can click on any run in the *Error* list +to open an *Error details* page that includes most of the same information +that is included the in <> section below. + +[role="screenshot"] +image::images/synthetics-analyze-individual-monitor-errors.png[The Errors tab on the individual monitor page for all monitor types in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-journeys]] += Browser monitors + +For browser monitors, you can look at results at various levels of granularity: + +* See an overview of journey runs over time. +* Drill down into the details of a single run. +* Drill down further into the details of a single _step_ within a journey. + +[discrete] +== Journey runs over time + +The journey page on the Overview tab includes: + +* An overview of the *last test run* including high-level information for each step. +* *Alerts* to date including both active and recovered alerts. +* *Duration by step* over the last 24 hours. +* A list of the *last 10 test runs* that link to the <>. + +[role="screenshot"] +image::images/synthetics-analyze-journeys-over-time.png[Individual journey page for browser monitors in the {synthetics-app}] + +From here, you can either drill down into: + +* The latest run of the full journey by clicking *image:images/icons/inspect.svg[Inspect icon] View test run* + or a past run in the list of *Last 10 test runs*. + This will take you to the view described below in <>. +* An individual step in this run by clicking the performance breakdown icon + (image:images/icons/apmTrace.svg[Performance breakdown icon]) next to one of the steps. + This will take you to the view described below in <>. + +[discrete] +[[synthetics-analyze-one-run]] +== Details for one run + +The page detailing one run for a journey includes more information on each step in the current run +and opportunities to compare each step to the same step in previous runs. + +// What info it includes +At the top of the page, see the _Code executed_ and any _Console_ output for each step. +If the step failed, this will also include a _Stacktrace_ tab that you can use to +diagnose the cause of errors. + +Navigate through each step using *image:images/icons/arrowLeft.svg[Previous icon] Previous* and +*Next image:images/icons/arrowRight.svg[Next icon]*. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-run-code-executed.png[Step carousel on a page detailing one run of a browser monitor in the {synthetics-app}] + +// What info it includes +Scroll down to dig into the steps in this journey run. +Click the image:images/icons/arrowRight.svg[Arrow right icon] icon next to the step number to show details. +The details include metrics for the step in the current run and the step in the last successful run. +Read more about step-level metrics below in <> and +<>. + +// What you might do with this info +This is particularly useful to compare the metrics for a failed step to the last time it completed successfully +when trying to diagnose the reason it failed. + +// Screenshot of the viz +[role="screenshot"] +image:images/synthetics-analyze-one-run-compare-steps.png[Step list on a page detailing one run of a browser monitor in the {synthetics-app}] + +Drill down to see even more details for an individual step by clicking the performance breakdown icon +(image:images/icons/apmTrace.svg[Performance breakdown icon]) next to one of the steps. +This will take you to the view described below in <>. + +[discrete] +[[synthetics-analyze-one-step]] +== Details for one step + +After clicking the performance breakdown icon (image:images/icons/apmTrace.svg[Performance breakdown icon]) +you'll see more detail for an individual step. + +[discrete] +[[synthetics-analyze-one-step-screenshot]] +=== Screenshot + +// What info it includes +By default the synthetics library will capture a screenshot for each step regardless of +whether the step completed or failed. + +[NOTE] +==== +Customize screenshot behavior for all monitors in the <>, +for one monitor using <>, or for a run using +the <>. +==== + +// What you might do with this info +Screenshots can be particularly helpful to identify what went wrong when a step fails because of a change to the UI. +You can compare the failed step to the last time the step successfully completed. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-step-screenshot.png[Screenshot for one step in a browser monitor in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-one-step-timing]] +=== Timing + +The *Timing* visualization shows a breakdown of the time spent in each part of +the resource loading process for the step including: + +* *Blocked*: The request was initiated but is blocked or queued. +* *DNS*: The DNS lookup to convert the hostname to an IP Address. +* *Connect*: The time it took the request to connect to the server. + Lengthy connections could indicate network issues, connection errors, or an overloaded server. +* *TLS*: If your page is loading resources securely over TLS, this is the time it took to set up that connection. +* *Wait*: The time it took for the response generated by the server to be received by the browser. + A lengthy Waiting (TTFB) time could indicate server-side issues. +* *Receive*: The time it took to receive the response from the server, + which can be impacted by the size of the response. +* *Send*: The time spent sending the request data to the server. + +Next to each network timing metric, there's an icon that indicates whether the value is +higher (image:images/icons/sortUp.svg[Value is higher icon]), +lower (image:images/icons/sortDown.svg[Value is lower icon]), +or the same (image:images/icons/minus.svg[Value is the same]) +compared to the median of all runs in the last 24 hours. +Hover over the icon to see more details in a tooltip. + +// What you might do with this info +This gives you an overview of how much time is spent (and how that time is spent) loading resources. +This high-level information may not help you diagnose a problem on its own, but it could act as a +signal to look at more granular information in the <> section. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-step-timing.png[Network timing visualization for one step in a browser monitor in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-one-step-metrics]] +=== Metrics + +// What info it includes +The *Metrics* visualization gives you insight into the performance of the web page visited in +the step and what a user would experience when going through the current step. +Metrics include: + +* *First contentful paint (FCP)* focuses on the initial rendering and measures the time from + when the page starts loading to when any part of the page's content is displayed on the screen. +* *Largest contentful paint (LCP)* measures loading performance. To provide a good user experience, + LCP should occur within 2.5 seconds of when the page first starts loading. +* *Cumulative layout shift (CLS)* measures visual stability. To provide a good user experience, + pages should maintain a CLS of less than 0.1. +* *`DOMContentLoaded` event (DCL)* is triggered when the browser completes parsing the document. + Helpful when there are multiple listeners, or logic is executed: + `domContentLoadedEventEnd - domContentLoadedEventStart`. +* *Transfer size* represents the size of the fetched resource. The size includes the response header + fields plus the response payload body. + +[NOTE] +==== +Largest contentful paint and Cumulative layout shift are part of Google's +https://web.dev/vitals/[Core Web Vitals], an initiative that introduces a set of metrics +that help categorize good and bad sites by quantifying the real-world user experience. +==== + +Next to each metric, there's an icon that indicates whether the value is +higher (image:images/icons/sortUp.svg[Value is higher icon]), +lower (image:images/icons/sortDown.svg[Value is lower icon]), +or the same (image:images/icons/minus.svg[Value is the same]) +compared to all runs over the last 24 hours. +Hover over the icon to see more details in a tooltip. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-step-metrics.png[Metrics visualization for one step in a browser monitor in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-one-step-object]] +=== Object weight and count + +// What info it includes +The *Object weight* visualization shows the cumulative size of downloaded resources by type, +and *Object count* shows the number of individual resources by type. + +// What you might do with this info +This provides a different kind of analysis. +For example, you might have a large number of JavaScript files, +each of which will need a separate download, but they may be collectively small. +This could help you identify an opportunity to improve efficiency by combining multiple files into one. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-step-object.png[Object visualization for one step in a browser monitor in the {synthetics-app}] + +[discrete] +[[synthetics-analyze-one-step-network]] +=== Network requests + +// What info it includes +The *Network requests* visualization is a waterfall chart that shows every request +the page made when a user executed it. +Each line in the chart represents an HTTP network request and helps you quickly identify +what resources are taking the longest to load and in what order they are loading. + +The colored bars within each line indicate the time spent per resource. +Each color represents a different part of that resource's loading process +(as defined in the <> section above) and +includes the time spent downloading content for specific +Multipurpose Internet Mail Extensions (MIME) types: +HTML, JS, CSS, Media, Font, XHR, and Other. + +Understanding each phase of a request can help you improve your site's speed by +reducing the time spent in each phase. + +// Screenshot of the viz +[role="screenshot"] +image::images/synthetics-analyze-one-step-network.png[Network requests waterfall visualization for one step in a browser monitor in the {synthetics-app}] + +Without leaving the waterfall chart, you can view data points relating to each resource: +resource details, request headers, response headers, and certificate headers. +On the waterfall chart, select a resource name, or any part of each row, +to display the resource details overlay. + +For additional analysis, whether to check the content of a CSS file or to view a specific image, +click the image:images/icons/popout.svg[External link icon] icon located beside each resource, +to view its content in a new tab. + +You can also navigate between steps and checks at the top of the page to +view the corresponding waterfall charts. + +// [discrete] +// [[synthetics-analyze-anomalies]] +// = Anomalies + +// [discrete] +// [[synthetics-analyze-alerts]] +// = Alerts diff --git a/docs/en/observability/synthetics-command-reference.asciidoc b/docs/en/observability/synthetics-command-reference.asciidoc index 8845225785..1a08303afe 100644 --- a/docs/en/observability/synthetics-command-reference.asciidoc +++ b/docs/en/observability/synthetics-command-reference.asciidoc @@ -1,17 +1,17 @@ [[synthetics-command-reference]] -= Synthetics command reference += Use the Synthetics CLI ++++ -Command reference +Use the CLI ++++ beta[] [discrete] [[elastic-synthetics-command]] -= `elastic-synthetics` += `@elastic/synthetics` -{heartbeat} uses the `npx @elastic/synthetics` command to run and report synthetic tests. +The {synthetics-app} uses the `npx @elastic/synthetics` command to run and report synthetic tests. It can also be used locally to help develop your tests. [source,sh] @@ -20,9 +20,8 @@ npx @elastic/synthetics [options] [files] [dir] ---- You will not need to use most command line flags -- they have been implemented -purely to interact with {heartbeat}. -However, there are some you may find useful. -They are documented below. +purely to interact with the {synthetics-app}. +However, there are some you may find useful: *`--debug`*:: Prints debug info. @@ -60,7 +59,7 @@ Shows help for the `npx @elastic/synthetics` command. [discrete] [[elastic-synthetics-init-command]] -= `elastic-synthetics init` += `@elastic/synthetics init` Scaffold a new project using Elastic Synthetics. @@ -73,9 +72,11 @@ These journeys can be edited and then pushed to {kib} to create monitors. npx @elastic/synthetics init ---- +Read more about what's included in a template project in <>. + [discrete] [[elastic-synthetics-push-command]] -= `elastic-synthetics push` += `@elastic/synthetics push` Create monitors in {kib} by using your local journeys. @@ -108,14 +109,14 @@ However there are some limitations when using external packages: `--auth`:: API key used for {kibana-ref}/api-keys.html[{kib} authentication]. + -If you are pushing to a <>, you must use an API key generated in 8.4 or higher. +If you are pushing to a <>, you must use an API key generated in 8.4 or higher. + To create an API key, you must be logged into {kib} as a user with the following privileges: + * {ref}/security-privileges.html#privileges-list-cluster[Cluster privileges]: _At least_ one of `manage_own_api_key`, `manage_security`, or `manage_api_key` * {kibana-ref}/kibana-privileges.html[{kib} privileges]: ** _If using one or more public locations_: `All` for *Synthetics and Uptime* in the *Observability* section. -** _If using one or more private locations_: `All` for both *Fleet* and *Integrations* in the *Management* section. +** _If using one or more {private-location}s_: `All` for both *Fleet* and *Integrations* in the *Management* section. `--url`:: The {kib} URL for the deployment to which you want to upload the monitors. @@ -137,7 +138,7 @@ it using a _different_ ID, it will create duplicates of all monitors in the proj [discrete] [[elastic-synthetics-locations-command]] -= `elastic-synthetics locations` += `@elastic/synthetics locations` List all available locations for running synthetics monitors. @@ -148,8 +149,10 @@ npx @elastic/synthetics locations --url --auth Run `npx @elastic/synthetics locations` with no flags to list all the available global locations managed by Elastic for running synthetics monitors. +To list both locations on Elastic's global managed infrastructure and {private-locations}, include: + `--url`:: -The {kib} URL for the deployment from which to fetch all available public and private locations. +The {kib} URL for the deployment from which to fetch all available public and {private-location}s. `--auth`:: API key used for {kibana-ref}/api-keys.html[{kib} authentication]. diff --git a/docs/en/observability/synthetics-configuration.asciidoc b/docs/en/observability/synthetics-configuration.asciidoc index a07e86159a..b767c3c3cb 100644 --- a/docs/en/observability/synthetics-configuration.asciidoc +++ b/docs/en/observability/synthetics-configuration.asciidoc @@ -1,8 +1,8 @@ [[synthetics-configuration]] -= Synthetic tests configuration += Configure Synthetics projects ++++ -Synthetic tests configuration +Configure projects ++++ beta[] @@ -89,7 +89,7 @@ A unique identifier for this monitor. `name` (`string`):: A human readable name for the monitor. `tags` (`Array`):: -A list of tags that will be sent with the monitor event. Tags are displayed in the {uptime-app} and allow you to search monitors by tag. +A list of tags that will be sent with the monitor event. Tags are displayed in the {synthetics-app} and allow you to search monitors by tag. `schedule` (`number`):: The interval (in minutes) at which the monitor should run. `enabled` (`boolean`):: @@ -100,19 +100,19 @@ Where to deploy the monitor. Monitors can be deployed in multiple locations so t To list available locations you can: + * Run the <>. -* Go to *{uptime-app}* -> *Monitor Management* and click *Add monitor*. -Locations will be listed in _Monitor locations_. +* Go to *Synthetics* -> *Management* and click *Create monitor*. +Locations will be listed in _Locations_. `privateLocations` (`Array`):: -The <> to which the monitors will be deployed. These private locations refer to locations hosted and managed by you, whereas -`locations` are hosted by Elastic. You can specify a private location using the location's name. +The <> to which the monitors will be deployed. These {private-location}s refer to locations hosted and managed by you, whereas +`locations` are hosted by Elastic. You can specify a {private-location} using the location's name. + -To list available private locations you can: +To list available {private-location}s you can: + * Run the <> with the {kib} URL for the deployment from which to fetch available locations. -* Go to *{uptime-app}* -> *Monitor Management* and click *Add monitor*. -Private locations will be listed in _Monitor locations_ with a "Private" badge next to their names. +* Go to *Synthetics* -> *Management* and click *Create monitor*. +{private-location}s will be listed in _Locations_. `throttling` (`boolean` | https://github.com/elastic/synthetics/blob/{synthetics_version}/src/common_types.ts#L194-L198[`ThrottlingOptions`]):: Control the monitor's download speeds, upload speeds, and latency to simulate your application's behavior on slower or laggier networks. Set to `false` to disable throttling altogether. diff --git a/docs/en/observability/synthetics-create-test.asciidoc b/docs/en/observability/synthetics-create-test.asciidoc index 0028efc51f..245f1455b6 100644 --- a/docs/en/observability/synthetics-create-test.asciidoc +++ b/docs/en/observability/synthetics-create-test.asciidoc @@ -87,7 +87,7 @@ journey('Journey name', ({ page, browser, context, params, request }) => { = Add steps A journey consists of one or more _steps_. Steps are actions that should be completed in a specific order. -Steps are displayed individually in the {uptime-app} along with screenshots for convenient debugging and error tracking. +Steps are displayed individually in the {synthetics-app} along with screenshots for convenient debugging and error tracking. A basic two-step journey would look like this: diff --git a/docs/en/observability/synthetics-get-started-project.asciidoc b/docs/en/observability/synthetics-get-started-project.asciidoc index 2cf9773b0b..0caf12b8e4 100644 --- a/docs/en/observability/synthetics-get-started-project.asciidoc +++ b/docs/en/observability/synthetics-get-started-project.asciidoc @@ -1,27 +1,27 @@ [[synthetics-get-started-project]] -= Create monitors with Project Monitors += Create monitors with {project-monitors-cap} ++++ -Use Project Monitors +Use {project-monitors-cap} ++++ beta[] -Projects are the most powerful and sophisticated way to configure synthetic monitors in the {stack}. Projects let you define your infrastructure as code, more commonly known as IaaC or Git-ops. With Project Monitors you organize your YAML configuration and JavaScript- or TypeScript-defined monitors on the filesystem, use Git for version control, and deploy via a CLI tool, usually executed on a CI/CD platform. +Projects are the most powerful and sophisticated way to configure synthetic monitors in the {stack}. Projects let you define your infrastructure as code, more commonly known as IaaC or Git-ops. With {project-monitors} you organize your YAML configuration and JavaScript- or TypeScript-defined monitors on the filesystem, use Git for version control, and deploy via a CLI tool, usually executed on a CI/CD platform. image::images/synthetics-get-started-projects.png[] // add text description -This is one of <> you can use to set up a synthetic monitor. +This is one of <> you can use to set up a synthetic monitor. [discrete] = Prerequisites -To try this beta functionality, first you need to enable Monitor Management in {kib}: +To try this beta functionality, first you need to enable it in {kib}: -. Go to **{observability}** -> **Uptime**. -. Click **Monitor Management**. -. Review the terms and conditions and click **Enable** to start using Monitor Management. +. Go to **{observability}** -> **Synthetics (beta)**. +. On the **Management** tab, review the terms and conditions and + click **Enable** to start using the {synthetics-app}. [IMPORTANT] ====== @@ -50,22 +50,20 @@ npm install -g @elastic/synthetics npx @elastic/synthetics -h ---- -[NOTE] -==== You should also decide where you want to run the monitors before getting started. -You can run Project Monitors on one or both of the following: +You can run {project-monitors} on one or both of the following: * *Elastic's global managed testing infrastructure*: With Elastic's global managed testing infrastructure, you can create and run monitors in multiple locations without having to manage your own infrastructure. Elastic takes care of software updates and capacity planning for you. -* *Private locations*: Private locations allow you to run monitors from your own premises. - To use private locations you must create a private location before continuing. +* *{private-location}s*: {private-location}s allow you to run monitors from your own premises. + To use {private-location}s you must create a {private-location} before continuing. For step-by-step instructions, refer to <>. -==== [discrete] +[[synthetics-get-started-project-init]] = Create a project Start by creating your first project. Run the command below to create a new @@ -81,17 +79,19 @@ When complete, set the `SYNTHETICS_API_KEY` environment variable in your termina for authentication with your {stack}: . To generate an API key: -.. Go to **Monitor Management** in the {uptime-app}. -.. Click **API Keys**. -.. Click **Generate API key**. +.. Go to **Synthetics (beta)** in {kib}. +.. Click **Settings**. +.. Switch to the **Project API Keys** tab. +.. Click **Generate Project API key**. + -image::images/synthetics-monitor-management-api-key.png[API Keys tooltip on the Uptime app's Monitor Management page] +[role="screenshot"] +image::images/synthetics-monitor-management-api-key.png[Project API Keys tab in Synthetics settings] . Set the `SYNTHETICS_API_KEY` environment variable in your terminal. You will most likely want to set this permanently. This is done differently in https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_environment_variables?view=powershell-7.2#saving-changes-to-environment-variables[Powershell] and https://unix.stackexchange.com/a/117470[Bash]. -NOTE: If you are pushing to a <>, you must use an API key generated in 8.4 or higher. +NOTE: If you are pushing to a <>, you must use an API key generated in 8.4 or higher. Then, take a look at key files and directories inside your project: @@ -167,16 +167,16 @@ npx @elastic/synthetics journeys npx @elastic/synthetics push --auth $SYNTHETICS_API_KEY --url ---- -One monitor will appear on the **Monitor management** page for each journey or +One monitor will appear in the {synthetics-app} for each journey or lightweight monitor, and you'll manage all monitors from your local environment. For more details on using the `push` command, refer to <>. [NOTE] ==== -If you've <>, -you can `push` to that private location. +If you've <>, +you can `push` to that {private-location}. -To list available private locations, +To list available {private-location}s, run the <> with the {kib} URL for the deployment from which to fetch available locations. ==== @@ -184,7 +184,8 @@ with the {kib} URL for the deployment from which to fetch available locations. [discrete] = View in {kib} -Then, go to the {uptime-app} in {kib}. You should see your newly pushed monitors running. You can also go to the *Monitor Management* page to see the monitors' configuration settings. +Then, go to the {synthetics-app} in {kib}. You should see your newly pushed monitors running. +You can also go to the *Management* tab to see the monitors' configuration settings. [discrete] = Next steps @@ -193,4 +194,4 @@ Learn more about: * <> * <> -* <> +* <> diff --git a/docs/en/observability/synthetics-get-started-ui.asciidoc b/docs/en/observability/synthetics-get-started-ui.asciidoc index 1a3fdcb988..386115a2ad 100644 --- a/docs/en/observability/synthetics-get-started-ui.asciidoc +++ b/docs/en/observability/synthetics-get-started-ui.asciidoc @@ -1,29 +1,29 @@ [[synthetics-get-started-ui]] -= Create monitors in the {uptime-app} UI += Create monitors in the {synthetics-app} ++++ -Use the {uptime-app} +Use the {synthetics-app} ++++ beta[] -You can create synthetic monitors directly in the {uptime-app} UI in {kib}. +You can create synthetic monitors directly in the {synthetics-app} in {kib}. image::images/synthetics-get-started-ui.png[Diagram showing which pieces of software are used to configure monitors, create monitors, and view results when using the Uptime App. Described in detail in Diagram text description.] // add text description -This is one of <> you can use to set up a synthetic monitor. +This is one of <> you can use to set up a synthetic monitor. [discrete] [[uptime-set-up-prereq]] = Prerequisites -To try this beta functionality, first you need to enable Monitor Management in {kib}: +To try this beta functionality, first you need to enable it in {kib}: -. Go to **{observability}** -> **Uptime**. -. Click **Monitor Management**. -. Review the terms and conditions and click **Enable** to start using Monitor Management. +. Go to **{observability}** -> **Synthetics (beta)**. +. On the **Management** tab, review the terms and conditions and + click **Enable** to start using the {synthetics-app}. [IMPORTANT] ====== @@ -35,49 +35,49 @@ the following privileges: ====== [[private-locations]] -[NOTE] -==== -You should also decide where you want to run the monitors before getting started. +You should decide where you want to run the monitors before getting started. You can run monitors on one or both of the following: * *Elastic's global managed testing infrastructure*: With Elastic's global managed testing infrastructure, you can create and run monitors in multiple locations without having to manage your own infrastructure. Elastic takes care of software updates and capacity planning for you. -* *Private locations*: Private locations allow you to run monitors from your own premises. - To use private locations you must create a private location before continuing. +* *{private-location}s*: {private-location}s allow you to run monitors from your own premises. + To use {private-location}s you must create a {private-location} before continuing. For step-by-step instructions, refer to <>. -==== [discrete] [[uptime-set-up-app-add-monitors]] = Add a lightweight monitor -To use the {uptime-app}'s Monitor Management UI to add a lightweight monitor: - -. Go to the **Monitor Management** page. -. Click **Add monitor**. -. In _Monitor locations_, select one or more locations. -. Choose a _Monitor type_ and configure the monitor as needed. -. Click **Save monitor**. +To use the {synthetics-app} to add a lightweight monitor: -image::uptime-set-up-ui.asciidoc.png[Add monitor UI in {kib} in the Uptime App's Monitor Management] +. Go to **Synthetics (beta)** in {kib}. +. Click **Create monitor**. +. Set the monitor type to *HTTP Ping*, *TCP Ping*, or *ICMP Ping*. +. In _Locations_, select one or more locations. +. Set the _Frequency_, and configure the monitor as needed. +. Click *Advanced options* to see more ways to configure your monitor. +. (Optional) Click *Run test* to verify that the test is valid. +. Click **Create monitor**. ++ +[role="screenshot"] +image::uptime-set-up-ui.asciidoc.png[Synthetics Create monitor UI] [NOTE] ==== -If you've <>, -you'll see your new private location in the list of _Monitor locations_. -The new private location will have the _Location name_ you provided and -a "Private" badge next to its name. +If you've <>, +you'll see your new {private-location} in the list of _Locations_. -image::images/private-locations-monitor-locations.png[Screenshot of Monitor locations options including a private location] +[role="screenshot"] +image::images/private-locations-monitor-locations.png[Screenshot of Monitor locations options including a {private-location}] ==== [discrete] [[synthetics-get-started-ui-browser]] = Add a browser monitor -You can also create a browser monitor in the {uptime-app} using an *Inline script*. +You can also create a browser monitor in the {synthetics-app} using an *Inline script*. An inline script contains a single journey that you manage individually. Inline scripts can be quick to set up, but can also be more difficult to manage. @@ -86,51 +86,49 @@ which must be maintained directly in {kib}. If you depend on external packages, have your journeys next to your code repository, or want to embed and manage more than one journey from a single monitor configuration, -use <> instead. +use <> instead. -To use the {uptime-app}'s Monitor Management UI to add a browser monitor: +To use the {synthetics-app} to add a browser monitor: -. Go to the **Monitor Management** page. -. Click **Add monitor**. -. In _Monitor locations_, select one or more locations. -. Set the _Monitor type_ to *Browser*. -. Add steps to the *Inline script* code block directly. +. Click **Create monitor**. +. Set the monitor type to *Multistep*. +. In _Locations_, select one or more locations. +. Set the _Frequency_. +. Add steps to the *Script editor* code block directly. The `journey` keyword isn't required, and variables like `page` and `params` will be part of your script's scope. You cannot `import` any dependencies when using inline browser monitors. + [role="screenshot"] -image::images/uptime-app-inline-script.png[Configure a synthetic monitor using an inline script in Elastic {fleet}] +image::images/synthetics-ui-inline-script.png[Configure a synthetic monitor using an inline script in Elastic {fleet}] + [NOTE] ==== Alternatively, you can use the *Script recorder* option. You can use the Elastic Synthetics Recorder to interact with a web page, export journey code that reflects all the actions you took, -and upload the results to the {uptime-app}. +and upload the results to {synthetics-app}. For more information, refer to <>. ==== -. Click *Advanced Browser options* to see more ways to configure your monitor. +. Click *Advanced options* to see more ways to configure your monitor. + +** Use *Data options* to add context to the data coming from your monitors. ** Use the *Synthetics agent options* to provide fine-tuned configuration for the synthetics agent. Read more about available options in <>. -** Use *Throttling options* to control the monitor's network speed. -You can control the monitor's download and upload speeds and its latency to simulate your application's behavior on slower or laggier networks. -** Use *Data stream settings* to configure additional Data Stream options. . (Optional) Click *Run test* to verify that the test is valid. -. Click *Save monitor*. +. Click *Create monitor*. [discrete] [[uptime-app-view-in-kibana]] = View in {kib} -Navigate to the {uptime-app} in {kib}, where you can see screenshots of each run, +Navigate to the {synthetics-app} in {kib}, where you can see screenshots of each run, set up alerts in case of test failures, and more. -If a test does fail (shown as `down` in the {uptime-app}), you'll be able to view the step script that failed, +If a test does fail (shown as `down` in the {synthetics-app}), you'll be able to view the step script that failed, any errors, and a stack trace. -For more information, refer to <>. +For more information, refer to <>. [discrete] = Next steps diff --git a/docs/en/observability/synthetics-get-started.asciidoc b/docs/en/observability/synthetics-get-started.asciidoc index d4b31f1ac0..ee7d8fc628 100644 --- a/docs/en/observability/synthetics-get-started.asciidoc +++ b/docs/en/observability/synthetics-get-started.asciidoc @@ -1,44 +1,26 @@ [[synthetics-get-started]] = Get started +beta[] + To set up a synthetic monitor, you need to configure the monitor, run it, and send data back to {es}. -After setup is complete, the data will be available in the {uptime-app} in {kib} to view, analyze, and alert on. +After setup is complete, the data will be available in {kib} to view, analyze, and alert on. [[uptime-set-up-choose]] -There are three ways to set up a synthetic monitor: +There are two ways to set up a synthetic monitor: -* {heartbeat} -* Project Monitors -* The {uptime-app} UI +* {project-monitors-cap} +* The {synthetics-app} Read more about each option below, and choose the approach that works best for you. -[discrete] -[[choose-heartbeat]] -= {heartbeat} - -{heartbeat} is a lightweight daemon that you install on a remote server to periodically -check the status of your services and determine if they are available. Performance data is -then gathered and reported back to {heartbeat}, where it's formatted and sent to the {stack}. - -This approach is only recommended for <>, and -works well for system administrators wanting to configure lightweight -monitors using YAML files. *You should _not_ use this approach to create browser monitors.* -If you want to create browser monitors, use <> or the <> instead. - -Get started in <>. - -image:images/synthetics-get-started-heartbeat.png[] - [discrete] [[choose-projects]] -= Project Monitors - -beta[] += {project-monitors-cap} -With Elastic Project Monitors, you write tests in an external version-controlled +With Elastic {project-monitors-cap}, you write tests in an external version-controlled project using YAML for lightweight monitors and JavaScript or TypeScript for browser monitors. -Then, you use the `@elastic/synthetics` NPM library’s `push` command to create +Then, you use the `@elastic/synthetics` NPM library's `push` command to create monitors in {kib}. This approach works well if you want to create both browser monitors and lightweight @@ -47,17 +29,16 @@ However, **this functionality is in beta and is subject to change.** Get started in <>. -image:images/synthetics-get-started-projects.png[] +image::images/synthetics-get-started-projects.png[] +// add text description [discrete] [[choose-ui]] -= {uptime-app} += {synthetics-app} -beta[] - -The {uptime-app} is an application in {kib}. -You can create monitors directly in the {uptime-app} using the user interface. -To try out this beta functionality, you will need to enable Monitor Management. +The {synthetics-app} is an application in {kib}. +You can create monitors directly in the {synthetics-app} using the user interface. +// To try out this beta functionality, you will need to enable Monitor Management. This approach works well if you want to configure and update monitors using a UI in your browser. @@ -65,7 +46,9 @@ However, **this functionality is in beta and is subject to change.** Get started in <>. -image:images/synthetics-get-started-ui.png[] +image::images/synthetics-get-started-ui.png[Diagram showing which pieces of software are used to configure monitors, create monitors, and view results when using the Uptime App. Described in detail in Diagram text description.] + +// add text description [NOTE] ==== @@ -74,7 +57,7 @@ synthetic monitors that is no longer recommended. *Do not use the Elastic Synthetics integration to set up new monitors.* For details on how to migrate from Elastic Synthetics integration to -Project Monitors or the {uptime-app}, refer to <>. +{project-monitors} or the {synthetics-app}, refer to <>. If you've used the Elastic Synthetics integration to create monitors in the past and need to reference documentation about the integration, go to the diff --git a/docs/en/observability/synthetics-intro.asciidoc b/docs/en/observability/synthetics-intro.asciidoc new file mode 100644 index 0000000000..132717d4cb --- /dev/null +++ b/docs/en/observability/synthetics-intro.asciidoc @@ -0,0 +1,70 @@ +[[monitor-uptime-synthetics]] += Synthetic monitoring + +++++ +Synthetics (beta) +++++ + +beta[] + +[NOTE] +==== +The {synthetics-app} is for viewing result data from monitors created and managed +directly in the <> or managed externally +using <>. +This can include both lightweight and browser-based monitors, and can include monitors +running from either Elastic's global managed testing infrastructure or from +<>. + +To view result data from lightweight monitors running through {heartbeat} and configured with +a traditional `heartbeat.yml` file, use the <> instead of the {synthetics-app}. +==== + +Synthetics periodically checks the status of your services and applications. +Monitor the availability of network endpoints and services using the following types of monitors: + +* <> +* <> + +[role="screenshot"] +image::images/synthetics-monitor-page.png[{synthetics-app} in {kib}] + +[discrete] +[[monitoring-uptime]] +== Lightweight HTTP/S, TCP, and ICMP monitors + +You can monitor the status of network endpoints using the following lightweight checks: + +// lint ignore v4 v6 +|=== +| *HTTP monitor* | Monitor your website. The HTTP monitor checks to make sure specific endpoints return the correct +status code and display the correct text. +| *ICMP monitor* | Check the availability of your hosts. The ICMP monitor uses ICMP (v4 and v6) Echo +Requests to check the network reachability of the hosts you are pinging. This will tell you whether the +host is available and connected to the network, but doesn't tell you if a service on the host is running or +not. +| *TCP monitor* | Monitor the services running on your hosts. The TCP monitor checks individual ports +to make sure the service is accessible and running. +|=== + +To set up your first monitor, refer to <>. + +[discrete] +[[monitoring-synthetics]] +== Browser monitors + +Real browser synthetic monitoring enables you to test critical actions and requests that an end-user would make +on your site at predefined intervals and in a controlled environment. +Synthetic monitoring extends traditional end-to-end testing techniques because it allows your tests to run continuously on the cloud. +The result is rich, consistent, and repeatable data that you can trend and alert on. + +For example, you can test popular user journeys, like logging in, adding items to a cart, and checking +out -- actions that need to work for your users consistently. + +You can run automated synthetic monitoring projects on a real Chromium browser and +view each synthetic monitoring journey in {kib} side-by-side with your other monitors. + +Alerting helps you detect degraded performance or broken actions before your users do. +By receiving alerts early, you can fix issues before they impact your bottom line or customer experience. + +To set up your first monitor, refer to <>. diff --git a/docs/en/observability/synthetics-journeys.asciidoc b/docs/en/observability/synthetics-journeys.asciidoc index 80c582c034..b879cb977c 100644 --- a/docs/en/observability/synthetics-journeys.asciidoc +++ b/docs/en/observability/synthetics-journeys.asciidoc @@ -5,7 +5,7 @@ beta[] Browser monitors are a type of synthetic monitor. Synthetic monitoring extends traditional end-to-end testing techniques because it allows your tests to run continuously on the cloud. -With synthetic monitoring in the {uptime-app}, you can assert that your application continues to work after a deployment by reusing +With synthetic monitoring, you can assert that your application continues to work after a deployment by reusing the same journeys that you used to validate the software on your machine. You can use synthetic monitors to detect bugs caused by invalid states you couldn't predict and didn't write tests for. diff --git a/docs/en/observability/synthetics-lightweight.asciidoc b/docs/en/observability/synthetics-lightweight.asciidoc index 8a01a0da1d..6dee857f8f 100644 --- a/docs/en/observability/synthetics-lightweight.asciidoc +++ b/docs/en/observability/synthetics-lightweight.asciidoc @@ -1,6 +1,8 @@ [[synthetics-lightweight]] = Configure lightweight monitors +beta[] + To configure lightweight monitors define a set of `monitors` to check your remote hosts. Each `monitor` item is an entry in a YAML list and begins with a dash (`-`). You can define the type of monitor to use, the hosts to check, and other @@ -8,17 +10,11 @@ optional settings. Lightweight monitors can be configured using any of the following: -* *YAML files in Project Monitors*. beta[] +* *YAML files in {project-monitors}*. <> and configure monitors in YAML files in the `lightweight` directory. -* *{uptime-app} UI*. beta[] - <> in {kib} and configure monitors - using the Monitor Management UI. -* *YAML files in {heartbeat}*. - <> and configure monitors in the - `heartbeat.yml` config file, or in external dynamically loaded files located in the - directory referenced by `heartbeat.config.monitors.path`. Read more about these options - in {heartbeat-ref}/configuration-heartbeat-options.html[Configure {heartbeat} monitors]. +* *{synthetics-app}*. + <> in {kib} and configure monitors. [discrete] [[synthetics-monitor-types]] @@ -68,9 +64,8 @@ the {heartbeat} documentation. [NOTE] ==== -*If you are using Project Monitors or the {uptime-app} UI to configure lightweight monitors*, -it is important to note that while the most commonly used {heartbeat} configuration options -are supported, some configuration options are not yet supported in these beta products. +While the most commonly used {heartbeat} configuration options are supported, +some configuration options are not yet supported in {project-monitors} and the {synthetics-app}. ==== There are some common monitor configuration options that are the same for all monitors. diff --git a/docs/en/observability/synthetics-manage-monitors.asciidoc b/docs/en/observability/synthetics-manage-monitors.asciidoc index d3c5834bf6..d6335add51 100644 --- a/docs/en/observability/synthetics-manage-monitors.asciidoc +++ b/docs/en/observability/synthetics-manage-monitors.asciidoc @@ -1,11 +1,13 @@ [[synthetics-manage-monitors]] = Manage monitors +beta[] + After you've <>, you'll need to manage that monitor over time. This might include updating or permanently deleting an existing monitor. -If you're using Project Monitors, you should also set up a workflow that uses +If you're using {project-monitors}, you should also set up a workflow that uses <> in a production environment. @@ -20,7 +22,7 @@ You can also update the journey used in a browser monitor. For example, if you update the UI used in your application, you may want to update your journey's selectors and assertions. -include::tab-widgets/uptime-monitoring/manage-monitors-update-monitor-widget.asciidoc[] +include::tab-widgets/synthetics/manage-monitors-update-monitor-widget.asciidoc[] [discrete] [[manage-monitors-delete]] @@ -29,11 +31,10 @@ include::tab-widgets/uptime-monitoring/manage-monitors-update-monitor-widget.asc Eventually you might want to delete a monitor altogether. For example, if the user journey you were validating no longer exists. -include::tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-widget.asciidoc[] +include::tab-widgets/synthetics/manage-monitors-delete-monitor-widget.asciidoc[] Alternatively, you can temporarily disable a monitor by updating the monitor's -configuration in your journey's code or on the {uptime-app}'s Monitor Management -page using the _Enabled_ toggle. +configuration in your journey's code or in the {synthetics-app} using the _Enabled_ toggle. [discrete] [[synthetics-projects-best-practices]] @@ -42,7 +43,7 @@ page using the _Enabled_ toggle. IMPORTANT: This is only relevant to monitors created using projects. After you've <>, -there are some best practices you can implement to manage Project Monitors effectively. +there are some best practices you can implement to manage {project-monitors} effectively. [discrete] [[synthetics-version-control]] diff --git a/docs/en/observability/synthetics-manage-retention.asciidoc b/docs/en/observability/synthetics-manage-retention.asciidoc index aed12ecfbf..a1a55f1d72 100644 --- a/docs/en/observability/synthetics-manage-retention.asciidoc +++ b/docs/en/observability/synthetics-manage-retention.asciidoc @@ -1,6 +1,8 @@ [[synthetics-manage-retention]] = Manage data retention +beta[] + When you set up a synthetic monitor, data from the monitor is saved in {ref}/data-streams.html[{es} data streams], an append-only structure in {es}. diff --git a/docs/en/observability/synthetics-migrate-integration.asciidoc b/docs/en/observability/synthetics-migrate-integration.asciidoc index cd42ec9062..3f19f1366b 100644 --- a/docs/en/observability/synthetics-migrate-integration.asciidoc +++ b/docs/en/observability/synthetics-migrate-integration.asciidoc @@ -7,11 +7,11 @@ The Elastic Synthetics integration is a method for creating synthetic monitors that is no longer recommended. You should _not_ use the Elastic Synthetics integration to set up new monitors and -should make a plan to migrate existing monitors to use either *Project Monitors* or the *{uptime-app}*: +should make a plan to migrate existing monitors to use either *{project-monitors-cap}* or the *{synthetics-app}*: -* With Elastic *Project Monitors*, you write tests in an external version-controlled project +* With Elastic *{project-monitors-cap}*, you write tests in an external version-controlled project and use a CLI tool to push monitors to the {stack}. -* The *{uptime-app}* is an application in {kib} that you can use to configure and create +* The *{synthetics-app}* is an application in {kib} that you can use to configure and create monitors using a user interface. [discrete] @@ -19,10 +19,10 @@ should make a plan to migrate existing monitors to use either *Project Monitors* = Compare approaches Below is a comparison of how you used the {agent} integration to create -monitors and how you'll use the {uptime-app} or projects to create monitors: +monitors and how you'll use the {synthetics-app} or projects to create monitors: |=== -| | {agent} integration | Projects or the {uptime-app} +| | {agent} integration | Projects or the {synthetics-app} | *Supported monitors* | Supported both lightweight and browser monitors @@ -33,7 +33,7 @@ monitors and how you'll use the {uptime-app} or projects to create monitors: | You had to run monitors on your infrastructure. a| You can run monitors on both: -* Your infrastructure using <> +* Your infrastructure using <> * Elastic's global managed infrastructure | *Where you configure monitors* @@ -69,9 +69,9 @@ a| . Went to the *Integrations* page in {kib}. . Searched for and added the *Elastic Synthetics* integration. . Configured the monitor. . Created the monitor. -a| . Go to the *{uptime-app}* in {kib}. - . Go to *Monitor Management*. - . Click *Add monitor*. +a| . Go to *Synthetics (beta)* in {kib}. + . Go to *Management*. + . Click *Create monitor*. . Configure the monitor. . Create the monitor. @@ -83,11 +83,11 @@ Find more details in <>. = Where monitors run If you want to continue hosting on your infrastructure, you will need to create a -private location before creating monitors. +{private-location} before creating monitors. If you have already have an {agent} running using `elastic-agent-complete`, -you can <> -in the {uptime-app}. -To create a new private location from scratch, follow all instructions in +you can <> +in the {synthetics-app}. +To create a new {private-location} from scratch, follow all instructions in <>. Alternatively, you can start hosting on Elastic's global managed infrastructure. @@ -160,11 +160,11 @@ refer to <>. = How to use the UI If you created monitors solely via the Elastic Synthetics integration UI, -you can recreate monitors in the {uptime-app} UI. +you can recreate monitors in the {synthetics-app}. -The configuration options in the {uptime-app} UI look very similar to the +The configuration options in the {synthetics-app} look very similar to the Elastic Synthetics integration UI with a few exceptions. -In the {uptime-app} UI: +In the {synthetics-app}: . You will select one or more locations for each monitor. . You cannot use a ZIP URL for browser monitors. @@ -172,5 +172,5 @@ In the {uptime-app} UI: . You can test the configuration (including the journey for browser monitors) using *Run test* before creating the monitor. -For more information on getting started with the {uptime-app}, +For more information on getting started with the {synthetics-app}, refer to <>. diff --git a/docs/en/observability/synthetics-monitor-use.asciidoc b/docs/en/observability/synthetics-monitor-use.asciidoc index 67387fb348..355d744f02 100644 --- a/docs/en/observability/synthetics-monitor-use.asciidoc +++ b/docs/en/observability/synthetics-monitor-use.asciidoc @@ -9,8 +9,8 @@ beta[] [NOTE] ==== -This is only relevant for Project Monitors. -For more information on configuring browser monitors added in the {uptime-app} UI, +This is only relevant for {project-monitors}. +For more information on configuring browser monitors added in the {synthetics-app}, refer to <>. ==== @@ -22,7 +22,7 @@ You'll need to set a few configuration options: * **Give your monitor a name.** Provide a human readable name and a unique ID for the monitor. This will appear in {kib} where you can view and manage monitors after they're created. * **Set the schedule.** Specify the interval at which your tests will run. * **Specify where the monitors should run.** You can run monitors on Elastic's global managed testing infrastructure -or <> to run monitors from your own premises. +or <> to run monitors from your own premises. * **Set other options as needed.** There are several other options you can set to customize your implementation including params, tags, screenshot options, throttling options, and more. Configure each monitor directly in your `journey` code using `monitor.use`. diff --git a/docs/en/observability/synthetic-monitoring-visualizations.asciidoc b/docs/en/observability/synthetics-monitoring-visualizations.asciidoc similarity index 100% rename from docs/en/observability/synthetic-monitoring-visualizations.asciidoc rename to docs/en/observability/synthetics-monitoring-visualizations.asciidoc diff --git a/docs/en/observability/synthetics-params-secrets.asciidoc b/docs/en/observability/synthetics-params-secrets.asciidoc index f9d19883e6..0d9282f76f 100644 --- a/docs/en/observability/synthetics-params-secrets.asciidoc +++ b/docs/en/observability/synthetics-params-secrets.asciidoc @@ -5,12 +5,11 @@ beta[] You may need to use dynamically defined values in your synthetic scripts, which may sometimes be sensitive. -For instance, you may want to test a production website with a particular demo account whose password is only known to the team administering {heartbeat}. -Another scenario might be using a different URL when running the tests under {heartbeat} and then running them locally using the Synthetics agent. +For instance, you may want to test a production website with a particular demo account whose password is only known to the team managing the synthetic monitors. Solving these problems is where `params` come in. `params` are variables that you can use within a synthetic project. -They can be defined either in the project config file, the synthetics agent command line, or in a {heartbeat} YAML config file. +They can be defined either in the project config file or the synthetics agent command line. -You should also note that since synthetics is a full JavaScript environment, it is also possible to use regular environment variables via +NOTE: Because synthetics is a full JavaScript environment, it is also possible to use regular environment variables via the standard node `process.env` global object. [discrete] @@ -37,18 +36,24 @@ journey("My Journey", ({ page, params }) => { If you try to run the example above you'll notice an error because we haven't specified a value for the `url` parameter. Parameter values can be declared by any of the following methods: -* Declaring a default value for the parameter in a configuration file. -* Passing the `--params` CLI argument. -* Specifying the parameter in the {heartbeat} YAML config using the `params` option. +* In the _Global parameters_ tab of the <>. +* Declaring a default value for the parameter in a <>. +* Passing the `--params` <>. -The values in the configuration file are read first, then merged with either the CLI argument, or the {heartbeat} -option, with the CLI and {heartbeat} options taking precedence over the configuration file. +The values in the configuration file are read in the following order: -These options are discussed in detail in the sections below. +. *Global parameters*: The _Global parameters_ set in {kib} are read first. +. *Configuration file*: Then the _Global parameters_ are merged with any parameters defined in a configuration file. + If a parameter is defined in both {kib} *and* a configuration file, + the value in the configuration file will be used. +. *CLI*: Then the parameters defined in the configuration are merged with any parameters passed to the CLI `--params` argument. + If a parameter is defined in a configuration file *and* using the CLI argument, + the value defined using the CLI will be used. + When running a script using the CLI, {kib}-defined _Global parameters_ have no impact + on the test because it won't have access to {kib}. [discrete] [[synthetics-dynamic-configs]] -// lint ignore params = Use a config file to set params Use a `synthetics.config.js` or `synthetics.config.ts` file to define variables your tests always need to be defined. @@ -69,58 +74,38 @@ export default (env) => { }; ---- -Note that we use the `env` variable in the above example, which corresponds to the value of the `NODE_ENV` environment variable -, or the `environment` parameter in the `browser` monitor definition when using {heartbeat}. +The example above uses the `env` variable, which corresponds to the value of the `NODE_ENV` environment variable. [discrete] [[synthetics-cli-params]] -// lint ignore params = Use CLI arguments to set params To set parameters when running `elastic-synthetics` on the command line, use the `--params` or `-p` flag to the `elastic-synthetics` program. The provided map is merged over any existing variables defined in the `synthetics.config.{js,ts}` file. -To override the `url` parameter, you would run: `elastic-synthetics . --params '{"url": "http://localhost:8080"}'` +For example, to override the `url` parameter, you would run: -[discrete] -[[synthetics-hb-params]] -// lint ignore params -= Use {heartbeat} options to set params - -When running via {heartbeat} use the `params` option to set additional parameters, passed through the `--params` flag -mentioned above and have their values merged over any default values. In the example below we run the `todos` app, overriding the `url` -parameter. - -[source,yaml] +[source,sh] ---- -- name: Todos - id: todos - type: browser - schedule: "@every 3m" - tags: todos-app - params: - url: "https://www.elastic.co" - source: - inline: - script: |- - step("load homepage", async () => { - await page.goto(params.url); - }); - step("hover over products menu", async () => { - await page.hover('css=[data-nav-item=products]'); - }); +elastic-synthetics . --params '{"url": "http://localhost:8080"}' ---- [discrete] [[synthetics-secrets-sensitive]] = Working with secrets and sensitive values -Your synthetics scripts may require the use of passwords or other sensitive secrets that are not known till runtime. Before we continue, it is -important to remember that since synthetics scripts have no limitations, a malicious script author could write a synthetics journey that -exfiltrates `params` and other data at runtime. Therefore, it is generally best not to use truly sensitive passwords (e.g. an admin password to test an admin -panel, or a real credit card) in *any* synthetics tools. Instead, set up limited dummy accounts, or fake credit cards with limited functionality. +Your synthetics scripts may require the use of passwords or other sensitive secrets that are not known until runtime. + +[WARNING] +==== +Because synthetics scripts have no limitations, a malicious script author could write a +synthetics journey that exfiltrates `params` and other data at runtime. +Do *not* to use truly sensitive passwords (for example, an admin password or a real credit card) +in *any* synthetics tools. +Instead, set up limited demo accounts, or fake credit cards with limited functionality. +==== Use environment variables to handle any values needing encryption at rest. -The example below uses the syntax `${URL}` to reference a variable named `URL` in the environment: +The example below uses the syntax `${URL}` to reference a variable named `URL` defined in the environment: [source,yaml] ---- diff --git a/docs/en/observability/synthetics-private-location.asciidoc b/docs/en/observability/synthetics-private-location.asciidoc index ec33d2b89e..895b35b07f 100644 --- a/docs/en/observability/synthetics-private-location.asciidoc +++ b/docs/en/observability/synthetics-private-location.asciidoc @@ -1,12 +1,15 @@ [[synthetics-private-location]] = Monitor resources on private networks +beta[] + To monitor resources on private networks you can either: * Allow Elastic's global managed infrastructure to access your private endpoints. -* Use {agent} to create a Private Location. +* Use {agent} to create a {private-location}. -Private Locations via Elastic Agent require only outbound connections from your network, while allowing Elastic's global managed infrastructure to access a private endpoint requires +{private-location}s via Elastic Agent require only outbound connections from your network, +while allowing Elastic's global managed infrastructure to access a private endpoint requires inbound access, thus posing an additional risk that users must assess. [discrete] @@ -24,17 +27,12 @@ is a concern consider adding additional protection via user/password authenticat [[monitor-via-private-agent]] = Monitor via a private agent -IMPORTANT: This is only relevant to monitors created using the {uptime-app} or project monitors. - -beta[] - -Private locations allow you to run monitors from your own premises. -Before running a monitor on a private location, you'll need to: +{private-location}s allow you to run monitors from your own premises. +Before running a monitor on a {private-location}, you'll need to: * <>. * <> and enroll an {agent} in {fleet}. -// The agent will be used to run the monitors in your private locations. -* <> in the {uptime-app} UI. +* <> in the {synthetics-app}. [discrete] [[synthetics-private-location-fleet-agent]] @@ -49,15 +47,15 @@ refer to {fleet-guide}/agent-policy.html#create-a-policy[{agent} policy]. [IMPORTANT] ==== -A private location should be set up against an agent policy that runs on a single {agent}. -The {agent} must be **enrolled in Fleet** (Private Locations cannot be set up using **standalone** {agents}). -Do _not_ run the same agent policy on multiple agents being used for private locations, as you may -end up with duplicate or missing tests. Private locations do not currently load balance tests across +A {private-location} should be set up against an agent policy that runs on a single {agent}. +The {agent} must be **enrolled in Fleet** ({private-location}s cannot be set up using **standalone** {agents}). +Do _not_ run the same agent policy on multiple agents being used for {private-location}s, as you may +end up with duplicate or missing tests. {private-location}s do not currently load balance tests across multiple {agents}. See <> for information on increasing the capacity -within a private location. +within a {private-location}. -By default private locations are configured to allow two simultaneous browser tests and an unlimited number of lightweight checks. -As a result, if more than two browser tests are assigned to a particular private location, there may be a delay to run them. +By default {private-location}s are configured to allow two simultaneous browser tests and an unlimited number of lightweight checks. +As a result, if more than two browser tests are assigned to a particular {private-location}, there may be a delay to run them. ==== [discrete] @@ -69,7 +67,7 @@ and enroll an {agent} in {fleet}. [[synthetics-private-location-docker]] Elastic provides Docker images that you can use to run {fleet} and an {agent} more easily. -For monitors running on private locations, you _must_ use the `elastic-agent-complete` +For monitors running on {private-location}s, you _must_ use the `elastic-agent-complete` Docker image to create a self-hosted {agent} node. The standard {ecloud} or self-hosted {agent} will not work. @@ -133,22 +131,22 @@ Learn how in {fleet-guide}/agent-environment-variables.html[{agent} environment [discrete] [[synthetics-private-location-add]] -= Add a private location += Add a {private-location} -When the {agent} is running you can add a new private location in {kib}: +When the {agent} is running you can add a new {private-location} in {kib}: -. Go to **{observability}** -> **Uptime**. -. Click **Monitor Management**. -. Click **Private locations**. +. Go to **{observability}** -> **Synthetics (beta)**. +. Click **Settings**. +. Click **{private-location}s**. . Click **Add location**. . Give your new location a unique _Location name_ and select the _Agent policy_ you created above. . Click **Save**. [discrete] [[synthetics-private-location-scaling]] -= Scaling private locations += Scaling {private-location}s -By default private locations are configured to allow two simultaneous browser tests, and an unlimited number of lightweight checks. +By default {private-location}s are configured to allow two simultaneous browser tests, and an unlimited number of lightweight checks. These limits can be set via the environment variables `SYNTHETICS_LIMIT_{TYPE}`, where `{TYPE}` is one of `BROWSER`, `HTTP`, `TCP`, and `ICMP` for the container running the {agent} docker image. @@ -167,4 +165,4 @@ a factor of 5. In the previous example that would mean allocating 5 slots. [[synthetics-private-location-next]] = Next steps -Now you can add monitors to your private location in <> or using the <>. +Now you can add monitors to your {private-location} in <> or using the <>. diff --git a/docs/en/observability/synthetics-recorder.asciidoc b/docs/en/observability/synthetics-recorder.asciidoc index 645d1a15ad..b22bf112de 100644 --- a/docs/en/observability/synthetics-recorder.asciidoc +++ b/docs/en/observability/synthetics-recorder.asciidoc @@ -52,8 +52,8 @@ To edit a step name: Steps represent groups of actions that should be completed in a specific order. Breaking a journey into steps can make it easier to read the resulting code. -It can also make it easier to interpret results in the {uptime-app} since each step is -displayed individually in the {uptime-app} along with screenshots for convenient debugging and error tracking. +It can also make it easier to interpret results in the {synthetics-app} since each step is +displayed individually in the {synthetics-app} along with screenshots for convenient debugging and error tracking. By default, the Synthetics Recorder will group all actions in a single step, but you can break actions into any number of steps. diff --git a/docs/en/observability/synthetics-settings.asciidoc b/docs/en/observability/synthetics-settings.asciidoc new file mode 100644 index 0000000000..1165e5ad97 --- /dev/null +++ b/docs/en/observability/synthetics-settings.asciidoc @@ -0,0 +1,93 @@ +[[synthetics-settings]] += Configure Synthetics settings + +beta[] + +There are several Synthetics settings you can adjust in {kib}. + +[discrete] +[[synthetics-settings-alerting]] += Alerting + +Alerting enables you to detect complex conditions using *rules* across Observability apps +and send a notification using *connectors*. + +When you create a new synthetic monitor, a new default synthetics rule will be applied. +To edit the default rule: + +. Click *Alerts and rules* in the top bar. +. Click *Monitor status rule* to open a panel where you can edit the rule's configuration. + +However, the automatically created Synthetics internal alert is intentionally preconfigured, +and some configuration options can't be changed. +For example, you can't change how often it checks the rule. + +If you need specific alerting behavior, set up a different rule. +To view all existing rules or create a new rule: + +. Click *Alerts and rules* in the top bar. +. Click *Manage rules*. + +Read more about creating new rules in <>. + +In the *Alerting* tab on the Synthetics Settings page, you can add and configure connectors. +If you are running in Elastic Cloud, then an SMTP connector will automatically be configured, +allowing you to easily set up email alerts. +Read more about all available connectors in <>. + +[role="screenshot"] +image::images/synthetics-settings-alerting.png[Alerting tab on the Synthetics Settings page in {kib}] + +[discrete] +[[synthetics-settings-private-locations]] += {private-location}s + +{private-location}s allow you to run monitors from your own premises. + +In the *{private-location}s* tab, you can add and manage {private-location}s. +After you <> and <>, +this is where you will add the {private-location} so you can specify it as the location for +a monitor created using the {synthetics-app} or projects. + +[role="screenshot"] +image::images/synthetics-settings-private-locations.png[{private-location}s tab on the Synthetics Settings page in {kib}] + +[discrete] +[[synthetics-settings-global-parameters]] += Global parameters + +Global parameters can be defined once and used across the configuration of lightweight and browser-based monitors. + +In the *Global parameters* tab, you can define variables and parameters. +This is one of several methods you can use to define variables and parameters. +To learn more about the other methods and which methods take precedence over others, see <>. + +[role="screenshot"] +image::images/synthetics-settings-global-parameters.png[Global parameters tab on the Synthetics Settings page in {kib}] + +[discrete] +[[synthetics-settings-data-retention]] += Data retention + +When you set up a synthetic monitor, data from the monitor is saved in {ref}/data-streams.html[Elasticsearch data streams], +an append-only structure in Elasticsearch. +You can customize how long synthetics data is stored by creating your own index lifecycle policy +and attaching it to the relevant custom Component Template in Stack Management. + +In the *Data retention* tab, use the links to jump to the relevant policy for each data stream. +Learn more about the data included in each data stream in <>. + +[role="screenshot"] +image::images/synthetics-settings-data-retention.png[Data retention tab on the Synthetics Settings page in {kib}] + +[discrete] +[[synthetics-settings-api-keys]] += Project API keys + +Project API keys are used to push {project-monitors} remotely from a CLI or CD pipeline. + +In the *Project API keys* tab, you can generate project API keys to use with your projects. +Learn more about using API keys in <>. + +[role="screenshot"] +image::images/synthetics-settings-api-keys.png[Project API keys tab on the Synthetics Settings page in {kib}] diff --git a/docs/en/observability/synthetics-visualize.asciidoc b/docs/en/observability/synthetics-visualize.asciidoc deleted file mode 100644 index 1df2f4b6b2..0000000000 --- a/docs/en/observability/synthetics-visualize.asciidoc +++ /dev/null @@ -1,141 +0,0 @@ -[[synthetics-visualize]] -= Visualize journeys - -beta[] - -Synthetic monitoring journeys can be visualized in the {uptime-app} side-by-side with -your other Uptime monitors. - -[role="screenshot"] -image::images/synthetic-app-overview.png[Synthetics app overview] - -[discrete] -[[analyze-synthetic-journeys]] -== Analyze synthetic journeys - -On the *Monitors* table, you can click a listed journey to analyze it further -on the monitor *Overview* page. You can examine journey details, including its -availability, monitor ID, service availability per monitoring location, the timing -for each synthetic check performed, and check statuses over time. - -The *History* table lists the total count of all of the synthetic checks that completed or failed -during the journey. The timestamp for each check is also displayed, along with its duration. -For any failed checks, the error and the failed step are displayed. - -[role="screenshot"] -image::images/synthetics_overview.png[Synthetics overview page] - -[discrete] -[[review-synthetic-checks]] -== Review synthetic checks - -To drill down and review the steps performed by a synthetic check, select it in the *History* -table to view the synthetic check details page. - -For each synthetic step, the following details are displayed: - -* The status of each step: `succeeded`, `failed`, or `skipped`. -* Step name. -* A screenshot taken of the step. In the case of a failed step, the last good screenshot is displayed, -making it easier to compare the step with the previous time it succeeded. - -[role="screenshot"] -image::images/synthetics_check_details.png[Synthetics check details] - -You can expand the table row for each step to view the following additional information: - -* An error message in the case of a failed step. -* The script performed for the step. -* The console output listing any errors or warnings from your browser. -* A screenshot taken of the step. -* The stack trace in the case of a failed step to help you quickly debug what caused the error. - -Select *View performance breakdown* to view the waterfall chart for the synthetic check. - -[discrete] -[[synthetic-waterfall]] -== Waterfall chart - -[IMPORTANT] -==== -Elastic Synthetics is regularly updated. To view the waterfall chart, make sure you -are running the latest <>. -==== - -The waterfall chart provides a visualization of every request the page made when -a user executed it. Each line in the chart represents an HTTP network request and -helps you quickly identify what resources are taking the longest to load and in what -order they are loading. - -[role="screenshot"] -image::images/synthetics-waterfall.png[Synthetics waterfall chart] - -The colored bars within each line indicate the time spent per resource. Each color -represents a different part of that resource's loading process and -includes the time spent downloading content for specific Multipurpose Internet Mail -Extensions (MIME) types: HTML, JS, CSS, Media, Font, XHR, and Other. - -It's important to understand each phase of a request so you can improve your site's -speed by reducing the time spent in each one. - -// This is collapsed by default -[%collapsible] -.*HTTP request phases* -==== -Queued/Blocked:: -The request was initiated but is blocked or queued. - -DNS:: -The DNS lookup to convert the hostname to an IP Address. - -Connecting:: -The time it took the request to connect to the server. Lengthy connections could indicate -network issues, connection errors, or an overloaded server. - -TLS:: -If your page is loading resources securely over TLS, this is the time it took to set -up that connection. - -Sending request:: -The time spent sending the request data to the server. - -Waiting (TTFB):: -The time it took for the response generated by the server to be received by the browser. A -lengthy Waiting (TTFB) time could indicate server-side issues. -==== - -Without leaving the waterfall chart, you can view data points relating to each resource: -resource details, request headers, response headers, and certificate headers. On the -waterfall chart, select a resource name, or any part of each row, to display the -resource details overlay. - -For additional analysis, whether to check the content of a CSS file or to view a specific image, -click image:images/url-link-icon.png[View page] located beside each resource, -to view its content in a new tab. - -You can also navigate between steps and checks at the top of the page to view the -corresponding waterfall charts. - -[discrete] -[[synthetic-filtering]] -=== Filter network requests - -To help you quickly identify resources that impact your user experience, you can combine -searching for a network request name with the automated filter options to focus on specific MIME types. - -[role="screenshot"] -image::images/waterfall-filter.png[Waterfall filter] - -You can filter by XHR, HTML, JS, CSS, Font, and Media, to highlight the waterfall chart's matching -results. To remove even more noise from the chart, you can select only the matching requests to view and group. - -[discrete] -[[synthetics-alerting]] -== Alerts - -User journeys that are tested with synthetic monitoring need to consistently work for your users. -Alerting ensures any degraded performance or broken actions are fixed prior to impacts on your -bottom line or customers' experience. - -To receive notifications based on errors and degraded performance, -see <>. diff --git a/docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-content.asciidoc b/docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-content.asciidoc similarity index 65% rename from docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-content.asciidoc rename to docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-content.asciidoc index afcb0632f7..907fc046ac 100644 --- a/docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-content.asciidoc +++ b/docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-content.asciidoc @@ -1,15 +1,6 @@ -// tag::heartbeat[] - -If you <>, -delete the monitor entry in the `heartbeat.yml` file. - -// end::heartbeat[] - // tag::project[] -beta[] - -If you <>, +If you <>, you'll delete the monitor from the project source and push changes. For lightweight monitors, delete the monitor from the YAML file. @@ -23,12 +14,10 @@ The monitor associated with that journey that existed in {kib} will be deleted. // tag::ui[] -beta[] - -If you <>, -you can delete a lightweight or browser monitor in the {uptime-app}'s UI: +If you <>, +you can delete a lightweight or browser monitor in the {synthetics-app}: -. Go to *Monitor Management*. +. Go to *Management*. . Click the trash can icon next to the monitor you want to delete. // end::ui[] diff --git a/docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-widget.asciidoc b/docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-widget.asciidoc similarity index 57% rename from docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-widget.asciidoc rename to docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-widget.asciidoc index 6b31cef6dc..9354e0a173 100644 --- a/docs/en/observability/tab-widgets/uptime-monitoring/manage-monitors-delete-monitor-widget.asciidoc +++ b/docs/en/observability/tab-widgets/synthetics/manage-monitors-delete-monitor-widget.asciidoc @@ -3,40 +3,22 @@
-
-
-++++ - -include::manage-monitors-delete-monitor-content.asciidoc[tag=heartbeat] - -++++ -