- new Ubuntu18 vm, ip addr: 192.168.1.42 hostname: Aramaki (patches up-to-date. static host entered in local dns service)
- [ESXi 6.7u2 host ip addr: 192.168.1.40 ]
- Win10 1903 workstation, ip addr: 192.168.1.20 hostname: Hikari (patches up-to-date. host auto-registered in local dns)
Elasticsearch.yml configs changed/set from default:
- cluster.name: Section9
- node.name: Aramaki
- node.attr.rack: v1
- network.host: 192.168.1.42
- http.port: 9200
- discovery.seed_hosts: ["192.168.1.42"]
- cluster.initial_master_nodes: ["192.168.1.42"]
Node starts properly and joins cluster. This is the first/only node at this time.
Kibana.yml configs changed/set from default:
- server.port: 5601
- server.host: "192.168.1.42"
- server.name: "Aramaki"
- elasticsearch.hosts: ["http://192.168.1.42:9200"]
Service starts properly and is browser-accessible from all other systems on network.
Winlogbeat.yml configs changed/set from default:
- host: "192.168.1.42:5601"
- hosts: ["192.168.1.42:9200"]
Installed on workstation & service registered properly
winlogbeat test config -c winlogbeat.yml from elevated PS prompt produces "config OK"
winlogbeat setup --dashboards produces following output:
Loading dashboards (Kibana must be running and reachable)
Exiting: error connecting to Kibana: fail to get the Kibana version: HTTP GET request to http://localhost:5601/api/status fails: fail to execute the HTTP GET request: Get http://localhost:5601/api/status: dial tcp [::1]:5601: connectex: No connection could be made because the target machine actively refused it.. Response: .
Service will start and export logs to ES, but no sample dashboards are loaded.
Setting yml option setup.dashboards.enabled to true causes service start to fail with similar message in logs. Using "192.168.1.42", "http://192.168.1.42:5601" or other variations for kibana host have no impact.
Setting yml options logging.level: debug and logging.selectors: ["*"] , suddenly the command-line setup recognizes the host settings and properly loads the dashboards into Kibana.
I was having similar issues getting the Metricbeat install with the same manner of configuration to run setup properly, but like Winlogbeat, turning on debug logging allowed the setup to proceed.