Sha256: 38759c215523a5a2a7f140dcd8765a8172bfdcb5dea010fd39212e32cf11bfe3
Contents?: true
Size: 1.57 KB
Versions: 8
Compression:
Stored size: 1.57 KB
Contents
[[debugging]] == Debugging the agent itself Hopefully the agent Just Works™, but depending on your situation the agent might need some tuning. First, to learn more about what's going on inside the agent, you can increase the amount of log messages it writes. To do this, set the log level with the option `log_level = 0` -- `0` being the level of most messages, `DEBUG`. In your `config/elastic_apm.yml`: [source,yaml] ---- log_level: <%= Logger::DEBUG %> ---- [float] [[debugging-log-messages]] === Log messages [float] [[debugging-errors-queue-full]] ==== `Queue is full (256 items), skipping…` The agent has an internal queue that holds events after they are done, and before they are safely serialized and sent to APM Server. To avoid using up all of your memory, this queue has a fixed size. Depending on your load and server setup, events may be added to the queue faster than they are consumed, hence the warning. Things to consider: - Is `server_url` misconfigured or APM Server down? If the agent fails to connect you will also see log messages containing `Connection error` or `Couldn't establish connection to APM Server`. - Experiencing high load? The agent can spawn multiple instances of its Workers that pick off the queue by changing the option `pool_size` (default is `1`). - If you have high load you may also consider setting `transaction_sample_rate` to something smaller than `1.0`. This determines whether to include _spans_ for every _transaction_. If you have enough traffic, skipping some (probably) identical spans won't have a noticeable effect on your data.
Version data entries
8 entries across 8 versions & 1 rubygems