Hi all,
Just setting up a minimal stand-alone (read: single server) elasticsearch
v1.7.2 and graylog v1.2.1 setup for the first time, and I've encountered
something that I consider a little weird. Specifically, I am disabling zen
auto-discovery on both sides, but it looks like graylog is still
*attempting* to use auto-discovery. Log entries of a startup look like
this:
*elasticsearch log entries*
...
[2015-10-14 19:56:40,997][INFO ][transport ]
[elasticsearch-herodotus.clio.com] bound_address {inet[/127.0.0.1:9300]},
publish_address {inet[/127.0.0.1:9300]}
[2015-10-14 19:56:41,008][INFO ][discovery ]
[elasticsearch-herodotus.clio.com] herodotus/2AE10OVXTZqUacq8-0vAXg
[2015-10-14 19:56:44,029][INFO ][cluster.service ]
[elasticsearch-herodotus.clio.com] new_master
[elasticsearch-herodotus.clio.com][2AE10OVXTZqUacq8-0vAXg][herodotus][inet[/127.0.0.1:9300]],
reason: zen-disco-join (elected_as_master)
[2015-10-14 19:56:44,051][INFO ][http ]
[elasticsearch-herodotus.clio.com] bound_address {inet[/127.0.0.1:9200]},
publish_address {inet[/127.0.0.1:9200]}
[2015-10-14 19:56:44,052][INFO ][node ]
[elasticsearch-herodotus.clio.com] started
[2015-10-14 19:56:44,082][INFO ][gateway ]
[elasticsearch-herodotus.clio.com] recovered [1] indices into cluster_state
[2015-10-14 19:57:39,337][INFO ][cluster.service ]
[elasticsearch-herodotus.clio.com] added
{[graylog2-server-herodotus.clio.com][3Ca02cwTRiiQDkp334oPkg][herodotus][inet[/127.0.0.1:9350]]{client=true,
data=false, master=false},}, reason: zen-disco-receive(join from
node[[graylog2-server-herodotus.clio.com][3Ca02cwTRiiQDkp334oPkg][herodotus][inet[/127.0.0.1:9350]]{client=true,
data=false, master=false}])
*graylog-server log entries*
...
2015-10-14T19:57:36.198Z INFO [node] [graylog2-server-herodotus.clio.com]
starting ...
...
2015-10-14T19:57:36.206Z INFO [IndexRetentionThread] Elasticsearch cluster
not available, skipping index retention checks.
...
2015-10-14T19:57:36.227Z INFO [IndexerClusterCheckerThread] Indexer not
fully initialized yet. Skipping periodic cluster check.
...
2015-10-14T19:57:36.293Z INFO [transport]
[graylog2-server-herodotus.clio.com] bound_address {inet[/127.0.0.1:9350]},
publish_address {inet[/127.0.0.1:9350]}
2015-10-14T19:57:36.305Z INFO [discovery]
[graylog2-server-herodotus.clio.com] herodotus/3Ca02cwTRiiQDkp334oPkg
...
2015-10-14T19:57:39.305Z WARN [discovery]
[graylog2-server-herodotus.clio.com] waited for 3s and no initial state was
set by the discovery
2015-10-14T19:57:39.305Z INFO [node] [graylog2-server-herodotus.clio.com]
started
2015-10-14T19:57:39.373Z INFO [service]
[graylog2-server-herodotus.clio.com] detected_master
[elasticsearch-herodotus.clio.com][2AE10OVXTZqUacq8-0vAXg][herodotus][inet[/127.0.0.1:9300]],
added
{[elasticsearch-herodotus.clio.com][2AE10OVXTZqUacq8-0vAXg][herodotus][inet[/127.0.0.1:9300]],},
reason: zen-disco-receive(from master
[[elasticsearch-herodotus.clio.com][2AE10OVXTZqUacq8-0vAXg][herodotus][inet[/127.0.0.1:9300]]])
2015-10-14T19:57:41.841Z INFO [RestApiService] Adding security context
factory: <org.graylog2.security.ShiroSecurityContextFactory@4cfa2ec3>
2015-10-14T19:57:41.862Z INFO [RestApiService] Started REST API at
<http://127.0.0.1:12900/>
2015-10-14T19:57:41.863Z INFO [ServiceManagerListener] Services are healthy
2015-10-14T19:57:41.863Z INFO [InputSetupService] Triggering launching
persisted inputs, node transitioned from Uninitialized [LB:DEAD] to Running
[LB:ALIVE]
2015-10-14T19:57:41.864Z INFO [ServerBootstrap] Services started, startup
times in ms: {MetricsReporterService [RUNNING]=1, JournalReader
[RUNNING]=1, BufferSynchronizerService [RUNNING]=1, OutputSetupService
[RUNNING]=1, InputSetupService [RUNNING]=3, KafkaJournal [RUNNING]=5,
DashboardRegistryService [RUNNING]=5, PeriodicalsService [RUNNING]=60,
IndexerSetupService [RUNNING]=3198, RestApiService [RUNNING]=5671}
2015-10-14T19:57:41.867Z INFO [ServerBootstrap] Graylog server up and
running.
As you can see, Graylog and Elasticsearch do seem to find each other (just
after the discovery timeout at 19:57:39), but what gives me pause is the
warning about discovery failing after 3s. Graylog, to my understanding,
should not even be *trying* service discovery (it is disabled) -- but it
seems to be, and it slows down the service startup by exactly 3s while the
startup waits for the discovery to timeout. Does anyone know why it is
attempting zen auto-discovery, even though it is disabled? The relevant
bits of the elasticsearch and graylog configuration(s) follow.
*/etc/elasticsearch/elasticsearch.yml*
cluster.name: "herodotus"
node.name: "elasticsearch-herodotus.clio.com"
bootstrap.mlockall: true
network.host: 127.0.0.1
discovery.zen.ping.multicast.enabled: false
*/etc/graylog/server/server.conf*
elasticsearch_max_size_per_index = 4294967296
elasticsearch_max_number_of_indices = 10
elasticsearch_shards = 1
elasticsearch_replicas = 0
elasticsearch_index_prefix = graylog2
elasticsearch_cluster_name = herodotus
elasticsearch_node_name = graylog2-server-herodotus.clio.com
elasticsearch_discovery_zen_ping_multicast_enabled = false
elasticsearch_discovery_zen_ping_unicast_hosts = 127.0.0.1:9300
elasticsearch_network_host = 127.0.0.1
elasticsearch_analyzer = standard
Thanks for whatever guidance that you provide -- I think that everything
will work in the current setup, but I'm *really* curious what the warning
about the discovery timeout is based on/why it is occurring. It would be
great if I could clear it up.
Thanks,
Remi
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/7114caf4-aa82-453d-a713-ced85885ebed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
