You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@flagon.apache.org by po...@apache.org on 2019/07/09 04:28:17 UTC
[incubator-flagon] branch master updated: [FLAGON-415] a few more
formating updates to scaling page
This is an automated email from the ASF dual-hosted git repository.
poorejc pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-flagon.git
The following commit(s) were added to refs/heads/master by this push:
new e01af7c [FLAGON-415] a few more formating updates to scaling page
e01af7c is described below
commit e01af7c84356f30c2b39d580aa39b7d94798f135
Author: poorejc <po...@apache.org>
AuthorDate: Tue Jul 9 00:27:58 2019 -0400
[FLAGON-415] a few more formating updates to scaling page
---
LICENSE | 20 ++++++-------
NOTICE | 6 ++++
content/docs/stack/scaling/index.html | 49 +++++++++++++++++++-------------
content/feed.xml | 2 +-
site/_docs/stack/scaling.md | 45 ++++++++++++++++-------------
site/_site/docs/stack/scaling/index.html | 49 +++++++++++++++++++-------------
site/_site/feed.xml | 2 +-
7 files changed, 102 insertions(+), 71 deletions(-)
diff --git a/LICENSE b/LICENSE
index 18f2950..b38f054 100644
--- a/LICENSE
+++ b/LICENSE
@@ -186,16 +186,16 @@
same "printed page" as the copyright notice for easier
identification within third-party archives.
- © Copyright [yyyy] [name of copyright owner]
+ Copyright [yyyy] [name of copyright owner]
- Licensed under the Apache License, Version 2.0 (the "License");
- you may not use this file except in compliance with the License.
- You may obtain a copy of the License at
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
- http://www.apache.org/licenses/LICENSE-2.0
+ http://www.apache.org/licenses/LICENSE-2.0
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
\ No newline at end of file
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
diff --git a/NOTICE b/NOTICE
new file mode 100755
index 0000000..6e3f04f
--- /dev/null
+++ b/NOTICE
@@ -0,0 +1,6 @@
+Apache Flagon UserALE.js
+Copyright 2019 The Apache Software Foundation
+
+This product includes software developed at The Apache Software Foundation (http://www.apache.org/),
+based on source code originally developed and generously granted to The Apache Software Foundation
+by The Charles Stark Draper Laboratory, Inc (http://www.draper.com/).
diff --git a/content/docs/stack/scaling/index.html b/content/docs/stack/scaling/index.html
index da8e903..5b9f576 100644
--- a/content/docs/stack/scaling/index.html
+++ b/content/docs/stack/scaling/index.html
@@ -266,11 +266,11 @@
<p><strong>The Apache Flagon Single-Node Elastic Container is an Ingredient, Not a Whole Solution</strong></p>
-<p>The single-node Elastic (ELK) distributed by <a href="/docs/stack">Apache Flagon</a> is not alone suitable for most production-level use-cases.</p>
+<p>The single-node Elastic (ELK) build distributed by <a href="/docs/stack">Apache Flagon</a> is not alone suitable for most production-level use-cases.</p>
-<p>It may be suitable on its own for “grab-and-go” user-testing use cases; just a few days of data collection from a specific application, from just a few users.</p>
+<p>This build may be suitable for limited user-testing; just a few days of data collection from a specific application, from just a few users.</p>
-<p>Alone it will fail quickly for any enterprise-scale use-cases.</p>
+<p>However, a single-node Elastic build will fail quickly for any enterprise-scale use-cases.</p>
<p>Instead, this container is meant to be a building block for larger solutions:</p>
@@ -293,16 +293,25 @@
<p>Default <a href="/docs/useralejs">Apache UserALE.js parameters</a> produce loads of <a href="/docs/useralejs/dataschema">data</a>, even from a single users.</p>
-<p>We strongly suggest that you think about your needs and consider whether you need data from all our event-handlers. If you don’t need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you’ll need.</p>
+<p>We strongly suggest that you consider whether you need data from all our event-handlers.</p>
-<p>You can <a href="/docs/useralejs/modifying">modify source</a> or use the <a href="/docs/useralejs/API">UserALE.js API</a>, and/or use <a href="/docs/useralejs">configurable HTLM5 parameters in our script tag</a> to manage data generation rate.</p>
+<p>If you don’t need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you’ll need.</p>
-<p>####Resource needs will also grow with <em>document length</em>
-<a href="https://blog.appdynamics.com/product/estimating-costs-of-storing-documents-in-elasticsearch/">Strings</a> within UserALE.js logs (see also <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/tune-for-disk-usage.html#_use_literal_best_compression_literal">Elastic’s tips on indexing strings</a>) can add to scaling needs.</p>
+<p>Instead, you can <a href="/docs/useralejs/modifying">modify source</a> or use the <a href="/docs/useralejs/API">UserALE.js API</a>, and/or use <a href="/docs/useralejs">configurable HTLM5 parameters in our script tag</a> to manage data generation rate.</p>
-<p>One of the discriminating features of Apache UserALE.js is its precision–it captures target DOM elements, the DOM path elements are nested in, and loads of metadata.</p>
+<p>####Resource needs will also grow with document length</p>
-<p>UserALE.js fields like <code class="highlighter-rouge">path</code> and <code class="highlighter-rouge">pageUrl</code> can grow for certain pages. Its worth considering if you need this level of precision.</p>
+<p><a href="https://blog.appdynamics.com/product/estimating-costs-of-storing-documents-in-elasticsearch/">Strings</a> within UserALE.js logs (see also <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/tune-for-disk-usage.html#_use_literal_best_compression_literal">Elastic’s tips on indexing strings</a>) can add to scaling needs.</p>
+
+<p>One of the discriminating features of Apache UserALE.js is its precision:</p>
+
+<ul>
+ <li>it captures target DOM elements;</li>
+ <li>it captures the DOM path that elements are nested in;</li>
+ <li>it captures loads of metadata (URI, page title, page url, referrer, etc.).</li>
+</ul>
+
+<p>UserALE.js fields like <code class="highlighter-rouge">path</code> and <code class="highlighter-rouge">pageUrl</code> can be lengthy for certain pages, increasing string length per document.</p>
<p>Instead, you might consider relying on <code class="highlighter-rouge">pageTitle</code> rather than <code class="highlighter-rouge">pageUrl</code>, or just <code class="highlighter-rouge">target</code> instead of <code class="highlighter-rouge">path</code></p>
@@ -345,7 +354,7 @@
</code></pre>
</div>
-<p>Through simple <a href="/docs/useralejs/modifying">modifications to UserALE.js source</a> or by using the UserALE.js <a href="/docs/useralejs/API">API</a> you can alias verbose fields in your logs to reduce resource consumption.</p>
+<p>Through simple <a href="/docs/useralejs/modifying">modifications to UserALE.js source</a> or with the UserALE.js <a href="/docs/useralejs/API">API</a> you can alias verbose fields in your logs to reduce resource consumption.</p>
<p>####Additional services attached to your stack can increase resource consumption</p>
@@ -359,7 +368,7 @@
<p>Analytical services connected to the stack can consume significant resources and increase indexing and search time.</p>
-<p>This can be problematic for real-time analytical and monitoring applications (including Kibana), and result in data loss if logs flush prior to being indexed.</p>
+<p>This can be problematic for real-time analytical and monitoring applications (including Kibana).</p>
<p>For hefty analytical services, it may be worth dedicating specific nodes in your cluster to service them.</p>
@@ -381,7 +390,7 @@
<p>Important: as noted in the instructions, you’ll need to have collected some log data to establish the index.</p>
</li>
- <li><strong>Once you’ve started up Elasticsearch, Logstash, Kibana, and metricbead, and confirm that you can see logs in Kibana, take a look at the <code class="highlighter-rouge">userale</code> index stats.</strong>
+ <li><strong>Once Elasticsearch, Logstash, Kibana, and metricbeat are up, look at the <code class="highlighter-rouge">userale</code> index stats.</strong>
<div class="language-shell highlighter-rouge"><pre class="highlight"><code> <span class="c">#Index Stats using Elastic's _stats API</span>
<span class="nv">$ </span>curl localhost:9200/index_name/_stats?pretty<span class="o">=</span><span class="nb">true</span>
@@ -467,7 +476,7 @@
data-url="http://localhost:8100/"
data-user="example-user"
data-version="1.1.1"
- data-resolution=1000 #increased the delay between collection of "high-resolution" events (e.g., mouseovers).
+ data-resolution=1000 #increased the delay between collection of frequent events (e.g., mouseovers).
data-tool="Apache UserALE.js Example"
></script>
</code></pre>
@@ -593,24 +602,24 @@ Output is very simple and index sizes stack on top of one another
<p>What happened is a thing called <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/merge-process.html">merging</a>.</p>
-<p>As data is collected it’s gathered into segments within an index.</p>
-
-<p>Each segment is an element of your index and takes up storage, so as your collect data the number of segments grows quickly consuming a lot of storage.</p>
+<p>As data is collected it’s gathered into segments within an index. Each segment is an element of your index and takes up storage.</p>
-<p>As Elastic (Lucene) indexes, it merges these segments into larger and larger segments, thus reducing the overall number of segments to reduce storage and resource needs.</p>
+<p>As Elastic (Lucene) indexes, it merges these segments into larger segments to reduce the overall number of segments to minimize storage.</p>
-<p>This means that depending on when you make a call to Elastic’s <code class="highlighter-rouge">STATS</code> API, you might be looking at the store size at different stages in the merging process.</p>
+<p>This means that a call to Elastic’s <code class="highlighter-rouge">STATS</code> API can result in a view into the store size at different stages in the merging process.</p>
<p>If your store size looks smaller than your last benchmark. You should re-run it then wait.</p>
-<p>If your store size looks way to big, then just wait. After a minute or two, call the <code class="highlighter-rouge">STATS</code> API again, and you’ll probably see a store size that makes much more sense.</p>
+<p>If your store size looks way to big, then wait. After a minute, call the <code class="highlighter-rouge">STATS</code> API again, and you’ll likely see a more sensible store size.</p>
<h3 id="summary">Summary</h3>
<p>Benchmarking and adjusting your data-rate so that you can scale how you want to is made very easy in Apache Flagon.</p>
<p>We combine easily deployed and modified capabilities with the power of Elastic’s APIs and visualization capabilities.</p>
-<p>Again, our single-node container is not a scaling solution. It’s a building block benchmarking tool to help you build and manage scale and cost.</p>
+<p>Again, Flagon’s single-node container is not a scaling solution.</p>
+
+<p>It’s a building block benchmarking tool to help you build and manage scale and cost.</p>
<p>Subscribe to our <a href="dev-subscribe@flagon.incubator.apache.org">dev list</a> and join the conversation!</p>
diff --git a/content/feed.xml b/content/feed.xml
index a69525a..e137ec0 100644
--- a/content/feed.xml
+++ b/content/feed.xml
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xml" href="http://flagon.incubator.apache.org/feed.xslt.xml"?><feed xmlns="http://www.w3.org/2005/Atom"><generator uri="http://jekyllrb.com" version="3.3.1">Jekyll</generator><link href="http://flagon.incubator.apache.org/feed.xml" rel="self" type="application/atom+xml" /><link href="http://flagon.incubator.apache.org/" rel="alternate" type="text/html" /><updated>2019-07-09T03:56:30+00:00</updated><id>http://flagon.incubat [...]
+<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xml" href="http://flagon.incubator.apache.org/feed.xslt.xml"?><feed xmlns="http://www.w3.org/2005/Atom"><generator uri="http://jekyllrb.com" version="3.3.1">Jekyll</generator><link href="http://flagon.incubator.apache.org/feed.xml" rel="self" type="application/atom+xml" /><link href="http://flagon.incubator.apache.org/" rel="alternate" type="text/html" /><updated>2019-07-09T04:25:05+00:00</updated><id>http://flagon.incubat [...]
diff --git a/site/_docs/stack/scaling.md b/site/_docs/stack/scaling.md
index 0cece36..bd7fff6 100644
--- a/site/_docs/stack/scaling.md
+++ b/site/_docs/stack/scaling.md
@@ -23,11 +23,11 @@ The best way to scale Apache Flagon depends entirely on your use-case:
**The Apache Flagon Single-Node Elastic Container is an Ingredient, Not a Whole Solution**
-The single-node Elastic (ELK) distributed by [Apache Flagon]({{ '/docs/stack' | prepend: site.baseurl }}) is not alone suitable for most production-level use-cases.
+The single-node Elastic (ELK) build distributed by [Apache Flagon]({{ '/docs/stack' | prepend: site.baseurl }}) is not alone suitable for most production-level use-cases.
-It may be suitable on its own for "grab-and-go" user-testing use cases; just a few days of data collection from a specific application, from just a few users.
+This build may be suitable for limited user-testing; just a few days of data collection from a specific application, from just a few users.
-Alone it will fail quickly for any enterprise-scale use-cases.
+However, a single-node Elastic build will fail quickly for any enterprise-scale use-cases.
Instead, this container is meant to be a building block for larger solutions:
@@ -48,16 +48,23 @@ Elastic has many useful [guides]((https://www.elastic.co/blog/found-sizing-elast
Default [Apache UserALE.js parameters]({{ '/docs/useralejs' | prepend: site.baseurl }}) produce loads of [data]({{ '/docs/useralejs/dataschema' | prepend: site.baseurl }}), even from a single users.
-We strongly suggest that you think about your needs and consider whether you need data from all our event-handlers. If you don't need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you'll need.
+We strongly suggest that you consider whether you need data from all our event-handlers.
-You can [modify source]({{ '/docs/useralejs/modifying' | prepend: site.baseurl }}) or use the [UserALE.js API]({{ '/docs/useralejs/API' | prepend: site.baseurl }}), and/or use [configurable HTLM5 parameters in our script tag]({{ '/docs/useralejs' | prepend: site.baseurl }}) to manage data generation rate.
+If you don't need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you'll need.
+
+Instead, you can [modify source]({{ '/docs/useralejs/modifying' | prepend: site.baseurl }}) or use the [UserALE.js API]({{ '/docs/useralejs/API' | prepend: site.baseurl }}), and/or use [configurable HTLM5 parameters in our script tag]({{ '/docs/useralejs' | prepend: site.baseurl }}) to manage data generation rate.
+
+####Resource needs will also grow with document length
-####Resource needs will also grow with *document length*
[Strings](https://blog.appdynamics.com/product/estimating-costs-of-storing-documents-in-elasticsearch/) within UserALE.js logs (see also [Elastic's tips on indexing strings](https://www.elastic.co/guide/en/elasticsearch/reference/5.5/tune-for-disk-usage.html#_use_literal_best_compression_literal)) can add to scaling needs.
-One of the discriminating features of Apache UserALE.js is its precision--it captures target DOM elements, the DOM path elements are nested in, and loads of metadata.
+One of the discriminating features of Apache UserALE.js is its precision:
+
+* it captures target DOM elements;
+* it captures the DOM path that elements are nested in;
+* it captures loads of metadata (URI, page title, page url, referrer, etc.).
-UserALE.js fields like `path` and `pageUrl` can grow for certain pages. Its worth considering if you need this level of precision.
+UserALE.js fields like `path` and `pageUrl` can be lengthy for certain pages, increasing string length per document.
Instead, you might consider relying on `pageTitle` rather than `pageUrl`, or just `target` instead of `path`
@@ -98,7 +105,7 @@ Below is a sample `path` for a Kibana element:
...
```
-Through simple [modifications to UserALE.js source]({{ '/docs/useralejs/modifying' | prepend: site.baseurl }}) or by using the UserALE.js [API]({{ '/docs/useralejs/API' | prepend: site.baseurl }}) you can alias verbose fields in your logs to reduce resource consumption.
+Through simple [modifications to UserALE.js source]({{ '/docs/useralejs/modifying' | prepend: site.baseurl }}) or with the UserALE.js [API]({{ '/docs/useralejs/API' | prepend: site.baseurl }}) you can alias verbose fields in your logs to reduce resource consumption.
####Additional services attached to your stack can increase resource consumption
@@ -112,7 +119,7 @@ As you configure that cluster, be mindful that Elasticsearch is indexing and ser
Analytical services connected to the stack can consume significant resources and increase indexing and search time.
-This can be problematic for real-time analytical and monitoring applications (including Kibana), and result in data loss if logs flush prior to being indexed.
+This can be problematic for real-time analytical and monitoring applications (including Kibana).
For hefty analytical services, it may be worth dedicating specific nodes in your cluster to service them.
@@ -133,7 +140,7 @@ However, you'll want to experiment with your own page/application for more accur
Important: as noted in the instructions, you'll need to have collected some log data to establish the index.
-1. **Once you've started up Elasticsearch, Logstash, Kibana, and metricbead, and confirm that you can see logs in Kibana, take a look at the `userale` index stats.**
+1. **Once Elasticsearch, Logstash, Kibana, and metricbeat are up, look at the `userale` index stats.**
```shell
#Index Stats using Elastic's _stats API
$ curl localhost:9200/index_name/_stats?pretty=true
@@ -219,7 +226,7 @@ However, you'll want to experiment with your own page/application for more accur
data-url="http://localhost:8100/"
data-user="example-user"
data-version="1.1.1"
- data-resolution=1000 #increased the delay between collection of "high-resolution" events (e.g., mouseovers).
+ data-resolution=1000 #increased the delay between collection of frequent events (e.g., mouseovers).
data-tool="Apache UserALE.js Example"
></script>
```
@@ -337,24 +344,24 @@ What you find is that your new store size is either dramatically bigger than you
What happened is a thing called [merging](https://www.elastic.co/guide/en/elasticsearch/guide/current/merge-process.html).
-As data is collected it's gathered into segments within an index.
+As data is collected it's gathered into segments within an index. Each segment is an element of your index and takes up storage.
-Each segment is an element of your index and takes up storage, so as your collect data the number of segments grows quickly consuming a lot of storage.
+As Elastic (Lucene) indexes, it merges these segments into larger segments to reduce the overall number of segments to minimize storage.
-As Elastic (Lucene) indexes, it merges these segments into larger and larger segments, thus reducing the overall number of segments to reduce storage and resource needs.
-
-This means that depending on when you make a call to Elastic's `STATS` API, you might be looking at the store size at different stages in the merging process.
+This means that a call to Elastic's `STATS` API can result in a view into the store size at different stages in the merging process.
If your store size looks smaller than your last benchmark. You should re-run it then wait.
-If your store size looks way to big, then just wait. After a minute or two, call the `STATS` API again, and you'll probably see a store size that makes much more sense.
+If your store size looks way to big, then wait. After a minute, call the `STATS` API again, and you'll likely see a more sensible store size.
### Summary
Benchmarking and adjusting your data-rate so that you can scale how you want to is made very easy in Apache Flagon.
We combine easily deployed and modified capabilities with the power of Elastic's APIs and visualization capabilities.
-Again, our single-node container is not a scaling solution. It's a building block benchmarking tool to help you build and manage scale and cost.
+Again, Flagon's single-node container is not a scaling solution.
+
+It's a building block benchmarking tool to help you build and manage scale and cost.
Subscribe to our [dev list](dev-subscribe@flagon.incubator.apache.org) and join the conversation!
diff --git a/site/_site/docs/stack/scaling/index.html b/site/_site/docs/stack/scaling/index.html
index da8e903..5b9f576 100644
--- a/site/_site/docs/stack/scaling/index.html
+++ b/site/_site/docs/stack/scaling/index.html
@@ -266,11 +266,11 @@
<p><strong>The Apache Flagon Single-Node Elastic Container is an Ingredient, Not a Whole Solution</strong></p>
-<p>The single-node Elastic (ELK) distributed by <a href="/docs/stack">Apache Flagon</a> is not alone suitable for most production-level use-cases.</p>
+<p>The single-node Elastic (ELK) build distributed by <a href="/docs/stack">Apache Flagon</a> is not alone suitable for most production-level use-cases.</p>
-<p>It may be suitable on its own for “grab-and-go” user-testing use cases; just a few days of data collection from a specific application, from just a few users.</p>
+<p>This build may be suitable for limited user-testing; just a few days of data collection from a specific application, from just a few users.</p>
-<p>Alone it will fail quickly for any enterprise-scale use-cases.</p>
+<p>However, a single-node Elastic build will fail quickly for any enterprise-scale use-cases.</p>
<p>Instead, this container is meant to be a building block for larger solutions:</p>
@@ -293,16 +293,25 @@
<p>Default <a href="/docs/useralejs">Apache UserALE.js parameters</a> produce loads of <a href="/docs/useralejs/dataschema">data</a>, even from a single users.</p>
-<p>We strongly suggest that you think about your needs and consider whether you need data from all our event-handlers. If you don’t need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you’ll need.</p>
+<p>We strongly suggest that you consider whether you need data from all our event-handlers.</p>
-<p>You can <a href="/docs/useralejs/modifying">modify source</a> or use the <a href="/docs/useralejs/API">UserALE.js API</a>, and/or use <a href="/docs/useralejs">configurable HTLM5 parameters in our script tag</a> to manage data generation rate.</p>
+<p>If you don’t need mouseover events, for example, you can dramatically reduce the rate at which you generate data and the resources you’ll need.</p>
-<p>####Resource needs will also grow with <em>document length</em>
-<a href="https://blog.appdynamics.com/product/estimating-costs-of-storing-documents-in-elasticsearch/">Strings</a> within UserALE.js logs (see also <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/tune-for-disk-usage.html#_use_literal_best_compression_literal">Elastic’s tips on indexing strings</a>) can add to scaling needs.</p>
+<p>Instead, you can <a href="/docs/useralejs/modifying">modify source</a> or use the <a href="/docs/useralejs/API">UserALE.js API</a>, and/or use <a href="/docs/useralejs">configurable HTLM5 parameters in our script tag</a> to manage data generation rate.</p>
-<p>One of the discriminating features of Apache UserALE.js is its precision–it captures target DOM elements, the DOM path elements are nested in, and loads of metadata.</p>
+<p>####Resource needs will also grow with document length</p>
-<p>UserALE.js fields like <code class="highlighter-rouge">path</code> and <code class="highlighter-rouge">pageUrl</code> can grow for certain pages. Its worth considering if you need this level of precision.</p>
+<p><a href="https://blog.appdynamics.com/product/estimating-costs-of-storing-documents-in-elasticsearch/">Strings</a> within UserALE.js logs (see also <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/tune-for-disk-usage.html#_use_literal_best_compression_literal">Elastic’s tips on indexing strings</a>) can add to scaling needs.</p>
+
+<p>One of the discriminating features of Apache UserALE.js is its precision:</p>
+
+<ul>
+ <li>it captures target DOM elements;</li>
+ <li>it captures the DOM path that elements are nested in;</li>
+ <li>it captures loads of metadata (URI, page title, page url, referrer, etc.).</li>
+</ul>
+
+<p>UserALE.js fields like <code class="highlighter-rouge">path</code> and <code class="highlighter-rouge">pageUrl</code> can be lengthy for certain pages, increasing string length per document.</p>
<p>Instead, you might consider relying on <code class="highlighter-rouge">pageTitle</code> rather than <code class="highlighter-rouge">pageUrl</code>, or just <code class="highlighter-rouge">target</code> instead of <code class="highlighter-rouge">path</code></p>
@@ -345,7 +354,7 @@
</code></pre>
</div>
-<p>Through simple <a href="/docs/useralejs/modifying">modifications to UserALE.js source</a> or by using the UserALE.js <a href="/docs/useralejs/API">API</a> you can alias verbose fields in your logs to reduce resource consumption.</p>
+<p>Through simple <a href="/docs/useralejs/modifying">modifications to UserALE.js source</a> or with the UserALE.js <a href="/docs/useralejs/API">API</a> you can alias verbose fields in your logs to reduce resource consumption.</p>
<p>####Additional services attached to your stack can increase resource consumption</p>
@@ -359,7 +368,7 @@
<p>Analytical services connected to the stack can consume significant resources and increase indexing and search time.</p>
-<p>This can be problematic for real-time analytical and monitoring applications (including Kibana), and result in data loss if logs flush prior to being indexed.</p>
+<p>This can be problematic for real-time analytical and monitoring applications (including Kibana).</p>
<p>For hefty analytical services, it may be worth dedicating specific nodes in your cluster to service them.</p>
@@ -381,7 +390,7 @@
<p>Important: as noted in the instructions, you’ll need to have collected some log data to establish the index.</p>
</li>
- <li><strong>Once you’ve started up Elasticsearch, Logstash, Kibana, and metricbead, and confirm that you can see logs in Kibana, take a look at the <code class="highlighter-rouge">userale</code> index stats.</strong>
+ <li><strong>Once Elasticsearch, Logstash, Kibana, and metricbeat are up, look at the <code class="highlighter-rouge">userale</code> index stats.</strong>
<div class="language-shell highlighter-rouge"><pre class="highlight"><code> <span class="c">#Index Stats using Elastic's _stats API</span>
<span class="nv">$ </span>curl localhost:9200/index_name/_stats?pretty<span class="o">=</span><span class="nb">true</span>
@@ -467,7 +476,7 @@
data-url="http://localhost:8100/"
data-user="example-user"
data-version="1.1.1"
- data-resolution=1000 #increased the delay between collection of "high-resolution" events (e.g., mouseovers).
+ data-resolution=1000 #increased the delay between collection of frequent events (e.g., mouseovers).
data-tool="Apache UserALE.js Example"
></script>
</code></pre>
@@ -593,24 +602,24 @@ Output is very simple and index sizes stack on top of one another
<p>What happened is a thing called <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/merge-process.html">merging</a>.</p>
-<p>As data is collected it’s gathered into segments within an index.</p>
-
-<p>Each segment is an element of your index and takes up storage, so as your collect data the number of segments grows quickly consuming a lot of storage.</p>
+<p>As data is collected it’s gathered into segments within an index. Each segment is an element of your index and takes up storage.</p>
-<p>As Elastic (Lucene) indexes, it merges these segments into larger and larger segments, thus reducing the overall number of segments to reduce storage and resource needs.</p>
+<p>As Elastic (Lucene) indexes, it merges these segments into larger segments to reduce the overall number of segments to minimize storage.</p>
-<p>This means that depending on when you make a call to Elastic’s <code class="highlighter-rouge">STATS</code> API, you might be looking at the store size at different stages in the merging process.</p>
+<p>This means that a call to Elastic’s <code class="highlighter-rouge">STATS</code> API can result in a view into the store size at different stages in the merging process.</p>
<p>If your store size looks smaller than your last benchmark. You should re-run it then wait.</p>
-<p>If your store size looks way to big, then just wait. After a minute or two, call the <code class="highlighter-rouge">STATS</code> API again, and you’ll probably see a store size that makes much more sense.</p>
+<p>If your store size looks way to big, then wait. After a minute, call the <code class="highlighter-rouge">STATS</code> API again, and you’ll likely see a more sensible store size.</p>
<h3 id="summary">Summary</h3>
<p>Benchmarking and adjusting your data-rate so that you can scale how you want to is made very easy in Apache Flagon.</p>
<p>We combine easily deployed and modified capabilities with the power of Elastic’s APIs and visualization capabilities.</p>
-<p>Again, our single-node container is not a scaling solution. It’s a building block benchmarking tool to help you build and manage scale and cost.</p>
+<p>Again, Flagon’s single-node container is not a scaling solution.</p>
+
+<p>It’s a building block benchmarking tool to help you build and manage scale and cost.</p>
<p>Subscribe to our <a href="dev-subscribe@flagon.incubator.apache.org">dev list</a> and join the conversation!</p>
diff --git a/site/_site/feed.xml b/site/_site/feed.xml
index a69525a..e137ec0 100644
--- a/site/_site/feed.xml
+++ b/site/_site/feed.xml
@@ -1 +1 @@
-<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xml" href="http://flagon.incubator.apache.org/feed.xslt.xml"?><feed xmlns="http://www.w3.org/2005/Atom"><generator uri="http://jekyllrb.com" version="3.3.1">Jekyll</generator><link href="http://flagon.incubator.apache.org/feed.xml" rel="self" type="application/atom+xml" /><link href="http://flagon.incubator.apache.org/" rel="alternate" type="text/html" /><updated>2019-07-09T03:56:30+00:00</updated><id>http://flagon.incubat [...]
+<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/xml" href="http://flagon.incubator.apache.org/feed.xslt.xml"?><feed xmlns="http://www.w3.org/2005/Atom"><generator uri="http://jekyllrb.com" version="3.3.1">Jekyll</generator><link href="http://flagon.incubator.apache.org/feed.xml" rel="self" type="application/atom+xml" /><link href="http://flagon.incubator.apache.org/" rel="alternate" type="text/html" /><updated>2019-07-09T04:25:05+00:00</updated><id>http://flagon.incubat [...]