Now that https://github.com/elastic/beats/pull/9118 is merged, starting 7.1 users will be able configure Metricbeat for monitoring Kibana instances using a simpler syntax.
Previously, users would have to run `metricbeat modules enable kibana` to enable the `kibana` Metricbeat module, then configure the module for Stack Monitoring by manually editing `modules.d/kibana.yml`. Going forward, users will be able to achieve the same effect by running `metricbeat modules enable kibana-xpack`.
This PR updates the docs with this change.
Related: https://github.com/elastic/elasticsearch/pull/40879
* Move ui/flyout to overlay core service
* Remove onClose in parameter (use FlyoutSession instead)
* Fix tests
* Remove old inspector tests
* Proper TODO message
* Convert flyout service to class
* Use correct i18n
* Resolving weird merge conflicts
* Fix panel plugin test
* Change new platform access
* Add more tests
* Remove commented tests
* Revert test fix (core is actually not fixed yet)
* Fix tests
* Expose onClose as Observable
* Use jest.doMock
* Fix typos
* Core start() -> setup()
* Remove @extends EventEmitter docs
* Refactor and test flyoutservice
* Fix comments: promise -> observable
* Fix tests
* Explicitly define OverlaySetup
* Fix OverlaySetup type signature
* Update Core API review file and docs
* Remove redudant if case
* Change FlyoutRef.onClose into a promise
* Remove redundante cleanup
* Use promise.finally
* Remove targetDomElement from openFlyout()
There's no need to support multiple targetDomElements per FlyoutService
and the current implementation handled this use case incorrectly.
Instead of adding complexity to try to support it, remove this from the
function signature.
* Fix + test to ensure child components are unmounted when a new flyover is displayed
* Wrap flyover in i18n Context component
* TSlint -> ESlint + test improvements
* Generate core API docs from TSDoc comments (#32148)
* Generate core API docs from TSDoc comments
Uses api-extractor and api-documenter to generate documentation for
the Kibana core API from TSDoc comments in the source code.
Documentation can be generated using `npm run docs:api`.
I used --no-verify to ignore the following pre-commit hook errors:
1. Filenames MUST use snake_case - api-extractor.json
It's possible to specify a different config file, but I prefer to keep the "standard" config file name.
2. UNHANDLED ERROR: Unable to find tsconfig.json file selecting "common/core_api_review/kibana.api.ts". Ensure one exists and it is listed in "src/dev/typescript/projects.ts"
This is not a source file, so safe to ignore.
* Flesh out API docs a little bit
* Ignore snake_case check for api-extractor.json
* Ignore api-extractor's review file from pre-commit check
* Try to fix build failing by using masters yarn.lock
* I'm being stupid
* Found a better home for ignoring common/core_api_review/kibana.api.ts
* Node script for detecting core API changes
I initially wanted to include this as a precommit hook, but it takes
quite long to execute (~12s) so might be better suited as a test or
as part of the release process.
The script currently fails because api-extractor uses an older version
of typescript.
* Fix tslint precommit hook ignore condition
* Write tsdoc-metadata.json into ./build
* Add LogMeta and ElasticSearch to exported types & docs
* Suppress logging when running api-extractor from script
* Improve check_core_api_changes script and run as test
* Inline api-extractor.json config
* Fix check_core_api_changes --help flag
* LogMeta TSDoc comments
* check_core_api_changes: fail if api-extractor produces warnings or errors
And print more useful messages to the console
* Move ignored ts files list into dev/file
* Add back build:types since api-exporter cannot operate on source files
* Upgrade api-exporter/documenter
* api-extractor: independantly analyze core/public and core/server
Becasue of https://github.com/Microsoft/web-build-tools/issues/1029
api-extractor can't use core/index.ts as a single entry point for
analyzing the public and server API's as isolated namespaces.
Instead we analyze these projects separately. This introduces other
problems like the api review files and documentation always being
called "kibana." from the package.json filename.
* Build types as part of build task
* Include types in typescript browser compilation
* Force inclusion of core/public for building types
* Fix api review filename in api-exporter errors
* Update docs and API review files
* Fix api-extractor warnings
* Remove ts file ignored list since it's no longer necessary
* Rename exported api package name
* Review comments
* Export other missing types
* Upgrade api-documenter to latest beta
* Export more missing types
* Fix warnings and add api-exporter to Jenkins tests
* Correctly handle runBuildTypes() exceptions
* Fix another swallowed exception
* Fix api-extractor warnings after master merge
* Update yarn.lock
* Fix erraneous type
* Revert "Update yarn.lock"
This reverts commit 85a8093015.
* Revert "Fix erraneous type"
This reverts commit 7f0550c0ae.
* Backport https://github.com/elastic/kibana/pull/32440
* Update core api signature and docs
* Modify import APIs to handle special use cases from the previous import process
* Cleanup
* Add more examples to the docs
* Make title come from data inside file
* Fix some broken tests
* Fix docs
* Fix docs wording
* Apply PR feedback pt1
* Apply PR feedback pt2
* Add first draft of uptime docs.
* Add first draft of uptime docs.
* Implement PR feedback.
* Add role info to uptime docs
* Impelement some more PR feedback.
* Attempt to add more copy focusing on the 'why' of each piece of the docs.
* uptime docs: grammar, formatting, order
* move location of uptime docs
* Implement more PR feedback.
* Add screenshots.
* [@kbn/expect] "fork" expect.js into repo
* [eslint] autofix references to expect.js
* [tslint] autofix all expect.js imports
* now that expect.js is in strict mode, avoid reassigning fn.length
