Filebeat god restart

Elastic Stack Beats
1

I want to restart an old Filebeat service after modifying its output.

This is the result of ps -eaf | grep filebeat:

root      6405     1  0  2020 ?        00:00:00 /usr/share/filebeat/bin/filebeat-god -r / -n -p /var/run/filebeat.pid -- /usr/share/filebeat/bin/filebeat -c /etc/filebeat/filebeat.yml -path.home /usr/share/filebeat -path.config /etc/filebeat -path.data /var/lib/filebeat -path.logs /var/log/filebeat
root      6406  6405  0  2020 ?        11:35:43 /usr/share/filebeat/bin/filebeat -c /etc/filebeat/filebeat.yml -path.home /usr/share/filebeat -path.config /etc/filebeat -path.data /var/lib/filebeat -path.logs /var/log/filebeat

Does this mean there are 2 instances of Filebeat running? Or is the second process a child of the first one? How can I restart Filebeat in this case?

2

Should I simply rerun the first cmd ... ...filebeat-god... ?

3

How did you start it originally?

Perhaps with systemctl

See here

systemctl status filebeat
systemctl stop filebeat
systemctl start filebeat
4

This doesn't look standard, is it possible someone made a custom unique install (AKA Snowflake)?

1 Like
5

I would tend to agree with @rugenl

6

I do not have any idea on this. It was installed by someone who isn't in the org anymore and the KT is lost.

I'm gonna go with service cmds since service status filebeat seems to work fine.

7

These steps worked to upgrade the service Logstash (v2.2 to v7.x) consuming data from Filebeat (v7.8):

# Steps followed (in order):

  service filebeat stop
  ps -eaf | grep filebeat
  service logstash stop
  ps -eaf | grep logstash

  sudo apt remove logstash
  wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
  sudo apt-get install apt-transport-https
  echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
  sudo apt-get install logstash
  apt-get update
  service logstash status # returns `logstash stop/waiting`

  # modify `/etc/logstash/pipelines.yml`
  # modify/remove/add the required .conf files in `/etc/logstash/conf.d/`

  service logstash start
  ps -eaf | grep logstash
  service filebeat start
  ps -eaf | grep filebeat

I tried upgrading to v7.13.x based on compatibility matrix, using the following cmd:
echo "deb https://artifacts.elastic.co/packages/7.13.4/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.13.4.list
But v7.14 got installed anyway. And the pipeline is working great, and the results are as expected.

Will that cause future Filebeat compatibility issues?

8

I didn't read all the change nodes, but the run of 7.13.x and 7.14 seems to have been mostly security fixes in Elasticsearch. IMHO, the beats often get released just to keep the versions in sync.

FYI, there are other posts about filebeat-god like Filebeat-god description? - #3 by paulkeogh. Did you notice what your old version of filebeat was? I wonder if it was older, I don't find file in my current install.

1 Like
9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.