What Illuminate content packs add to Graylog and when teams need them
Illuminate content packs help when logs from common sources arrive parsed in different ways and you want one schema before you write searches and alerts. Web servers, Linux audit records and firewalls each name the same fact differently, so a query for source addresses or failed requests can miss events. Graylog Illuminate is a collection of pipelines, parsing rules and lookup tables that normalizes these logs to the *Graylog Information Model* (GIM), the common field schema Graylog uses across packs. Before you build a parsing pipeline from scratch, check whether a pack already covers the source, because the pack carries the field mapping work with it.
Graylog Open includes only four packs: Apache Web Server, Linux Auditbeat, NGINX and pfSense. If your intake is limited to those sources, you can use the packs without an Enterprise or Security license, and the decision is mostly about whether the normalized fields match the searches and event definitions you plan to run. If you have other sources, such as cloud services, endpoint tools or other firewalls, confirm with Graylog which packs your edition unlocks before you design around them, since the wider range depends on the license you hold.
Plan the order of work before you configure any input. Graylog recommends enabling the matching Illuminate content pack before you set up the input, which avoids duplicate entities. Check the Graylog Illuminate documentation for the pack versions that match your Graylog release, and test each pack against a sample of real messages in a non-production stream. Review which fields the pack writes, which existing pipeline rules it may overlap with, and who owns updates to the pack when Graylog releases new versions.
Which content pack fits which log source and edition
This table compares the four Illuminate content packs available on Graylog Open with the wider catalog reserved for Enterprise and Security. Read each row as a log source, the edition that unlocks its pack, and the situation where it fits best. Confirm the full Enterprise and Security catalog in the Illuminate documentation and your licensed product before you plan around a specific pack.
| Log source | Edition needed | When it fits |
|---|---|---|
| Apache Web Server | Graylog Open | Web servers that write access and error logs and need requests normalized to the Graylog Information Model for search and dashboards |
| NGINX | Graylog Open | Reverse proxies and web front ends where you want HTTP fields parsed consistently with other web sources |
| Linux Auditbeat | Graylog Open | Linux hosts shipping Auditbeat events where you need file, process and user activity mapped to shared fields |
| pfSense | Graylog Open | Firewall and gateway firewall logs where you need traffic and rule events normalized for network searches |
| Wider Illuminate catalog (other sources) | Graylog Enterprise or Graylog Security | Additional vendor and platform sources beyond the four open packs; confirm the exact list in the Illuminate docs and your licensed product |
| Packs needed for security detections | Graylog Security | Teams that plan to rely on Security content such as prebuilt detections; confirm which Illuminate packs map to those features before you commit |
| Sources without a matching pack | Graylog Open | Custom applications or devices with no pack; build your own pipeline rules and map fields to the Graylog Information Model yourself |
Enabling an Illuminate pack before configuring its input
This sequence confirms the license, matches an Illuminate pack to a log source, enables the pack before its input, and verifies normalized fields in search. It produces a source whose logs arrive in Graylog Information Model fields without duplicate entities. Each step closes with a check and a rollback path.
Confirm edition and license for the pack
Confirm which Graylog edition your organization runs and which Illuminate packs that license covers. Graylog Open includes the Apache Web Server, Linux Auditbeat, NGINX and pfSense packs, while Enterprise and Security licenses open a wider range. Ask the platform owner to verify the license on the Graylog server before you plan the source. Done when you have written confirmation of the pack you need and the license that covers it.
Match the pack to the source
Identify the log source you plan to onboard and select the Illuminate pack built for it, such as the NGINX pack for NGINX access logs on Graylog Open. Check that the pack targets the same product and log format your source emits, and note the source version. The Graylog Illuminate documentation describes how packs normalize logs to the Graylog Information Model. Done when the pack name, source and log format are recorded in the change ticket.
Install and enable the pack first
From the Illuminate content in the Graylog web interface, install the matching pack and enable it before you create any input for that source. Graylog recommends this order to avoid duplicate entities, which can appear when a pack and a manually created input both define the same objects. Let the pack's pipelines, parsing rules and lookup tables appear in the system before you continue. Done when the pack shows as installed and enabled and its pipelines are listed.
Configure the input for the source
Create the input that receives the source's logs, using the protocol the source sends, such as syslog or Beats. Set the port, transport and bind address to match what the source owner configured, and confirm each setting with that owner. Follow the Graylog inputs documentation for the options of your input type. Done when the input shows as running on the node or nodes you expected.
Send test events from the source
Generate a small, known set of events on the source, such as a few requests to a test web server or a login on a test host, so you know what should arrive. Record the time and the content of each event. Confirm that the messages reach Graylog on the new input and land in the stream or index set you planned. Done when each test event appears in search with the timestamp you recorded.
Verify parsed fields in search
Open search and filter to the test events. Check that the fields the pack normalizes to the Graylog Information Model contain the values from your test events, and that no unexpected fields appear. Compare several parsed values by hand against the raw message. Done when every expected field is populated for each test event and no required field is empty.
Confirm pipeline matches and single entities
Use the pipeline views available in your Graylog version to check that the pack's rules matched your test messages. Then review the inputs, streams, pipelines and lookup tables for duplicate names, which would indicate an entity created by an earlier input or manual setup. Done when each test message shows the expected pipeline match and each pack entity appears once.
Record the rollback path
Write down how to reverse the change: stop or remove the input, disable the pack, and delete any pack objects you no longer want. Confirm in the Illuminate documentation and your version's administration guide what disabling a pack changes for messages already parsed. Test the procedure on a non-production instance if one is available. Done when the rollback steps are in the change record and the platform owner has approved them.
How Illuminate rules interact with your own pipelines and streams
The main risk with Illuminate content packs is that their pipeline rules run alongside the processing pipelines and stream rules you already have, so the order in which messages pass through each stage decides the result. A custom rule that rewrites a field before a pack rule parses the message can change what the pack sees, and a pack that parses the same raw data as one of your own rules can produce duplicate or conflicting fields. Before you enable a pack, export your current pipeline definitions and list which pipelines are attached to which streams, then write down the order in which messages will reach each one. Confirm that order in your own environment by checking a sample of messages after enabling the pack, rather than assuming the pack's rules run first.
Graylog's inputs documentation recommends enabling the matching Illuminate content pack before you configure the input, which avoids duplicate entities. If you already have an input running, plan a short review: check whether the input's existing extractors, stream rules or pipeline rules already parse the same fields the pack normalizes to the Graylog Information Model. Decide, for each overlapping source, whether your own rule or the pack's rule should own the field, and remove or narrow the other one. Keep a change record for each decision, because a later pipeline edit by another team can silently reintroduce a duplicate parse.
Stream routing decides which messages reach which pipelines at all, so it should be reviewed together with the pack. Confirm that the streams feeding a pack carry only the log types the pack is built for, and that no catch-all stream sends unrelated messages through the same rules. Routing design is a separate topic in this guide, so treat this check as a prerequisite rather than a full design exercise. Confirm the pack's current rule list and the rule conditions in your Graylog version, since packs change between releases.
What to confirm before relying on Illuminate packs
An Illuminate content pack only normalizes logs correctly when several details in your environment match what the pack expects. The cards below cover the version, license, source format, lookup data and downstream field names to confirm before you rely on a pack's output.
Graylog version in use
Confirm which Graylog release your nodes run before you install or enable a pack. The current documentation covers version 7.2, and pack behavior can differ between releases. Check the release you run against the compatibility matrix, and plan any move to a newer release so the pack's parsing rules and pipeline functions are tested on that version first. Ask the pack owner or Graylog which release the pack was validated against.
License tier and pack availability
Graylog Open includes only some packs, so confirm whether the pack you need is one of them before planning around it. Enterprise and Security tiers add access to a wider range. Confirm your license covers the pack on every node, and ask your Graylog contact how a license change affects packs already installed.
Source log format version
Confirm the exact version of the source product, such as the Apache Web Server, NGINX, pfSense or Linux Auditbeat release, and the log format it writes. Parsing rules written for one format may miss fields or misread values after the source changes its output. Capture a sample from production and run it through the pipeline in a test environment before you enable the pack.
Lookup table data currency
Some pack enrichment depends on lookup tables that map values to labels or categories. Confirm whether those tables are current for your environment, who owns updates, and how often they change. Stale mappings produce wrong enrichment without any error, so record an owner and a review schedule for each table the pack uses.
Field names used by dashboards and alerts
Normalized fields from the Graylog Information Model may differ from the raw field names your existing dashboards, searches and event definitions use. Export the field names those assets reference and compare them with the pack's output. Plan mappings or updates before enabling the pack, so alerts do not silently stop matching after the change.
Input and pack order
Graylog recommends enabling the matching Illuminate pack before you configure its input, which avoids duplicate entities. Confirm the order in your change plan, especially where inputs are already running. Check for existing rules or pipelines that also parse the same messages, since two parsers on one stream can overwrite each other's fields.
Questions teams ask before enabling Illuminate
Which license do I need to use Illuminate content packs?
Graylog Open includes only a small set of Illuminate content packs: Apache Web Server, Linux Auditbeat, NGINX and pfSense. Graylog Enterprise and Graylog Security users get access to a wider range of packs, so any other source you want normalized will require one of those paid editions. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, per the Graylog pricing page. Both paid editions have a minimum of 10 GB per day or 100 Graylog Compute Units and are licensed on processed data, with no per-user or per-device fees. Confirm the current pack list for your edition with Graylog before you plan around a specific source.
How much effort does an Illuminate pack rollout take?
Effort depends mostly on how many log sources you are onboarding, how much of your data already flows through custom parsing, and how many dashboards, alerts and searches depend on field names you will change. A single well-understood source with no existing custom pipelines is a small change. Several sources that overlap with existing extractors, or that feed alerts, need a review of pipeline order and duplicate entities. Ask any partner for a written breakdown of inventory, testing and cutover work, and confirm whether the quote covers changes to existing dashboards and event definitions.
Can our team enable Illuminate packs without outside help?
Yes, if your engineers already run Graylog and understand its inputs, streams and processing pipelines. Enabling a pack is an administrative step in the Graylog interface, and the main risk lies in sequencing. Graylog recommends enabling the matching Illuminate content pack before configuring an input to avoid duplicate entities. Teams new to Graylog, or those with heavy custom parsing, often bring in outside help for the design and test steps. Decide early which work you will keep in house, and write down the test cases your team will use to sign off each source.
How long does validation take with many log sources?
Validation time grows with the number of sources, the number of distinct log formats per source, and the number of downstream consumers of each normalized field. For each source, check that messages parse into the expected Graylog Information Model fields, that no duplicate inputs or entities were created, and that streams route the messages to the right index sets. Sources that feed alerts or compliance evidence deserve longer checks than informational ones. Ask for the validation plan and the acceptance criteria in writing, and agree on how many sample messages per source the test will cover.
What happens to existing data after a pack is enabled?
Enabling a pack changes how new messages are processed. It does not reprocess messages that are already stored, so historical data keeps the field names and structure it had when it was indexed. This means searches and dashboards that expect the new Graylog Information Model fields may return different results for older time ranges. Plan for this by documenting the cutover date, adjusting saved searches and alert conditions that span it, and deciding whether any historical reprocessing is needed for your reporting. Confirm with Graylog how reprocessing is handled in your edition and version before you rely on it.
What is the Graylog Information Model and why does it matter?
The Graylog Information Model, or GIM, is the common schema that Illuminate uses to normalize logs from different sources. Each pack maps vendor- or product-specific fields into shared fields, so a login event from one system can be searched and alerted on the same way as one from another. This matters most when you run several sources that describe the same activity. It also makes content, such as dashboards and detection rules, easier to reuse. Review the field mappings against your own detection needs, since packs may not cover every field your team relies on.
Do Illuminate packs affect compliance evidence?
They can change what evidence your logs show, so treat them as a change to the controls that depend on log data. Normalized fields may make review easier, but a pack that drops, renames or reshapes fields can break queries that auditors or your own procedures rely on. Record which pack version is enabled, when it was enabled, and what was validated. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification.
How DeployOpen scopes and delivers Illuminate rollouts
DeployOpen plans and implements Graylog inside your own infrastructure, including the Illuminate content packs that normalize logs to the Graylog Information Model. We start by agreeing on which log sources, edition and packs are in scope, then build, test, document and hand over the result. Engagements are fixed-scope, with ongoing support available as a retainer.
How we scope
- Inventory the log sources you need normalized and confirm which have a matching Illuminate content pack.
- Confirm your Graylog edition, since packs beyond the Graylog Open set require an Enterprise or Security license.
- Write the scope, deliverables and timeline into a fixed-scope agreement before any work starts.
How we build
- Enable each matching content pack before its input is configured, to avoid duplicate entities.
- Test parsing pipelines and lookup tables against sample messages from each real source.
- Check that normalized fields match the Graylog Information Model before routing data to streams.
How we hand over
- Document each enabled pack, its source mapping, custom rules and any changes made to packaged content.
- Walk your operators through searches and streams that rely on normalized Information Model fields.
- Deliver a runbook for adding new sources so future packs follow the same review steps.
How we support
- Offer ongoing support and pack updates as a retainer, scoped to your Graylog version and edition.
- Review pack changes when you upgrade Graylog, since parsing behavior can shift between releases.
- Confirm with you which packs and rules your license covers before each support cycle begins.
