Admin: Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "

2026-01-17T07:06:02Z

Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "

← Older revision		Revision as of 07:06, 17 January 2026
Line 1:		Line 1:
	[[Category:Wiki]]		[[Category:Wiki]]

			'''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]'''''


	== Log Files and System Monitoring ==		== Log Files and System Monitoring ==

Admin: Created page with "Category:Wiki == Log Files and System Monitoring == Before diving into the specifics of Elasticsearch problems, it's important to review log files and system health metrics. * Elasticsearch logs are typically located in the `/var/log/elasticsearch/` directory (depending on the installation and configuration). * The Elasticsearch logs can also be accessed via the `GET /_cat/indices?v` API to view the status of indices. * Monitoring tools like Kibana can provide ins..."

2025-12-14T08:47:15Z

Created page with "Category:Wiki == Log Files and System Monitoring == Before diving into the specifics of Elasticsearch problems, it's important to review log files and system health metrics. * Elasticsearch logs are typically located in the `/var/log/elasticsearch/` directory (depending on the installation and configuration). * The Elasticsearch logs can also be accessed via the `GET /_cat/indices?v` API to view the status of indices. * Monitoring tools like Kibana can provide ins..."

New page

[[Category:Wiki]]

== Log Files and System Monitoring ==

Before diving into the specifics of Elasticsearch problems, it's important to review log files and system health metrics.

* Elasticsearch logs are typically located in the `/var/log/elasticsearch/` directory (depending on the installation and configuration).
* The Elasticsearch logs can also be accessed via the `GET /_cat/indices?v` API to view the status of indices.
* Monitoring tools like Kibana can provide insight into cluster health.

Example of checking logs using the command line:
<nowiki>
tail -f /var/log/elasticsearch/elasticsearch.log</nowiki>

For Elasticsearch health, you can use the following API:

<nowiki>
curl -X GET "localhost:9200/_cat/health?v=true&pretty"</nowiki>

This will display the cluster health with key metrics such as `status`, `node count`, and `shards`.

== Cluster Health Issues ==

When the cluster health is "red" or "yellow," it often means that there are issues with the cluster that need to be addressed.

* **Red Status**: Critical, some or all primary shards are unassigned.
* **Yellow Status**: Warnings, replicas are unassigned.

Common causes:
1. **Shards Not Allocated**:
- This can happen if there are not enough resources to allocate the shards (e.g., disk space or memory).

Check the allocation status using:
<nowiki>
curl -X GET "localhost:9200/_cat/shards?v=true&pretty"</nowiki>

If a shard is unassigned, you may need to adjust settings for shard allocation, like this:

<nowiki>
PUT /_cluster/settings
{
"persistent": {
"cluster.routing.allocation.disk.watermark.low": "70%",
"cluster.routing.allocation.disk.watermark.high": "85%"
}
}</nowiki>

2. **Node Failures**:
- Elasticsearch nodes may fail to communicate, causing the cluster to lose quorum or shards to become unassigned. Ensure network connectivity between nodes is functional.

To check node status:

<nowiki>
curl -X GET "localhost:9200/_cat/nodes?v=true&pretty"</nowiki>

If you notice nodes are not visible or unreachable, investigate the networking issues between nodes.

== Query Performance Issues ==

Slow query performance is a common issue that can arise from several sources, including inefficient queries, inadequate hardware, or improperly configured settings.

* **Inefficient Queries**: Complex queries, missing filters, and unoptimized indices can lead to slow performance.

Example of a slow query:
<nowiki>
GET /index_name/_search
{
"query": {
"match_all": {}
}
}</nowiki>

You can use the profile API to analyze and optimize queries:

<nowiki>
GET /index_name/_search?profile=true</nowiki>

The response will show detailed execution times for each phase of the query.

* **Shard Size and Distribution**: Elasticsearch performance degrades if you have too many or too few shards. Typically, a shard should not exceed 50GB in size.

Check the shard distribution with:
<nowiki>
curl -X GET "localhost:9200/_cat/shards?v=true&pretty"
</nowiki>

If necessary, consider reindexing to rebalance or split large shards:

<nowiki>
POST /_shrink/index_name
{
"settings": {
"index.number_of_shards": 1
}
}</nowiki>

== Out Of Memory (OOM) Issues ==

Elasticsearch can consume a large amount of memory, and OOM errors can cause crashes or poor performance.

1. **JVM Heap Settings**: Ensure the heap size is properly set. It's typically recommended to set the heap size to 50% of your available system memory (up to a maximum of 32GB).

You can configure the heap size by setting the `-Xms` and `-Xmx` options in `jvm.options`:

<nowiki>
-Xms16g
-Xmx16g</nowiki>

2. **Garbage Collection (GC) Issues**: Excessive garbage collection pauses can lead to performance degradation.

To diagnose GC issues, enable the GC logging in the `jvm.options` file:

<nowiki>
-Xlog:gc*:file=/var/log/elasticsearch/gc.log</nowiki>

Analyze the logs for frequent GC pauses.

== Disk Space Issues ==

Disk space is a critical resource for Elasticsearch, and running out of disk space will cause indices to become read-only.

1. **Disk Watermarks**: Elasticsearch has disk watermark settings that prevent further data from being written when disk space is low.

Check your disk usage with:
<nowiki>
curl -X GET "localhost:9200/_cat/allocation?v=true&pretty"</nowiki>

If you encounter the "disk full" issue, free up space or increase storage capacity.

2. **Index Read-Only**: Elasticsearch will automatically mark indices as read-only if disk space is too low. To remove the read-only flag:

<nowiki>
PUT /index_name/_settings
{
"settings": {
"index.blocks.read_only": false
}
}</nowiki>

== Snapshot and Restore Issues ==

When performing snapshots and restores, ensure that:
* You are using a compatible version of Elasticsearch.
* You have enough storage space on the repository location.
* The repository is correctly registered.

Check the snapshot status:

<nowiki>
GET /_snapshot/snapshot_name/_status</nowiki>

If you encounter issues during restore, verify that the index mappings are compatible between source and target clusters.

== Networking Issues ==

Elasticsearch requires proper network configuration between nodes in the cluster.

1. **Port Accessibility**: Ensure that the required ports (default 9200 for HTTP and 9300 for inter-node communication) are open and accessible.

To check port accessibility:

<nowiki>
telnet localhost 9200 </nowiki>

2. **Timeouts and Latency**: Network latency or timeouts can affect cluster communication. Ensure your nodes have reliable network connections.

== Useful Links ==

* [Elasticsearch Documentation](https://www.elastic.co/guide/en/elasticsearch/reference/index.html)
* [Elasticsearch Troubleshooting Guide](https://www.elastic.co/guide/en/elasticsearch/reference/current/_troubleshooting.html)
* [Elasticsearch Query DSL](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html)
* [Elastic Community Forum](https://discuss.elastic.co/)
* [Elasticsearch GitHub Repository](https://github.com/elastic/elasticsearch)

ELASTICSEARCH - Troubleshoot - Revision history

Admin: Text replacement - "Category:Wiki" to "Category:Wiki '''''[https://it-arts.net/index.php/Category:Wiki Return to Wiki Index]''''' "