Hi Bob,
On Friday, 6 January 2017 16:27:36 UTC+1, Bob wrote:
>
> Do you recommend high volume nodes be physical?
>
Yes.
Cheers,
Jochen
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails
Jochen, given the issues with remote storage for the journal... Do you
recommend high volume nodes be physical? I run into issues with my
receiving nodes where once a node has significant messages in the journal
it can take considerable time to recover. Often during these periods the
system in
To share some more insights and describe how I managed to get Graylog to
perform better:
Grok patterns are very costly as mentioned earlier so I went ahead and
looked for a solution that better
indexed those custom logs (in my case sidewinder firewall SEF-format) than
having an input with
~ 12
Hi Jochen,
in enteprise environments you don´t use SAN for network mounted drives -
they become the sole disk infracstructure for your virtual appliances
run on (with fibrechannel in our case or iSCSI or FCoE in other cases). The
i/o usually feels and acts like local disk mounted volumes.
The
Hi Jerri,
On Thursday, 5 January 2017 14:34:08 UTC+1, Jerri Son wrote:
>
> of that I am aware, alas, a SAN usually provides storage for a virtual
> infrastructure and as such acts as a "local" drive :)
>
The disk journal implementation makes heavy use of the disk (write-through)
cache to
Hi Jochen,
of that I am aware, alas, a SAN usually provides storage for a virtual
infrastructure and as such acts as a "local" drive :)
I´ve been trying to find the right settings for our environment for the
last 2 days (amount of procs in the server.conf, output_batch_size, etc.)
in order to
Hi Jerri,
the Graylog disk journal should *always* run locally and *never* be placed
on a "remote" disk (like a SAN or any other network storage).
You can change the journal directory with the message_journal_dir
Just to share my finding after testing a lot: once I disabled the intranel
graylog journaling I get the desired I/O. This might be attributed to my
SAN backend but surely enough
I can finally run the latest and greatest gralyog features :)
--
You received this message because you are
Hi Cazy,
thank you so much for your response! I´ll be willing to give it another try
and apply your suggestions - I could live with a "little" worse after the
upgrade
just not with an almost complete standstill.
Am Montag, 7. November 2016 11:44:41 UTC+1 schrieb cazy:
>
> Hi Jerri,
>
> same
Hi Jerri,
same here! We experienced quite the same problems after upgrading from GL
1.3.4/ES 1.7.1 to GL2.1.1/ES 2.3.5.
Graylog support recommended increasing output batch size (see also Bob's
comment) so we increased the value from 500 to 5000.
Moreover, you should set the ES-parameter
Hi bob,
appreciate your answer!
The VM specs don´t change while upgrading and judging from the CPU
utilization I can´t really see a difference between
ES 2.3.5 and ES 1.7.1. My inputs come from various sources, logstash,
nxlog, raw udp, etc. Inputs don´t change
when upgrading though and I get
With 4 cpu's on your ES server your bulk threads will max out at 4, with a
1000 message output batch size that would set your max to essentially 4k
msg/s. I would increase the output batch size and add cpu on the ES vm.
Also you didn't mention what your input config is in graylog, are you sure
I´d like to add 2 more Graphs we have from our ES host (upgrade took place
on wednesday and was reverted thursday):
http://imgur.com/euZOPMq -> TCP MIB, where you can clearly see a lot less
established session with the upgraded setup
and
http://imgur.com/qPnR69Y -> Traffic took a serious drop
13 matches
Mail list logo
