You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Its default configuration is meant to be used by core {kib} developers
18
+
With an application as varied and complex as Kibana has become, it's not practical or scalable to craft all possible performance measurements by hand ahead of time. As such, we need to rely on tooling to help us catch things we may otherwise have missed.
19
+
20
+
For example, say you implement a brand new feature, plugin or service but don't quite know how it will impact Kibana's performance as a whole. APM allows us to not only spot that something is slow, but also hints at why it might be performing slowly. For example, if a function is slow on specific types of inputs, we can see where the time is spent by viewing the trace for that function call in the APM UI.
21
+
22
+
image::images/apm_example_trace.png[]
23
+
24
+
The net of metrics captured by APM are both a wide and deep because the entire application is instrumented at runtime and we simply take a sample of these metrics. This means that we don't have to know what we need to measure ahead of time, we'll instead just get (most) of the data we're likely going to need by default.
25
+
26
+
This type of data can help us identify unknown bottlenecks, spot when a performance regression may have been introduced, and inform how the performance of Kibana is changing between releases. Using APM allows us to be proactive in getting ahead of potential performance regressions before they are released.
27
+
28
+
The default APM configuration is meant to be used by core {kib} developers
19
29
only, but it can easily be re-configured to your needs. In its default
20
30
configuration it’s disabled and will, once enabled, send APM data to a
21
31
centrally managed {es} cluster accessible only to Elastic
@@ -27,11 +37,8 @@ APM config option. To activate the APM agent, use the
Once the agent is active, it will trace all incoming HTTP requests to
57
64
{kib}, monitor for errors, and collect process-level metrics. The
58
65
collected data will be sent to the APM Server and is viewable in the APM
59
-
UI in {kib}.
66
+
UI in {kib}.
67
+
68
+
[discrete]
69
+
=== Running Kibana with the APM Agent Locally
70
+
71
+
The easiest and recommended way of running Kibana with the APM agent locally is to use the solution provided by the https://github.com/elastic/apm-integration-testing[apm-integration-testing] repo. You’ll need https://www.docker.com/community-edition[Docker] and https://docs.docker.com/compose/install/[Docker Compose] to use the tool.
72
+
73
+
[discrete]
74
+
==== Quick start guide
75
+
76
+
. Clone the https://github.com/elastic/apm-integration-testing[elastic/apm-integration-testing] repo.
77
+
. Change into the apm-integration-testing repo:
78
+
+
79
+
[source,bash]
80
+
----
81
+
cd apm-integration-testing
82
+
----
83
+
84
+
. Run {es} and the APM servers without running Kibana:
85
+
+
86
+
[source,bash]
87
+
----
88
+
./scripts/compose.py start master --no-kibana
89
+
----
90
+
91
+
. Change into the {kib} repo:
92
+
+
93
+
[source,bash]
94
+
----
95
+
cd ../kibana
96
+
----
97
+
98
+
. Change the elasticsearch credentials in your `kibana.yml` configuration file to match those needed by elasticsearch and the APM server (see the apm-integration-testing repo's https://github.com/elastic/apm-integration-testing#logging-in[README] for users provided to test different scenarios).
99
+
. Make sure that the APM agent is active and points to the local APM server by adding the following configuration settings to to a config file under `config/apm.dev.js`:
0 commit comments