[DOCS] Adds user-facing docs for the new KP logging configuration (#9…

…4993)

Co-authored-by: Lisa Cawley <[email protected]>

docs/developer/architecture/core/application_service.asciidoc

@@ -0,0 +1,40 @@
+[[application-service]]
+== Application service
+Kibana has migrated to be a Single Page Application. Plugins should use `Application service` API to instruct Kibana that an application should be loaded and rendered in the UI in response to user interactions. The service also provides utilities for controlling the navigation link state, seamlessly integrating routing between applications, and loading async chunks on demand.
+
+NOTE: The Application service is only available client side.
+
+[source,typescript]
+----
+import { AppMountParameters, CoreSetup, Plugin, DEFAULT_APP_CATEGORIES } from 'kibana/public';
+
+export class MyPlugin implements Plugin {
+  public setup(core: CoreSetup) {
+    core.application.register({ // <1>
+      category: DEFAULT_APP_CATEGORIES.kibana,
+      id: 'my-plugin',
+      title: 'my plugin title',
+      euiIconType: '/path/to/some.svg',
+      order: 100,
+      appRoute: '/app/my_plugin', // <2>
+      async mount(params: AppMountParameters) { // <3>
+        // Load application bundle
+        const { renderApp } = await import('./application');
+        // Get start services
+        const [coreStart, depsStart] = await core.getStartServices(); // <4>
+        // Render the application
+        return renderApp(coreStart, depsStart, params); // <5>
+      },
+    });
+  }
+}
+----
+<1> See {kib-repo}blob/{branch}/docs/development/core/public/kibana-plugin-core-public.applicationsetup.register.md[application.register interface]
+<2> Application specific URL.
+<3> `mount` callback is invoked when a user navigates to the application-specific URL.
+<4> `core.getStartServices` method provides API available during `start` lifecycle.
+<5> `mount` method must return a function that will be called to unmount the application, which is called when Kibana unmounts the application. You can put a clean-up logic there.
+
+NOTE: you are free to use any UI library to render a plugin application in DOM.
+However, we recommend using React and https://elastic.github.io/eui[EUI] for all your basic UI
+components to create a consistent UI experience.

docs/developer/architecture/core/configuration-service.asciidoc

@@ -0,0 +1,149 @@
+[[configuration-service]]
+== Configuration service
+{kib} provides `ConfigService` for plugin developers that want to support
+adjustable runtime behavior for their plugins.
+Plugins can only read their own configuration values, it is not possible to access the configuration values from {kib} Core or other plugins directly.
+
+NOTE: The Configuration service is only available server side.
+
+[source,js]
+----
+// in Legacy platform
+const basePath = config.get('server.basePath');
+// in Kibana Platform 'basePath' belongs to the http service
+const basePath = core.http.basePath.get(request);
+----
+
+To have access to your plugin config, you _should_:
+
+* Declare plugin-specific `configPath` (will fallback to plugin `id`
+if not specified) in {kib-repo}blob/{branch}/docs/development/core/server/kibana-plugin-core-server.pluginmanifest.md[`kibana.json`] manifest file.
+* Export schema validation for the config from plugin's main file. Schema is
+mandatory. If a plugin reads from the config without schema declaration,
+`ConfigService` will throw an error.
+
+*my_plugin/server/index.ts*
+[source,typescript]
+----
+import { schema, TypeOf } from '@kbn/config-schema';
+export const plugin = …
+export const config = {
+  schema: schema.object(…),
+};
+export type MyPluginConfigType = TypeOf<typeof config.schema>;
+----
+
+* Read config value exposed via `PluginInitializerContext`:
+
+*my_plugin/server/index.ts*
+[source,typescript]
+----
+import type { PluginInitializerContext } from 'kibana/server';
+export class MyPlugin {
+  constructor(initializerContext: PluginInitializerContext) {
+    this.config$ = initializerContext.config.create<MyPluginConfigType>();
+    // or if config is optional:
+    this.config$ = initializerContext.config.createIfExists<MyPluginConfigType>();
+  }
+  ...
+}
+----
+
+If your plugin also has a client-side part, you can also expose
+configuration properties to it using the configuration `exposeToBrowser`
+allow-list property.
+
+*my_plugin/server/index.ts*
+[source,typescript]
+----
+import { schema, TypeOf } from '@kbn/config-schema';
+import type { PluginConfigDescriptor } from 'kibana/server';
+
+const configSchema = schema.object({
+  secret: schema.string({ defaultValue: 'Only on server' }),
+  uiProp: schema.string({ defaultValue: 'Accessible from client' }),
+});
+
+type ConfigType = TypeOf<typeof configSchema>;
+
+export const config: PluginConfigDescriptor<ConfigType> = {
+  exposeToBrowser: {
+    uiProp: true,
+  },
+  schema: configSchema,
+};
+----
+
+Configuration containing only the exposed properties will be then
+available on the client-side using the plugin's `initializerContext`:
+
+*my_plugin/public/index.ts*
+[source,typescript]
+----
+interface ClientConfigType {
+  uiProp: string;
+}
+
+export class MyPlugin implements Plugin<PluginSetup, PluginStart> {
+  constructor(private readonly initializerContext: PluginInitializerContext) {}
+
+  public async setup(core: CoreSetup, deps: {}) {
+    const config = this.initializerContext.config.get<ClientConfigType>();
+  }
+----
+
+All plugins are considered enabled by default. If you want to disable
+your plugin, you could declare the `enabled` flag in the plugin
+config. This is a special {kib} Platform key. {kib} reads its
+value and won’t create a plugin instance if `enabled: false`.
+
+[source,js]
+----
+export const config = {
+  schema: schema.object({ enabled: schema.boolean({ defaultValue: false }) }),
+};
+----
+[[handle-plugin-configuration-deprecations]]
+=== Handle plugin configuration deprecations
+If your plugin has deprecated configuration keys, you can describe them using
+the `deprecations` config descriptor field.
+Deprecations are managed on a per-plugin basis, meaning you don’t need to specify
+the whole property path, but use the relative path from your plugin’s
+configuration root.
+
+*my_plugin/server/index.ts*
+[source,typescript]
+----
+import { schema, TypeOf } from '@kbn/config-schema';
+import type { PluginConfigDescriptor } from 'kibana/server';
+
+const configSchema = schema.object({
+  newProperty: schema.string({ defaultValue: 'Some string' }),
+});
+
+type ConfigType = TypeOf<typeof configSchema>;
+
+export const config: PluginConfigDescriptor<ConfigType> = {
+  schema: configSchema,
+  deprecations: ({ rename, unused }) => [
+    rename('oldProperty', 'newProperty'),
+    unused('someUnusedProperty'),
+  ],
+};
+----
+
+In some cases, accessing the whole configuration for deprecations is
+necessary. For these edge cases, `renameFromRoot` and `unusedFromRoot`
+are also accessible when declaring deprecations.
+
+*my_plugin/server/index.ts*
+[source,typescript]
+----
+export const config: PluginConfigDescriptor<ConfigType> = {
+  schema: configSchema,
+  deprecations: ({ renameFromRoot, unusedFromRoot }) => [
+    renameFromRoot('oldplugin.property', 'myplugin.property'),
+    unusedFromRoot('oldplugin.deprecated'),
+  ],
+};
+----

docs/developer/architecture/core/elasticsearch-service.asciidoc

@@ -0,0 +1,30 @@
+[[elasticsearch-service]]
+== Elasticsearch service
+`Elasticsearch service` provides `elasticsearch.client` program API to communicate with Elasticsearch server HTTP API.
+
+NOTE: The Elasticsearch service is only available server side. You can use the {kib-repo}blob/{branch}/docs/development/plugins/data/public/kibana-plugin-plugins-data-public.md[Data plugin] APIs on the client side.
+
+`elasticsearch.client` interacts with Elasticsearch service on behalf of:
+
+- `kibana_system` user via `elasticsearch.client.asInternalUser.*` methods.
+- a current end-user via `elasticsearch.client.asCurrentUser.*` methods. In this case Elasticsearch client should be given the current user credentials.
+See <<scoped-services>> and <<development-security>>.
+
+{kib-repo}blob/{branch}/docs/development/core/server/kibana-plugin-core-server.elasticsearchservicestart.md[Elasticsearch service API docs]
+
+[source,typescript]
+----
+import { CoreStart, Plugin } from 'kibana/public';
+
+export class MyPlugin implements Plugin {
+  public start(core: CoreStart) {
+    async function asyncTask() {
+      const result = await core.elasticsearch.client.asInternalUser.ping(…);
+    }
+    asyncTask();
+  }
+}
+----
+
+For advanced use-cases, such as a search, use {kib-repo}blob/{branch}/docs/development/plugins/data/server/kibana-plugin-plugins-data-server.md[Data plugin]
+

docs/developer/architecture/core/http-service.asciidoc

@@ -0,0 +1,67 @@
+[[http-service]]
+== HTTP service
+
+NOTE: The HTTP service is available both server and client side.
+
+=== Server side usage
+
+The server-side HttpService allows server-side plugins to register endpoints with built-in support for request validation. These endpoints may be used by client-side code or be exposed as a public API for users. Most plugins integrate directly with this service.
+
+The service allows plugins to:
+* to extend the {kib} server with custom HTTP API.
+* to execute custom logic on an incoming request or server response.
+* implement custom authentication and authorization strategy.
+
+See {kib-repo}blob/{branch}/docs/development/core/server/kibana-plugin-core-server.httpservicesetup.md[HTTP service API docs]
+
+[source,typescript]
+----
+import { schema } from '@kbn/config-schema';
+import type { CoreSetup, Plugin } from 'kibana/server';
+
+export class MyPlugin implements Plugin {
+  public setup(core: CoreSetup) {
+    const router = core.http.createRouter();
+    
+    const validate = {
+      params: schema.object({
+        id: schema.string(),
+      }),
+    };
+    
+    router.get({
+      path: 'my_plugin/{id}',
+      validate
+    },
+    async (context, request, response) => {
+      const data = await findObject(request.params.id);
+      if (!data) return response.notFound();
+      return response.ok({
+        body: data,
+        headers: {
+          'content-type': 'application/json'
+        }
+      });
+    });
+  }
+}
+----
+
+=== Client side usage
+
+The HTTP service is also offered on the client side and provides an API to communicate with the {kib} server via HTTP interface. 
+The client-side HttpService is a preconfigured wrapper around `window.fetch` that includes some default behavior and automatically handles common errors (such as session expiration). The service should only be used for access to backend endpoints registered by the same plugin. Feel free to use another HTTP client library to request 3rd party services.
+
+[source,typescript]
+----
+import { CoreStart } from 'kibana/public';
+interface ResponseType {…};
+interface MyPluginData {…};
+async function fetchData<ResponseType>(core: CoreStart) {
+  return await core.http.get<MyPluginData>(
+    '/api/my_plugin/',
+    { query: … },
+  ); 
+}
+----
+See {kib-repo}blob/{branch}/docs/development/core/public/kibana-plugin-core-public.httpsetup.md[for all available API].