Open mtojek opened 3 years ago
Pinging @elastic/fleet (Team:Fleet)
Another stack trace:
Performing setup of Fleet in Kibana
Kibana Fleet setup failed: http POST request to http://kibana:5601/api/fleet/setup fails: <nil>. Response: {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}
Kibana Fleet setup failed: http POST request to http://kibana:5601/api/fleet/setup fails: <nil>. Response: {"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred."}
The Elastic Agent is currently in BETA and should not be used in production
2021-03-31T10:53:41.842Z INFO cmd/enroll_cmd.go:185 Elastic Agent might not be running; unable to trigger restart
2021-03-31T10:53:41.842Z INFO cmd/enroll_cmd.go:187 Successfully triggered restart on running Elastic Agent.
Successfully enrolled the Elastic Agent.
Not sure here what could be the cause here, @nchaulet or @urso have you seen this?
Another occurrence:
https://beats-ci.elastic.co/job/Ingest-manager/job/integrations/job/master/171/artifact/build/elastic-stack-dump/latest/proofpoint/logs/elastic-agent.log https://beats-ci.elastic.co/job/Ingest-manager/job/integrations/job/master/171/artifact/build/elastic-stack-dump/latest/proofpoint/logs/elasticsearch.log https://beats-ci.elastic.co/job/Ingest-manager/job/integrations/job/master/171/artifact/build/elastic-stack-dump/latest/proofpoint/logs/kibana.log https://beats-ci.elastic.co/job/Ingest-manager/job/integrations/job/master/171/artifact/build/elastic-stack-dump/latest/proofpoint/logs/package-registry.log
and again in pair with .security-7
index issue. Let me know if you need to more data.
My suspicion is that the .security-7
error is somehow related to the docker setup. We should figure out how to get rid of this issue and see if the other problems persist.
We tried here: https://github.com/elastic/kibana/issues/90148
Maybe we can improve the healthcheck by checking the status of http://localhost:9200/_cat/shards
:
.security-7 0 p STARTED 65 202.8kb 127.0.0.1 532fa6814a6a
We can check if that shard has been started, WDYT?
@ycombinator Any idea?
Looking at the errors in the various logs, this looks like an internal Kibana error to me. When the Fleet Server (or is it Agent? or either?) is calling POST /api/fleet/setup
, the Kibana code behind those APIs is trying to make some Elasticsearch API call, which fails because the .security
index isn't green yet.
A similar thing seems to be happening when GET /login
is being called. The user agent there is curl
so I'm not sure exactly what is calling that or if it was a human doing some testing.
In either case, I think it would be great if Kibana could expose a Fleet health check API that will allow Fleet Server or Agent to ask the question, "Is Fleet ready or not?" before calling POST /api/fleet/setup
or any other Fleet APIs. Maybe there is or there can be something in the GET /api/status
Kibana API response or maybe there should be a dedicated GET /api/fleet/status
endpoint for this. Internally within Fleet UI code, this status API would make sure the Elasticsearch Security index is ready (i.e. not red) before it tries to use it; until then the status API would respond as "not ready". To check if the index is not ready, this Elasticsearch API call could be used: http://localhost:9200/_cat/indices/.security-*?h=health&format=json.
Thoughts?
I think I partially mimicked it here: https://github.com/elastic/elastic-package/pull/311 . Could you please take a look?
Blocker: https://github.com/elastic/elastic-package/issues/278
I spotted this while integrating with Fleet Server. Fun fact - all our integration tests passed! I mean, Kibana/Fleet/Agent behave correctly in terms of HTTP responses, but logs are full or errors. I suppose that someone would like to check it.
Fleet Server:
Kibana:
(source: https://beats-ci.elastic.co/job/Ingest-manager/job/elastic-package/job/PR-279/33/artifact/build/elastic-stack-dump/check/logs/kibana.log)
Elasticsearch:
(source: https://beats-ci.elastic.co/job/Ingest-manager/job/elastic-package/job/PR-279/33/artifact/build/elastic-stack-dump/check/logs/elasticsearch.log) - not sure if this one is relevant.