<div dir="ltr">Hello Folks,<br><br>Thank you Jeremy and Clark for sharing the issue that you have. I understand that the main issue is related to a lack of time. <div>ELK stack requires a lot of resources, but the values that you share probably can be optimized. Is it possible to share </div><div>the architecture, how many servers are using which Elasticsearch server role (master, data servers, etc.) ?<br><br>My team is managing RDO infra, which contains an ELK stack based on Opendistro for Elasticsearch. </div><div>We have ansible playbooks to setup Elasticsearch base on Opendistro just on one node. Almost all of ELK </div><div>stack services are located on one server that does not utilize a lot of resources (the retention time is set to</div><div>10 days, 90GB of HDD is used, 2GB of RAM for Elasticsearch, 512MB for Logstash). <br>Could you share, what is the retention time set currently in the cluster that it requires 1 TB disk? Also other statistics like</div><div> how many queries are done in kibana and how much of HDD disk space is used by the Openstack project and compare </div><div>it to other projects that are available in Opendev?<br><br>In the end, I would like to ask, if you can share what is the Elasticsearch version currently running on your servers and if </div><div>you can share the -Xmx and -Xms parameters that are set in Logstash, Elasticsearch and Kibana.<br><br>Thank you for your time and effort in keeping things running smoothly for OpenDev.  We find the OpenDev ELK stack </div><div>valuable enough to the OpenDev community to take a much larger role in keeping it running.   </div><div>If you can think of any additional links or information that may be helpful to us taking a larger role here, please do not </div><div>hesitate to share it.<br></div><div><br>Dan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 3:20 PM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-05-12 02:05:57 -0700 (-0700), Sorin Sbarnea wrote:<br>
[...]<br>
> TripleO health check project relies on being able to query ER from<br>
> both opendev and rdo in order to easy identification of problems.<br>
<br>
Since you say RDO has a similar setup, could they just expand to<br>
start indexing our logs? As previously stated, doing that doesn't<br>
require any special access to our infrastructure.<br>
<br>
> Maybe instead of dropping we should rethink what it is supposed to<br>
> index and not, set some hard limits per job and scale down the<br>
> deployment. IMHO, one of the major issues with it is that it does<br>
> try to index maybe too much w/o filtering noisy output before<br>
> indexing.<br>
<br>
Reducing how much we index doesn't solve the most pressing problem,<br>
which is that we need to upgrade the underlying operating system,<br>
therefore replace the current current configuration management which<br>
won't work on newer platforms, and also almost certainly upgrade<br>
versions of the major components in use for it. Nobody has time to<br>
do that, at least nobody who has heard our previous cries for help.<br>
<br>
> If we can delay making a decision a little bit so we can<br>
> investigate all available options it would really be great.<br>
<br>
This thread hasn't set any timeline for stopping the service, not<br>
yet anyway.<br>
<br>
> I worth noting that I personally do not have a special love for ES<br>
> but I do value a lot what it does. I am also pragmatic and I would<br>
> not be very upset to make use of a SaaS service as an alternative,<br>
> especially as I recognize how costly is to run and maintain an<br>
> instance.<br>
[...]<br>
<br>
It's been pointed out that OVH has a similar-sounding service, if<br>
someone is interested in experimenting with it:<br>
<br>
<a href="https://www.ovhcloud.com/en-ca/data-platforms/logs/" rel="noreferrer" target="_blank">https://www.ovhcloud.com/en-ca/data-platforms/logs/</a><br>
<br>
The case with this, and I think with any SaaS solution, is that<br>
there would still need to be a separate ingestion mechanism to<br>
identify when new logs are available, postprocess them to remove<br>
debug lines, and then feed them to the indexing service at the<br>
provider... something our current team doesn't have time to design<br>
and manage.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr" style="color:rgb(136,136,136)"><div dir="ltr"><div dir="ltr">Regards,</div><div dir="ltr">Daniel Pawlik<br><table border="0"><tbody><tr></tr></tbody></table></div></div></div></div></div></div></div></div>