History

James Gowdy a0fded52eb [ML] Adding space aware jobs (#77916 ) * [ML] Adding space aware jobs * adding mlClient * switching to type includes * adding additional job checks * fixing conflict * adding dfa checks * refactoring jobs in spaces checks * filtering calendars * adding initial job object status and repair endpoints * enabling repair endpoint * fixing listed jobs in status * adding datafeed repair * updating shared services * adding results job id check * fixing conflicts * don't remove SO on delete * fixing non-ml plugins * filtering job audit messages * fixing types * fixing tests * adding job ids wildcard support * removing empty migration test * fixing tests and disabling spaces test user * adding saved objects all permission * fixing calendars * updating job 404 * updating job wildcard search * renaming services * fixing conflicts * fixing log tests * disabling apm test * skipping more apm tests * optimzing repair * fixing types * updating apm test archive to include ML saved objects * enabling disabled test * removing comment * adding space assigning endpoints * adding saved object default permissions * removing commented code * loading all jobs for all spaces for status check * adding spaces list endpoint * adding job spaces to management page * adding trained model fltering * fixing trained model id check and job wildcard check * fixing types * fixing bug when adding new job to calendar * changes based on review * updating schema * changes based on review * fixing types * rolling back http service injection * fixing http service injection * adding errrors to repair endpoint response * updating api doc * improving types * disabling id check on ad get endpoints * fixing tests * fixing group requests * adding comments * using filter in saved object search * fixing fake request issue * removing console log * making job saved object hidden * removing acccidentally included file * renaming saved object client * updating apidoc * unhiding ml saved objects * moving route guard * improving error when SOC is null * fixing types after merge with master * fixing tests Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>		2020-11-03 15:34:35 +00:00
..
.storybook	Storybook 6 and config changes (#75357 )	2020-09-29 19:34:05 -05:00
common	[Metrics UI] Add endpoint for Metrics API (#81693 )	2020-10-29 13:55:50 -07:00
docs	[Logs / Metrics] New Platform migration (full cutover) (#54583 )	2020-02-18 19:22:27 +00:00
public	Upgrade EUI to v30.1.1 (#81499 )	2020-10-30 16:18:27 -06:00
scripts	Storybook 6 and config changes (#75357 )	2020-09-29 19:34:05 -05:00
server	[ML] Adding space aware jobs (#77916 )	2020-11-03 15:34:35 +00:00
types	Update dependency @elastic/charts to v19.1.2 (#64759 )	2020-05-04 18:42:58 -05:00
kibana.json	Change plugin id for `triggers_actions_ui` to `triggersActionsUi` (#78555 )	2020-10-05 14:17:06 -07:00
README.md	[Logs / Metrics] New Platform migration (full cutover) (#54583 )	2020-02-18 19:22:27 +00:00

README.md

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 UI
- Feature: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
- Release note labels (see Kibana's contribution procedures)
  - release_note:enhancement if the PR contains a new feature or enhancement
  - release_note:fix if the PR contains an external-facing fix
  - release_note:breaking if the PR contains a breaking change
  - release_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 and review. 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. The yarn 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.