Download Graylog V5.0 now and post your impressions, questions, and suggestions

Hey Graylog Open Members,

Graylog 5.0 is here and available for download. Try it our and ask questions or leave your feedback here.

Download Graylog 5.0 now and let us know what you think!

Also, check out these resources for more information:

So what’s new? See Graylog v5.0 in action
Graylog 5.0 Release Announcement
Graylog 5.0 Installation Documentation
Register now to join our technical experts for a live look at Graylog v5.0 on January 11, 2023, at 11 am ET.

Let’s get the discussion going here. What are your thoughts, questions, and suggestions?


@dscryber Might be some issue with links in the documentation, for example here
when clicking on say CentOS installation
I receive this:

I also noticed under Upgrading Graylog section.

Click on Manual Upgrade, Ubuntu Upgrade, etc.. nothing happens. I’m assuming there still working on it?

Hey @dscryber

Graylog Docker Install /Upgrade did not work very well.
I am fairly new at Docker but I have upgrade my service several time with out any issues. From the error in the logs I need to at least have MongoDb 5.0 install (i.e., I tried with MongoDb 4.4, it was a no go). MongoDb Container failed to be created.
The following link describe what I execute. I’m waiting for Deb package from OpenSearch before I start upgrade my Prod servers.

Also I found this here. Not sure if this is actual cause

yeah, tried in place upgrade, opensearch 2.4.0 screams about old indices created with es 6.8.11 so tried jumping back to 1.3.6 which now screams my indices are already upgraded to lucene 9, how deep is sh*t i’m in? is there any way to delete old indices while opensearch is offline?

EDIT: started clear node in another directory, logs must flow, any ideas on how to recover old data?

Now that Java is bundled within the Graylog installer, is the JVM heap size still managed via /etc/default/graylog-server ?

@maniel @Alper

My Docker Operation setup is still unable to upgrade, I have been going over what documentation they have for an upgrade/configuration needed but still haven’t found a completed resolve yet…
I made sure JAVA 17 was installed, Image MongoDb 5.0.13-14 & Graylog 5 Image.
Posted a “some what” resolve on the CPU issue on GitHub from the link above.

root@ansible:/usr/local/bin# sudo update-alternatives --config java
There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
* 0            /usr/lib/jvm/java-17-openjdk-amd64/bin/java      1711      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      manual mode
  2            /usr/lib/jvm/java-17-openjdk-amd64/bin/java      1711      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press <enter> to keep the current choice[*], or type selection number:

I just start working with Docker for 11 months now, execute a few upgrades/Updates without an issue.
Here is the file I’ve been using.

root@ansible:/usr/local/bin# cat docker-compose.yaml
version: '3'
   # MongoDB:
    image: mongo:4.4.18
    #image: mongo:5.0.14
    #image: mongo:latest
    network_mode: bridge
   # DB in share for persistence
      - mongo_data:/data/db
   # Elasticsearch:
    # image: opensearchproject/opensearch:1.3.2
    network_mode: bridge
    #data folder in share for persistence
      - es_data:/usr/share/elasticsearch/data
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
        soft: -1
        hard: -1
    mem_limit: 1g
   # Graylog:
    #image: graylog/graylog-enterprise:4.3.3-jre11
    image: graylog/graylog-enterprise:4.3.9-jre11
    #image: graylog/graylog-enterprise:5.0.0
    network_mode: bridge
   # journal and config directories in local NFS share for persistence
       - graylog_journal:/usr/share/graylog/data/journal
       # - graylog_bin:/usr/share/graylog/bin
       - graylog_bin:/usr/share/graylog-server/bin/
       - graylog_data:/usr/share/graylog/data/config
       - graylog_log:/usr/share/graylog/data/log
       - graylog_plugin:/usr/share/graylog/data/plugin
       - graylog_content:/usr/share/graylog/data/contentpacks
      # Mount local configuration directory into Docker container
       - graylog_scripts:/usr/share/graylog/scripts
       #- ./graylog/data/journal:/usr/share/graylog/data/journal
       #- ./graylog/config:/usr/share/graylog/data/config

      # Container time Zone
      - TZ=America/Chicago
      # CHANGE ME (must be at least 16 characters)!
      - GRAYLOG_PASSWORD_SECRET=pJod1TRZAckHmqM2oQPqX1qnLVJS99jHm2DuCux2Bpiuu2XLTZuyb2YW9eHiKLTifjy7cLpeWIjWgMtnwZf6Q79HW2nonDhN
      # Password: admin
      - GRAYLOG_ROOT_PASSWORD_SHA2=ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
      - GRAYLOG_ROOT_TIMEZONE=America/Chicago
      - GRAYLOG_TRANSPORT_FROM_EMAIL=root@localhost
      #- depends_on: GRAYLOG_REPORT_RENDER_URI=
      - GRAYLOG_REPORT_USER=graylog-report
      driver: syslog
        syslog-address: "udp://"
        syslog-facility: "local7"
        syslog-format: "rfc3164"
        tag: "asible"
      - mongodb:mongo
      - elasticsearch
      - mongodb
      - elasticsearch
      # Graylog web interface and REST API
      - 9000:9000
      # Syslog TCP
      - 8514:8514
      # Elasticsearch
      - 9200:9200
      - 9300:9300
      # Syslog UDP
      - 8514:8514/udp
      # GELF TCP
      #- 12201:12201
      # GELF UDP
      - 12201:12201/udp
      # Reports
      - 9515:9515
      - 9515:9515/udp
      # beats
      - 5044:5044
      # email
      - 25:25
      - 25:25/udp
      # web
      - 80:80
      - 443:443
      - 21:21
      # Forwarder
      - 13302:13302
      - 13301:13301
      # keycloak
      - 8443:8443
      # packetbeat
      - 5055:5055
      # Syslogs
      - 51420:51420
      # CEF Messages
      - 5555:5555/udp
#Volumes for persisting data, see
    driver: local
    driver: local
    driver: local
    driver: local
    driver: local
    driver: local
    driver: local
    driver: local
    driver: local

root # docker-compose up -d

Command show Mongo update was “Done” but the container was not started. having issue with naming convention with Mongo Container.

Dec  8 17:27:53 ansible kernel: [ 2473.152844] traps: mongod[18239] trap invalid opcode ip:56311d63fa7a sp:7ffc21b4de10 error:0 in mongod[5631195ba000+51eb000]

And this

Cannot link to a non running container: /876472e84634_bin_mongodb_1 AS /bin_graylog_1/bin_mongodb_1"

Since I am fairly new at Docker, I researching how to resolve this issue.

Not sure yet, still working on the upgrade, plus I’m waiting for OpenSearch to release Deb package because I’m on CentOS 7 right now and I’m going to wipe the server to install Ubuntu 20+ then rebuild it.

Umm good question, I do know from elasticsearch you can always upgrade but there will be lose of data if you back track. I’m assuming this also goes for OpenSearch.

@gsmith I’ll check out the links and alert documentation. Thanks!

1 Like

For those who are having troubles with installing/starting mongoDb-5.0 found a link that pretty much sums it up.


i’m kinda okay with deleting old indices indexed by ES <7 manually but it’s really tedious, basically opensearch 2.* complains about one index at a time which gives me it’s directory name which i can then delete…

Yeah I had to do the same a while back, lesson learned with Elasticsearch. My way was

I had to find the oldest shard and execute the following command to delete the index;

root# curl -XGET http://localhost:9200/_cat/shards  
root# curl -XDELETE http://localhost:9200/ graylog_457/

yeah, but opensearch fails to run properly, just spews errors before it publishes REST API

In trying to do a clean install of 5.0 on Ubuntu 20.04, I see an error when trying to install Elasticsearch 7.10.2:

The repository ‘ stable Release’ does not have a Release file.

I tried to install using OpenSearch, but it seems that there are many references to Elasticsearch in the Graylog config file that must be somehow satisfied.

I’ve also posted to the Elasticsearch forum on the repo issue, but maybe someone here has overcome this issue.

Edit: Elasticsearch tells me that to install this specific version, it must be manually installed. I’ll try that later today.

Edit 2: that did the trick, I was able to get 5.0 up and running. I would suggest that the instructions for Elasticsearch be modified to show a manual installation.

Since I had the chance, I decided to try it on Ubuntu 22.04 with MongoDB 6.0 and Elasticsearch 7.10.2. Time to find some inputs!


Questions regarding the docs:|_____0

Please add link to “Upgrading to Graylog 5.0.x”|Installing%20Graylog|_____0

Here you write that only RHEL 9 is supported - RHEL 7 or 8 is not mentioned.|Upgrade%20Notes%20by%20Version|_____15

But on the Upgrade Notes I read that support for RHEL 6 is dropped. Does that mean that RHEL 7 and 8 is still supported? One of both pages need an edit I think.

We run GL on HyperV
GL5 requires Mongo5+
Mongo5+ requires AVX cpu extensions
HyperV does not provide AVX (VMWare apparently can)
Result = you can’t run GL5+ on HyperV anymore.

This kills you in HyperV as well.

Sure does, were looking at options :frowning_face:

1 Like

Two day trying to install graylog, because mongodb doesn´t works, after install version 5 of mongo i put systemctl status mongod and the output is:
root@santifernvm01:/etc/apt# systemctl status mongod
● mongod.service - MongoDB Database Server
Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Mon 2022-12-19 14:21:46 CET; 29min ago
Process: 3208 ExecStart=/usr/bin/mongod --config /etc/mongod.conf (code=killed, signal=ILL)
Main PID: 3208 (code=killed, signal=ILL)
CPU: 7ms

Dec 19 14:21:46 santifernvm01 systemd[1]: Started MongoDB Database Server.
Dec 19 14:21:46 santifernvm01 systemd[1]: mongod.service: Main process exited, code=killed, status=4/ILL
Dec 19 14:21:46 santifernvm01 systemd[1]: mongod.service: Failed with result ‘signal’.

What is the problkem. Virtualboc 2 CPU 4g RAM debian 11 bullseye… please help meeeeeeeeeeeeeeeeeeeeeeeeeeee

I’m assuming you didn’t upgrade to mongo 5.0 from an unsupported version (lower than 4.4.1) if you did you should roll back and follow their upgrade path. For example, if you were on mongodb 4.2 you must upgrade to 4.4.18, then upgrade to 5.0 and then if you want upgrade to 6.0 as this is the latest supported version on graylog 5.0

Between each upgrade, you should run this command in mongo shell and make sure the compatibility version matches the version currently installed or it won’t start:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

That command will give you the current compatibility level and should match the version currently installed, if it doesn’t then you have to run the following command (replace 5.0 with the current version):

db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )

After that you can perform the upgrade following mongodb documentation.

Let me know if that was it, but without logs or config files I cannot help you further.