Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kibana Monitoring Pipeline Viewer UI not showing values #28153

Open
mfbloom opened this issue Jan 6, 2019 · 7 comments
Open

Kibana Monitoring Pipeline Viewer UI not showing values #28153

mfbloom opened this issue Jan 6, 2019 · 7 comments
Labels
bug Fixes for quality problems that affect the customer experience Feature:Logstash Pipelines Logstash Pipeline UI related Team:Monitoring Stack Monitoring team

Comments

@mfbloom
Copy link

mfbloom commented Jan 6, 2019

Kibana version:
docker.elastic.co/kibana/kibana:6.5.3

Elasticsearch version:
docker.elastic.co/elasticsearch/elasticsearch:6.5.3

Server OS version:
docker-engine 18.09.0

Browser version:
Chrome Version 71.0.3578.98 (Official Build) (64-bit)

Browser OS version:
Windows 10

Original install method (e.g. download page, yum, from source, etc.):
docker

Describe the bug:
There are no events/second metric values displaying in the logstash pipeline viewer UI for any elements. The same is true if you click an element, which opens the detail view; no data.

I don't believe it is a configuration error on my side because I can see on the overview screen events received and emitted data.

Screenshots (if relevant):
pipeline-viewer

output

emitted

Errors in browser console (if relevant):
none

Provide logs and/or server output (if relevant):
none that I could find

Any additional context:
Fantastic work on the UI!

@mfbloom
Copy link
Author

mfbloom commented Jan 6, 2019

The moment after I submitted this data started populating. It seems there is a considerable delay from the time all services are running and when this UI starts displaying data (>30 minutes).

@monfera monfera added triage_needed Team:Monitoring Stack Monitoring team labels Jan 8, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/stack-monitoring

@ycombinator ycombinator added the Feature:Logstash Pipelines Logstash Pipeline UI related label Jan 8, 2019
@ycombinator ycombinator added bug Fixes for quality problems that affect the customer experience and removed triage_needed labels Mar 11, 2019
@Eniqmatic
Copy link

+1 I have this issue, except my stats never show up. Version 6.6.1

ycombinator added a commit that referenced this issue Mar 21, 2019
_This PR targets a feature branch instead of `master`. Once this PR is merged, a follow up PR will be made to the feature branch to update tests. The idea here is to keep the size of each PR small. Finally, a PR will be created from the feature branch to `master`._

Resolves #27513.

## Before this PR
The Logstash Pipeline Viewer UI would make a single Kibana API call to fetch all the information necessary to render the Logstash pipeline. This included information necessary to render the detail drawer that opens up when a user clicks on an individual vertex in the pipeline.

Naturally, this single API call fetched _a lot_ of data, not just from the Kibana server but also, in turn, from Elasticsearch as well. The "pro" of this approach was that the user would see instantaneous results if they clicked on a vertex in a pipeline and opened the detail drawer for that vertex. The "cons" were the amount of computation Elasticsearch had to perform and the amount of data being transferred over the wire between Elasticsearch and the Kibana server as well as between the Kibana server and the browser.

## With this PR
This PR makes the Kibana API call to fetch data necessary for **initially** rendering the pipeline — that is, with the detail drawer closed — much lighter. When the user clicks on a vertex in a pipeline, a second API call is then made to fetch data necessary for the detail drawer.

Concretely, this PR makes the following changes:

* [x] For each metric of each vertex in the pipeline viewer, instead of returning a timeseries in the Kibana API response, we now only return the _latest_ data point. In other words, instead of returning `[ [t1, v1], [t2, v2], ... [tn, vn] ]` we now only return `vn`. This dramatically cuts down the number of aggregation buckets that Elasticsearch needs to generate.

* [x] For each vertex in the pipeline viewer, instead of returning up to 9 metrics in the Kibana API response we now only return 4. These are the 4 that are actually needed for the initial rendering of the pipeline (i.e. with the detail drawer closed). The 5 metrics that are no longer returned are `events_in`, `events_out`, `duration_in_millis`, `queue_push_duration_in_millis`, and `queue_push_duration_in_millis_per_event`.  

* [x] Since we no longer return `queue_push_duration_in_millis`, and `queue_push_duration_in_millis_per_event` from the Kibana API response, we also no longer compute the aggregations behind these metrics. Specifically, we no longer need the `queue_push_duration_in_millis_temp_by_ephemeral_id` and `queue_push_duration_in_millis_total` aggregations.

* [x] We no longer return the `pipeline.representation.plugins` array in the Kibana API response, since this array is not currently used in the Pipeline Viewer UI. We do this by excluding the `plugins` field from the Elasticsearch API response for the `logstash_state` document.

* [x] A new API to return timeseries metrics for a single vertex is created. This API is called whenever the detail drawer is open and showing a plugin vertex.

## Gains, by the numbers

Based on a simple, 1-input, 1-filter, and 1-output pipeline.

* Before this PR, the Elasticsearch `logstash_stats` API responses (multiple calls were made using the `composite` aggregation over the `date_histogram` aggregation) generated a total of 1228 aggregation buckets (before any `filter_path`s were applied but across all `composite` "pages"). With this PR, the single `logstash_stats` API response (note that this is just for the initial rendering of the pipeline, with the detail drawer closed) generated 12 buckets (also before any `filter_path`s were applied). That's a **99.02% reduction** in number of buckets.

* Before this PR, the Elasticsearch `logstash_stats` API responses added up to 70319 bytes. With this PR, the single `logstash_stats` API response for the same pipeline is 746 bytes. That's a **98.93% reduction** in size.

* Before this PR, the Elasticsearch `logstash_state` API response was 7718 bytes. With this PR, the API response for the same pipeline is 2328 bytes. That's a **69.83% reduction** in size.

* Before this PR the Kibana API response was 51777 bytes. With this PR, the API response for the same pipeline is 2567 bytes (again, note that this is just for the initial rendering of the pipeline, with the detail drawer closed). That's a **95.04% reduction** in size.

## Testing this PR

1. [Setup Logstash Monitoring](https://www.elastic.co/guide/en/logstash/current/configuring-logstash.html).
2. Start a Logstash pipeline, like so:

   ```
   ./bin/logstash -e 'input { generator {} } filter { drop {} } output { stdout { codec => dots } }'
   ```
3. Let the pipeline run for ~30 minutes (due to [this bug](#28153) 😞).

4. Open the Monitoring UI and visit the Logstash Pipeline Viewer for your pipeline.

5. Make sure the pipeline shows up. Check that the API response for the initial rendering of the pipeline doesn't contain any timeseries data. Then click on a vertex to open the Detail Drawer. Check that the details for that vertex show up, including sparklines rendered using timeseries data. Sample screenshots of what to expect:

   * Initial rendering

   <img width="1182" alt="Screen Shot 2019-03-18 at 11 02 45 AM" src="https://user-images.githubusercontent.com/51061/54552538-87caf980-496d-11e9-93ad-ede1eb6defa9.png">

   * With detail drawer open for `drop` filter plugin vertex

   <img width="1201" alt="Screen Shot 2019-03-18 at 11 02 57 AM" src="https://user-images.githubusercontent.com/51061/54552548-8dc0da80-496d-11e9-9e9e-8d130ed361ca.png">
@cachedout cachedout self-assigned this Apr 24, 2019
@dsvetlov
Copy link

dsvetlov commented Jul 5, 2019

I experiencing the same problem on 6.8.x

@cachedout cachedout removed their assignment Apr 21, 2020
@daleckystepan
Copy link

Same on 7.9.0

@chrisronline
Copy link
Contributor

Thanks for the bump @daleckystepan. We hope to look into this soon, but in the meantime, would you be able to share the last few .monitoring-logstash-* documents to help us debug this more?

@daleckystepan
Copy link

daleckystepan commented Sep 2, 2020

@chrisronline Here it is:

GET .monitoring-logstash-*/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      }
    }
  ]
}

https://gist.github.com/daleckystepan/bf062867820c4f32c4989af1d2b8183e

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Logstash Pipelines Logstash Pipeline UI related Team:Monitoring Stack Monitoring team
Projects
None yet
Development

No branches or pull requests