In reviewing the OVA, it is clear it is ideal to work with and is probably the best attributes to have for a production system. Chef scripts make it easy to do operations which are usually manual.
However, it is said that this OVA is not ideal for production environment. What are the attributes that make it not ideal for production environment?
a) I understand file limits is not sufficient for Graylog2 case.
b) Disk size at the moment might be a bit small (depending on requirements).
c) While the Graylog version line maybe static, Chef tools allow for upgrade to latest versions.
d) Maybe there are more points I am missing.
So what makes the OVA not ideal for production use? Or what needs to be done to the OVA in order for it to be OK for production use?
Most importantly an utter lack of high availability (HA) and disaster recoverability (DR). Aside from that, the fact that three pieces of software will fight for resources.
Graylog runs on top of ElasticSearch and MongoDB.
MongoDB requires only very little processing resources, but since it contains the whole config of Graylog you don’t want to lose access to the db!
Graylog runs the inputs that receive all your logging. You don’t want to miss out on logging when one host goes down, so you’d better run the same inputs on multiple hosts.
Ditto for the web interface.
Even worse for ElasticSearch! Are you really going to throw all your logging data onto one host, praying it will never go tits up?
With only one host running everything, you can’t properly perform any maintenance.
I have another opinion.
Maybe it’s about the responsibility.
If you want to use a system, you have to plan it. It is a fast way to test the software, and check what you need.
Someone else installed it, so it can have errors. Or just thought another way than you.
You have to know what is your desire about HA and DR as @Totally_Not_A_Robot mentioned.
The technically problems as I read before, You can’t set the DNS and/or NTP servers. (But I’m not sure)
If someone decides to run production on this ready-made OVA and things go screwy, they can’t sue Graylog Inc saying “You never said that we couldn’t!”… Because, yes they did.
Thank you @macko003 & @Totally_Not_A_Robot. These are thought stimulating points. It is clear that one cannot take a short cut when it comes to system planning and the responsibility for the implementation.
At this moment in time my installations have not considered HA nor DR failover. But it is something I need to consider.
Honestly I can’t understand if you use OVA for productive envirement. A Graylog install is not more than 1 hour with everything.
If you install the three main components, it’s working without any work.
Well, admittedly that’s only true if you have already figured everything out beforehand, have prior experience with the tools and mostly go for default settings.
When designing and building my environment I had zero experience with Mongo, Elastic or Graylog. Not with ELK either. I had to learn how to properly and safely configure Mongo, Elastic and Graylog clusters, including locked down accounts and TLS certificates. Figuring out how to do everything, from alpha to omega took me two days of work. Actually building the whole setup, following my own instructions document, takes roughly a whole day. But as I said, that includes prepping the VMs, creating the required certificates and everything.
You are right. But if you need a basic one node graylog, you just need installs the components, and GL will work.
And I installed many systems, so I know it. But if I have no experience, and I have an OVA. I’m not sure I will do a clean install.
