Merge branch 'master' into update-reason-string

Author: michaelolo24

.github/workflows/sync-main-branch.yml

@@ -0,0 +1,26 @@
+# Synchronize all pushes to 'master' branch with 'main' branch to facilitate migration
+name: "Sync main branch"
+on:
+  push:
+    branches:
+      - master
+
+jobs:
+  sync_latest_from_upstream:
+    runs-on: ubuntu-latest
+    name: Sync latest commits from master branch
+
+    steps:
+      - name: Checkout target repo
+        uses: actions/checkout@v2
+        with:
+          ref: main
+
+      - name: Sync upstream changes
+        id: sync
+        uses: aormsby/Fork-Sync-With-Upstream-action@v3.0
+        with:
+          target_sync_branch: main
+          target_repo_token: ${{ secrets.KIBANAMACHINE_TOKEN }}
+          upstream_sync_branch: master
+          upstream_sync_repo: elastic/kibana

docs/apm/correlations.asciidoc

@@ -12,34 +12,33 @@ piece of hardware, like a host or pod. Or, perhaps a set of users, based on IP
 address or region, is facing increased latency due to local data center issues.
 
 To find correlations, select a service on the *Services* page in the {apm-app}
-and click **View correlations**.
+then select a transaction group from the *Transactions* tab.
 
 NOTE: Queries within the {apm-app} are also applied to the correlations.
 
 [discrete]
 [[correlations-latency]]
 ==== Find high transaction latency correlations
 
-The correlations on the *Latency* tab help you discover which attributes are
-contributing to increased transaction latency. 
+The correlations on the *Latency correlations* tab help you discover which
+attributes are contributing to increased transaction latency. 
 
 [role="screenshot"]
 image::apm/images/correlations-hover.png[Latency correlations]
 
 The progress bar indicates the status of the asynchronous analysis, which
 performs statistical searches across a large number of attributes. For large
-time ranges and services with high transaction throughput this might take some
-time. To improve performance, reduce the time range on the service overview
-page.
+time ranges and services with high transaction throughput, this might take some
+time. To improve performance, reduce the time range.
 
 The latency distribution chart visualizes the overall latency of the
-transactions in the service. If there are attributes that have a statistically
-significant correlation with slow response times, they are listed in a table
-below the chart. The table is sorted by correlation coefficients that range from
-0 to 1. Attributes with higher correlation values are more likely to contribute
-to high latency transactions. By default, the attribute with the highest
-correlation value is added to the chart. To see the latency distribution for
-other attributes, hover over their row in the table.
+transactions in the transaction group. If there are attributes that have a
+statistically significant correlation with slow response times, they are listed
+in a table below the chart. The table is sorted by correlation coefficients that
+range from 0 to 1. Attributes with higher correlation values are more likely to
+contribute to high latency transactions. By default, the attribute with the
+highest correlation value is added to the chart. To see the latency distribution
+for other attributes, hover over their row in the table.
 
 If a correlated attribute seems noteworthy, use the **Filter** quick links:
 

docs/apm/images/correlations-hover.png

@@ -285,7 +285,7 @@ With Security enabled, Reporting has two forms of access control: each user can
 
 [NOTE]
 ============================================================================
-The `xpack.reporting.roles` settings are for a deprecated system of access control in Reporting. It does not allow API Keys to generate reports, and it doesn't allow {kib} application privileges. We recommend you explicitly turn off reporting's deprecated access control feature by adding `xpack.reporting.roles.enabled: false` in kibana.yml. This will enable application privileges for reporting, as described in <<grant-user-access, granting users access to reporting>>.
+The `xpack.reporting.roles` settings are for a deprecated system of access control in Reporting. It does not allow API Keys to generate reports, and it doesn't allow {kib} application privileges. We recommend you explicitly turn off reporting's deprecated access control feature by adding `xpack.reporting.roles.enabled: false` in kibana.yml. This will enable you to create custom roles that provide application privileges for reporting, as described in <<grant-user-access, granting users access to reporting>>.
 ============================================================================
 
 [[xpack-reporting-roles-enabled]] `xpack.reporting.roles.enabled`::

docs/settings/reporting-settings.asciidoc

@@ -221,11 +221,12 @@ export class CiStatsReporter {
           ? `${error.response.status} response`
           : 'no response';
 
+        const seconds = attempt * 10;
         this.log.warning(
-          `failed to reach ci-stats service [reason=${reason}], retrying in ${attempt} seconds`
+          `failed to reach ci-stats service, retrying in ${seconds} seconds, [reason=${reason}], [error=${error.message}]`
         );
 
-        await new Promise((resolve) => setTimeout(resolve, attempt * 1000));
+        await new Promise((resolve) => setTimeout(resolve, seconds * 1000));
       }
     }
   }

packages/kbn-dev-utils/src/ci_stats_reporter/ci_stats_reporter.ts

@@ -59656,8 +59656,9 @@ class CiStatsReporter {
 
 
         const reason = error !== null && error !== void 0 && (_error$response = error.response) !== null && _error$response !== void 0 && _error$response.status ? `${error.response.status} response` : 'no response';
-        this.log.warning(`failed to reach ci-stats service [reason=${reason}], retrying in ${attempt} seconds`);
-        await new Promise(resolve => setTimeout(resolve, attempt * 1000));
+        const seconds = attempt * 10;
+        this.log.warning(`failed to reach ci-stats service, retrying in ${seconds} seconds, [reason=${reason}], [error=${error.message}]`);
+        await new Promise(resolve => setTimeout(resolve, seconds * 1000));
       }
     }
   }

packages/kbn-pm/dist/index.js

@@ -6,7 +6,7 @@ echo " -> Running APM cypress tests"
 cd "$XPACK_DIR"
 
 checks-reporter-with-killswitch "APM Cypress Tests" \
- node plugins/apm/scripts/ftr_e2e/cypress_run
+ node plugins/apm/scripts/test/e2e.js
 
 echo ""
 echo ""

test/scripts/jenkins_apm_cypress.sh

@@ -216,8 +216,8 @@ describe('getHealthServiceStatusWithRetryAndErrorHandling', () => {
       })
     ).toPromise();
 
-    expect(status.level).toEqual(ServiceStatusLevels.unavailable);
-    expect(status.summary).toEqual('Alerting framework is unavailable');
+    expect(status.level).toEqual(ServiceStatusLevels.degraded);
+    expect(status.summary).toEqual('Alerting framework is degraded');
     expect(status.meta).toBeUndefined();
   });
 
@@ -275,8 +275,8 @@ describe('getHealthServiceStatusWithRetryAndErrorHandling', () => {
       }),
       retryDelay
     ).subscribe((status) => {
-      expect(status.level).toEqual(ServiceStatusLevels.unavailable);
-      expect(status.summary).toEqual('Alerting framework is unavailable');
+      expect(status.level).toEqual(ServiceStatusLevels.degraded);
+      expect(status.summary).toEqual('Alerting framework is degraded');
       expect(status.meta).toEqual({ error: err });
     });
 

x-pack/plugins/alerting/server/health/get_state.test.ts

@@ -73,9 +73,7 @@ const getHealthServiceStatus = async (
   const level =
     doc.state?.health_status === HealthStatus.OK
       ? ServiceStatusLevels.available
-      : doc.state?.health_status === HealthStatus.Warning
-      ? ServiceStatusLevels.degraded
-      : ServiceStatusLevels.unavailable;
+      : ServiceStatusLevels.degraded;
   return {
     level,
     summary: LEVEL_SUMMARY[level.toString()],
@@ -102,10 +100,10 @@ export const getHealthServiceStatusWithRetryAndErrorHandling = (
       );
     }),
     catchError((error) => {
-      logger.warn(`Alerting framework is unavailable due to the error: ${error}`);
+      logger.warn(`Alerting framework is degraded due to the error: ${error}`);
       return of({
-        level: ServiceStatusLevels.unavailable,
-        summary: LEVEL_SUMMARY[ServiceStatusLevels.unavailable.toString()],
+        level: ServiceStatusLevels.degraded,
+        summary: LEVEL_SUMMARY[ServiceStatusLevels.degraded.toString()],
         meta: { error },
       });
     })

x-pack/plugins/alerting/server/health/get_state.ts

@@ -240,7 +240,7 @@ export class AlertingPlugin {
     );
 
     const serviceStatus$ = new BehaviorSubject<ServiceStatus>({
-      level: ServiceStatusLevels.unavailable,
+      level: ServiceStatusLevels.degraded,
       summary: 'Alerting is initializing',
     });
     core.status.set(serviceStatus$);