* bump @elastic/elasticsearch to canary.7
* address errors in core
* address errors in data plugin
* address errors in Alerting team plugins
* remove outdated messages in Lens
* remove unnecessary comments in ML
* address errors in Observability plugin
* address errors in reporting plugin
* address errors in Rule registry plugin
* fix errors in Security plugins
* fix errors in ES-UI plugin
* remove unnecessary union.
* update core tests
* fix kbn-es-archiver
* update to canary 8
* bump to v9
* use new typings
* fix new errors in core
* fix errors in core typeings
* fix type errors in data plugin
* fix type errors in telemetray plugin
* fix data plugin tests
* fix search examples type error
* fix errors in discover plugin
* fix errors in index_pattern_management
* fix type errors in vis_type_*
* fix errors in typings/elasticsearch
* fix type errors in actions plugin
* fix type errors in alerting and apm plugins
* fix type errors in canvas and cases
* fix errors in event_log
* fix type errors in ILM and ingest_pipelines
* fix errors in lens plugin
* fix errors in lists plugin
* fix errors in logstash
* fix errors in metrics_entities
* fix errors in o11y
* fix errors in watcher
* fix errors in uptime
* fix errors in upgrade_assistant
* fix errors in task_manager
* fix errors in stack_alerts
* fix errors in security_solution
* fix errors in rule_registry
* fix errors in snapshot_restore
* fix remaining errors
* fix search intergration tests
* adjust assetion
* bump version to canary.10
* adapt code to new naming schema
* use mapping types provided by the client library
* Revert "adjust assetion"
This reverts commit
|
||
---|---|---|
.. | ||
.storybook | ||
common | ||
docs | ||
public | ||
scripts | ||
server | ||
types | ||
jest.config.js | ||
kibana.json | ||
README.md | ||
tsconfig.json |
The infra
plugin
This is the home of the infra
plugin, which aims to provide a solution for
the infrastructure monitoring use-case within Kibana.
UI Structure
The plugin provides two main apps in Kibana - the Metrics UI and the Logs UI. Both are reachable via their own main navigation items and via links from other parts of Kibana.
The Metrics UI consists of three main screens, which are the Inventory, the Node details and the Metrics explorer.
The Logs UI provides one log viewer screen.
Communicating
In order to address the whole infrastructure monitoring team, the @elastic/infra-logs-ui team alias can be used as a mention or in review requests.
The Infrastructure forum and Logs forum on Discuss are frequented by the team as well.
Contributing
Since the infra
plugin lives within the Kibana repository, Kibana's
contribution procedures apply. In addition to that,
this section details a few plugin-specific aspects.
Ingesting metrics for development
The Metrics UI displays ECS-compatible metric data from indices
matching the metricbeat-*
pattern by default. The primary way to ingest these
is by running Metricbeat to deliver metrics to the development Elasticsearch
cluster. It can be used to ingest development host metrics using the system
module.
A setup that ingests docker and nginx metrics is described in [./docs/test_setups/infra_metricbeat_docker_nginx.md].
Ingesting logs for development
Similarly, the Logs UI assumes ECS-compatible log data to be present in
indices matching the filebeat-*
pattern. At the time of writing the minimum
required fields are @timestamp
and message
, but the presence of other ECS
fields enable additional functionality such as linking to and from other
solutions.
The primary way to ingest such log data is via Filebeat. A convenient source of log entries are the Kibana and Elasticsearch log files produced by the development environment itself. These can easily be consumed by enabling the modules
$ filebeat modules enable elasticsearch
$ filebeat modules enable kibana
and then editing the modules.d/elasticsearch.yml
and modules.d/kibana.yml
to change the var.paths
settings to contain paths to the development
environment's log files, e.g.:
- module: elasticsearch
server:
enabled: true
var.paths:
- "${WORK_ENVIRONMENT}/kibana/.es/8.0.0/logs/elasticsearch_server.json"
var.convert_timezone: true
Creating PRs
As with all of Kibana, we welcome contributions from everyone. The usual life-cycle of a PR looks like the following:
- Create draft PR: To make ongoing work visible, we recommend creating
draft PRs as soon as possible. PRs are usually targetted at
master
and backported later. The checklist in the PR description template can be used to guide the progress of the PR. - Label the PR: To ensure that a newly created PR gets the attention of
the @elastic/infra-logs-ui team, the following label should be applied to
PRs:
Team:infra-logs-ui
Feature:Infra UI
if it relates to the Intrastructure UIFeature:Logs UI
if it relates to the Logs UI[zube]: In Progress
to track the stage of the PR- Version labels for merge and backport targets (see Kibana's contribution
procedures), usually:
- the version that
master
currently represents - the version of the next minor release
- the version that
- Release note labels (see Kibana's contribution procedures)
release_note:enhancement
if the PR contains a new feature or enhancementrelease_note:fix
if the PR contains an external-facing fixrelease_note:breaking
if the PR contains a breaking changerelease_note:deprecation
if the PR contains deprecations of publicly documented features.release_note:skip
if the PR contains only house-keeping changes, fixes to unreleased code or documentation changes
- Satisfy CI: The PR will automatically be picked up by the CI system,
which will run the full test suite as well as some additional checks. A
comment containing
jenkins, test this
can be used to manually trigger a CI run. The result will be reported on the PR itself. Out of courtesy for the reviewers the checks should pass before requesting reviews. - Request reviews: Once the PR is ready for reviews it can be marked as
such by changing the PR state to ready. In addition the label
[zube]: In Progress
should be replaced with[zube]: In Review
andreview
. If the GitHub automation doesn't automatically request a review from@elastic/infra-logs-ui
it should be requested manually. - Incorporate review feedback: Usually one reviewer's approval is sufficient. Particularly complicated or cross-cutting concerns might warrant multiple reviewers.
- Merge: Once CI is green and the reviewers are approve, PRs in the Kibana
repo are "squash-merged" to
master
to keep the history clean. - Backport: After merging to
master
, the PR is backported to the branches that represent the versions indicated by the labels. Theyarn backport
command can be used to automate most of the process.
There are always exceptions to the rule, so seeking guidance about any of the steps is highly recommended.