* chore(NA): upgrade oss to lodash4 chore(NA): migrate cli, cli_plugin, cli_keystore, dev, test_utils and apm src script to lodash4 chore(NA): missing file for cli plugin chore(NA): add src core chore(NA): es archiver and fixtures chore(NA): try to fix functional test failure chore(NA): migrate src/legacy entirely to lodash4 except src/legacy/core_plugins chore(NA): move legacy core plugins to lodash4 chore(NA): upgrade optimize to lodash4 chore(NA): upgrade to lodash4 on advanced_settings, charts, console and dashboard chore(NA): migrate to lodash4 on dev_tools, discover, embeddable, es_ui)shared, expressions, home plugins chore(NA): upgrade data plugin to lodash4 chore(NA): upgrade usage_collection, ui_actions, tile_map, telemtry, share, saved_objects, saved_objects_management, region_map and navigation to lodash4 chore(NA): missing data upgrades to lodash4 Revert "chore(NA): upgrade usage_collection, ui_actions, tile_map, telemtry, share, saved_objects, saved_objects_management, region_map and navigation to lodash4" This reverts commit 137055c5fed2fc52bb26547e0bc1ad2e3d4fe309. Revert "Revert "chore(NA): upgrade usage_collection, ui_actions, tile_map, telemtry, share, saved_objects, saved_objects_management, region_map and navigation to lodash4"" This reverts commit f7e73688782998513d9fb6d7e8f0765e9beb28d1. Revert "chore(NA): missing data upgrades to lodash4" This reverts commit 92b85bf947a89bfc70cc4052738a6b2128ffb076. Revert "chore(NA): upgrade data plugin to lodash4" This reverts commit 88fdb075ee1e26c4ac979b6681d8a2b002df74c6. chore(NA): upgrade idx_pattern_mgt, input_control_vis, inspector, kbn_legacy, kbn_react, kbn_usage_collections, kbn_utils, management and maps_legacy to lodash4 chore(NA): map src plugin data to lodash3 chore(NA): missing lodash.clonedeep dep chore(NA): change packages kbn-config-schema deps chore(NA): update renovate config chore(NA): upgrade vis_type plugins to lodash4 chore(NA): move vis_type_vislib to lodash3 chore(NA): update visualizations and visualize to lodash4 chore(NA): remove lodash 3 types from src and move test to lodash4 chore(NA): move home, usage_collection and management to lodash 3 Revert "chore(NA): move home, usage_collection and management to lodash 3" This reverts commit f86e8585f02d21550746569af54215b076a79a3d. chore(NA): move kibana_legacy, saved_objects saved_objects_management into lodash3 chore(NA): update x-pack test to mock lodash4 Revert "chore(NA): move kibana_legacy, saved_objects saved_objects_management into lodash3" This reverts commit 2d10fe450533e1b36db21d99cfae3ce996a244e0. * chore(NA): move x-pack and packages to lodash 4 * chore(NA): remove mention to lodash from main package.json * chore(NA): remove helper alias for lodash4 and make it the default lodash * chore(NA): fix last failing types in the repo * chore(NA): fix public api * chore(NA): fix types for agg_row.tsx * chore(NA): fix increment of optimizer modules in the rollup plugin * chore(NA): migrate `src/core/public/http/fetch.ts` (#5) * omit undefined query props * just remove merge usage * fix types * chore(NA): fixes for feedback from apm team * chore(NA): recover old behaviour on apm LoadingIndeicatorContext.tsx * chore(NA): fixes for feedback from watson * Platform lodash4 tweaks (#6) * chore(NA): fix types and behaviour on src/core/server/elasticsearch/errors.ts * Canvas fixes for lodash upgrade * [APM] Adds unit test for APM service maps transform (#7) * Adds a snapshot unit test for getConnections and rearranges some code to make testing easier * reverts `ArrayList` back to `String[]` in the painless script within `fetch_service_paths_from_trace_ids.ts` * chore(NA): update yarn.lock * chore(NA): remove any and use a real type for alerts task runner Co-authored-by: Gidi Meir Morris <github@gidi.io> * chore(NA): used named import for triggers_actions_ui file * chore(NA): fix eslint * chore(NA): fix types * Delete most uptime lodash references. * Simplify. Clean up types. * [Uptime] Delete most uptime lodash references (#8) * Delete most uptime lodash references. * Simplify. Clean up types. * chore(NA): add eslint rule to avoid using lodash3 * chore(NA): apply changes on feedback from es-ui team * fix some types (#9) * Clean up some expressions types. * chore(NA): missing ts-expect-error statements * Upgrade lodash 4 vislib (#11) * replace lodash 3 with lodash 4 on vislib plugin * Further changes * further replacement of lodash3 to 4 * further work on upgrading to lodash 4 * final changes to update lodash * chore(NA): upgrade data plugin to lodash4 chore(NA): upgrade data plugin public to lodash4 chore(NA): fix typecheck task chore(NA): fix agg_config with hasIn chore(NA): assign to assignIn and has to hasIn chore(NA): upgrade data plugin server to lodash4 chore(NA): new signature for core api fix(NA): match behaviour between lodash3 and lodash4 for set in search_source * chore(NA): remove lodash3 completely from the repo * chore(NA): fix x-pack/test/api_integration/apis/metrics_ui/snapshot.ts missing content * chore(NA): fix lodash usage on apm * chore(NA): fix typecheck for maps * Patch lodash template (#12) * Applying changes from https://github.com/elastic/kibana/pull/64985 * Using isIterateeCall, because it seems less brittle * Also patching `lodash/template` and `lodash/fp/template` * Reorganizing some files... * Revising comment * Ends up `_` is a function also... I hate JavaScript Co-authored-by: Pierre Gayvallet <pierre.gayvallet@gmail.com> Co-authored-by: Josh Dover <me@joshdover.com> Co-authored-by: Clint Andrew Hall <clint.hall@elastic.co> Co-authored-by: Oliver Gupte <ogupte@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Gidi Meir Morris <github@gidi.io> Co-authored-by: Justin Kambic <justin.kambic@elastic.co> Co-authored-by: Stratoula Kalafateli <stratoula1@gmail.com> Co-authored-by: Luke Elmers <luke.elmers@elastic.co> Co-authored-by: Brandon Kobel <brandon.kobel@gmail.com> Co-authored-by: kobelb <brandon.kobel@elastic.co> |
||
---|---|---|
.. | ||
common | ||
docs | ||
public | ||
scripts | ||
server | ||
types | ||
kibana.json | ||
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 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.