* creating overview page and menu * styling the home page * adjusting breadcrumb * renaming isnt working * renaming isnt working * renaming isnt working * fixing import * fixing scroll when resize window * fixing eslint errors * prepending links * adding target option * refactoring * adding dark mode support * fixing prettier format * fixing i18n * reverting some unnecessary changes * addressing PR comments * fixing functional tests * ordering observability menu * fixing tests * addressing PR comments * fixing scroll * addressing pr comments * addressing pr comments * creating overview page * mocking data * mocking data * refactoring * crearting apm chart * adding overview page * adding metric charts * adding charts * changing mock data location * adding mock registry * adding date picker * adding route validation * adding io-ts * adding io-ts * adding io-ts support * fixing imports and mock data * adding app folder * creating a section for each plugin * adding stats * adding domain min max * refactoring xcoordinaters * fixing route * adding bucket size * adding group property on logs * adding home page * dont break page if location state is undefined * each component fetches its own data * Refactoring * adding loading indicator to chart * fixing uptime chart * adding brush functionality to charts * fixing refresh button and auto refresh function * adding horizontal line to accordion section * adding emptySection to dashboard page * adding add data button * adding resources section * removing margins from horizontal rule * changing min interval to 60s * fixing empty section * removing unnecessary code * adding unit tests * fixing imports * adding initial story book for observability * removeing uptime mock data * fixing xDomain to show correct data on x-axis * fixing empty state alignment * adding story book and other improvements * adding news component * adding support to custom colors on EuiProgress and EuiStats * removing infra mock data * adding error message when api throwns an error * adding alert section * Adding alerts * adding alert api call * addressing PR comments * adding storybook * adding feedback button * addressing PR comments * chamging plugins return data * fixing kibana app navigation * fixing unit test * fixing ts issues * addressing PR comments * using lodash truncate * adding comment * updating public documentation * fixing alerts request * fixing unit test * fixing unit test * aligin beta badge to the center * adding moment duration to get the units as seconds * addressing PR comments * addressing PR comments |
||
---|---|---|
.. | ||
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.