Freephile Wiki

Elasticsearch: Difference between revisions

Browse history interactively
← Older edit
VisualWikitext
m Text replacement - "<(\/?)source" to "<$1syntaxhighlight"
 
(2 intermediate revisions by the same user not shown)
Line 8: Line 8:
{{#set:feature tests = Search for something in "files" which indicates that PDF index results are returned instead of just articles. E.g.[https://wiki.freephile.org/wiki/index.php?title=Special:Search&profile=advanced&profile=advanced&fulltext=Search&search=ssh-agent&ns6=1 Search for 'ssh-agent' in the File namespace] }}
{{#set:feature tests = Search for something in "files" which indicates that PDF index results are returned instead of just articles. E.g.[https://wiki.freephile.org/wiki/index.php?title=Special:Search&profile=advanced&profile=advanced&fulltext=Search&search=ssh-agent&ns6=1 Search for 'ssh-agent' in the File namespace] }}
{{#set:feature examples =  }}
{{#set:feature examples =  }}
This site uses Elasticsearch for it's search functionality under the hood.
This site uses Elasticsearch for it's search functionality under the hood.


Line 73: Line 74:


For version 1.7 on Ubuntu 16.04, although the system uses SystemD, there is still a SysV init script that controls elasticsearch. I think this means that you can't get the logging info into the journalctl system... See /etc/init.d/elasticsearch According to the [https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html install guide], you should be able to edit the elasticsearch.service file, and take out the --quiet option to make it log to the journal.  When that is enabled, you can do <code>journalctl --unit elasticsearch</code> to quickly see the info being logged.
For version 1.7 on Ubuntu 16.04, although the system uses SystemD, there is still a SysV init script that controls elasticsearch. I think this means that you can't get the logging info into the journalctl system... See /etc/init.d/elasticsearch According to the [https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html install guide], you should be able to edit the elasticsearch.service file, and take out the --quiet option to make it log to the journal.  When that is enabled, you can do <code>journalctl --unit elasticsearch</code> to quickly see the info being logged.
=== Out of memory ===
If Elasticsearch has died, and when you try to start it with <code>systemctl start elasticsearch</code>
you may see an error like ''''Not enough space'''<nowiki/>' - which in this case is actually a memory error. If you look at disk space, there is no problem.
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000080000000, 2147483648, 0) failed; error='Not enough space' (errno=12)
Elasticsearch will write an error log to <code>/var/log/elasticsearch/hs_err*</code> where the PID is appended, eg. <code>_pid4061142.log</code>  There is valuable info in that file to tell you specifically what's wrong; and suggests ways to fix it. In my case, I only had to stop both kibana and elasticsearch; and then start elasticsearch first to let it claim it's memory; followed by starting kibana
There's a good chance that if you are running out of memory that it is because your virtual host is not configured to use any [[Swap]] partition.


==Production Configuration==
==Production Configuration==
Line 228: Line 237:


==Monitoring==
==Monitoring==
With the upgrade to Elasticsearch 5.x and 6.x, plugins are deprecated. It's suggested to use [[Kibana]] as a monitoring and management interface to Elasticsearch.
It's suggested to use '''[[Kibana]]''' as a monitoring and management interface to Elasticsearch.
<img src="http://meta.qualitybox.us:20000/api/v1/badge.svg?chart=elasticsearch_local.cluster_health_status&alarm=elasticsearch_last_collected&refresh=auto" />


http://meta.qualitybox.us:20000/api/v1/badge.svg?chart=elasticsearch_local.cluster_health_status&alarm=elasticsearch_last_collected&refresh=auto" type="image/svg+xml
You'll need to set xpack.monitoring.collection.enabled=true for Elasticsearch to do self-monitoring. If that is enabled in your elasticsearch.yml, then you can navigate in the left-panel of Kibana to "Stack Monitoring" under the "Management" section at the bottom. However that is called 'internal monitoring'. It has long been recommended to use a distinct 'external' service called '''Metricbeat''' for monitoring the health of your Elasticsearch cluster.




<html>
[[File:Kibana-self-monitoring.png|thumb]]
<embed src="http://meta.qualitybox.us:20000/api/v1/badge.svg?chart=elasticsearch_local.cluster_health_status&alarm=elasticsearch_last_collected&refresh=auto" type="image/svg+xml" height="20"/>
</html>


*Monitoring the Elastic Stack https://www.elastic.co/guide/en/elastic-stack-overview/6.4/xpack-monitoring.html
 
*Monitoring Settings https://www.elastic.co/guide/en/elasticsearch/reference/6.4/monitoring-settings.html
Although you can turn on monitoring in the Kibana Web interface, you can also use curl on the command line to inspect and set cluster settings.
*X-Pack monitoring https://www.elastic.co/guide/en/kibana/current/xpack-monitoring.html
<syntaxhighlight lang="bash">
*Configuring Monitoring in Kibana https://www.elastic.co/guide/en/kibana/6.4/monitoring-xpack-kibana.html
curl -X GET "localhost:9200/_cluster/settings?pretty"
*Monitoring with [https://github.com/lmenezes/cerebro Cerebro]
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
*You can still use [https://mobz.github.io/elasticsearch-head/ elasticsearch-head] if you use an SSH reverse tunnel to access the remote server.
{
  "persistent": {
    "xpack.monitoring.collection.enabled": true
  }
}
</syntaxhighlight>




Retrieved from "https://wiki.freephile.org/wiki/Elasticsearch"