json decoder

[doc dodo]

Hello,

I have rule for this event:

{"method":"POST","path":"/api/graphql","format":"*/*","controller":"GraphqlController","action":"execute","status":200,"time":"2026-07-31T09:03:33.537Z","params":[{"key":"operationName","value":"updatePipelineSchedule"},{"key":"variables","value":"[FILTERED]"},{"key":"query","value":"[FILTERED]"},{"key":"graphql","value":{"operationName":"updatePipelineSchedule","variables":"[FILTERED]","query":"[FILTERED]"}}],"correlation_id":"01KYVPM824XHVHGNXRKMRQ36XM","meta.caller_id":"GraphqlController#execute","meta.feature_category":"continuous_integration","meta.organization_id":1,"meta.remote_ip":"192.168.111.221","meta.user":"eugene.proshchenko","meta.user_id":4,"meta.client_id":"user/4","graphql":[{"complexity":4,"depth":2,"used_fields":["PipelineScheduleUpdatePayload.clientMutationId","PipelineScheduleUpdatePayload.errors","PipelineScheduleUpdatePayload.__typename","Mutation.pipelineScheduleUpdate"],"used_deprecated_fields":[],"used_deprecated_arguments":["PipelineScheduleUpdate.inputs"],"variables":"{\"input\"=>{\"id\"=>\"gid://gitlab/Ci::PipelineSchedule/40\", \"description\"=>\"[FILTERED]\", \"cron\"=>\"0 15 * * *\", \"cronTimezone\"=>\"Europe\", \"ref\"=>\"main\", \"variables\"=>\"[FILTERED]\", \"active\"=>false, \"inputs\"=>[]}}","operation_name":"updatePipelineSchedule"}],"remote_ip":"192.168.111.221","user_id":4,"username":"eugene","ua":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0","queue_duration_s":0.007774,"request_urgency":"low","target_duration_s":5,"json_body_bytesize":573,"json_total_elements":36,"json_max_array_count":1,"json_max_hash_count":8,"json_max_depth":5,"redis_calls":20,"redis_allowed_cross_slot_calls":1,"redis_duration_s":0.002342,"redis_read_bytes":582,"redis_write_bytes":1700,"redis_cache_calls":1,"redis_cache_duration_s":9.5e-05,"redis_cache_read_bytes":4,"redis_cache_write_bytes":107,"redis_db_load_balancing_calls":2,"redis_db_load_balancing_duration_s":0.000237,"redis_db_load_balancing_write_bytes":104,"redis_feature_flag_calls":4,"redis_feature_flag_duration_s":0.000723,"redis_feature_flag_read_bytes":232,"redis_feature_flag_write_bytes":385,"redis_repository_cache_calls":10,"redis_repository_cache_duration_s":0.000825,"redis_repository_cache_read_bytes":68,"redis_repository_cache_write_bytes":459,"redis_sessions_calls":3,"redis_sessions_allowed_cross_slot_calls":1,"redis_sessions_duration_s":0.000462,"redis_sessions_read_bytes":278,"redis_sessions_write_bytes":645,"db_count":23,"db_write_count":2,"db_cached_count":0,"db_txn_count":1,"db_replica_txn_count":0,"db_primary_txn_count":0,"db_replica_count":0,"db_primary_count":23,"db_replica_write_count":0,"db_primary_write_count":2,"db_replica_cached_count":0,"db_primary_cached_count":0,"db_replica_wal_count":0,"db_primary_wal_count":0,"db_replica_wal_cached_count":0,"db_primary_wal_cached_count":0,"db_replica_txn_max_duration_s":0,"db_primary_txn_max_duration_s":0,"db_replica_txn_duration_s":0,"db_primary_txn_duration_s":0,"db_replica_duration_s":0,"db_primary_duration_s":0.012,"db_main_txn_count":0,"db_ci_txn_count":1,"db_main_replica_txn_count":0,"db_ci_replica_txn_count":0,"db_main_count":14,"db_ci_count":9,"db_main_replica_count":0,"db_ci_replica_count":0,"db_main_write_count":0,"db_ci_write_count":2,"db_main_replica_write_count":0,"db_ci_replica_write_count":0,"db_main_cached_count":0,"db_ci_cached_count":0,"db_main_replica_cached_count":0,"db_ci_replica_cached_count":0,"db_main_wal_count":0,"db_ci_wal_count":0,"db_main_replica_wal_count":0,"db_ci_replica_wal_count":0,"db_main_wal_cached_count":0,"db_ci_wal_cached_count":0,"db_main_replica_wal_cached_count":0,"db_ci_replica_wal_cached_count":0,"db_main_txn_max_duration_s":0,"db_ci_txn_max_duration_s":0.019,"db_main_replica_txn_max_duration_s":0,"db_ci_replica_txn_max_duration_s":0,"db_main_txn_duration_s":0,"db_ci_txn_duration_s":0.019,"db_main_replica_txn_duration_s":0,"db_ci_replica_txn_duration_s":0,"db_main_duration_s":0.008,"db_ci_duration_s":0.004,"db_main_replica_duration_s":0,"db_ci_replica_duration_s":0,"path_traversal_check_duration_s":4e-05,"cpu_s":0.082597,"mem_objects":33595,"mem_bytes":2080672,"mem_mallocs":7672,"mem_total_bytes":3424472,"pid":3856610,"worker_id":"puma_3","rate_limiting_gates":[],"db_duration_s":0.01091,"view_duration_s":0.00016,"duration_s":0.07704}

I use next custom rule:

  <rule id="342028" level="3">
    <if_sid>1002</if_sid>
    <match>updatePipelineSchedule</match>
    <regex>active\\\p+false</regex>
    <description>Gitlab pipeline schedules has been deactivated.</description>
  </rule>

and Wazuh server can decode this event:

**Phase 2: Completed decoding.
        name: 'json'

**Phase 3: Completed filtering (rules).
        id: '342028'
        level: '3'
        description: 'Gitlab pipeline schedules has been deactivated.'
        groups: '['local', 'syslog', 'sshd']'
        firedtimes: '1'
        mail: 'False'
**Alert to be generated.

But the event is not generated on the agent.

This block has also been added to the agent configuration:

  <localfile>
    <log_format>json</log_format>
    <location>/var/log/gitlab/gitlab-rails/production_json.log</location>
  </localfile>

Could you help me find the error please?

[Md. Nazmur Sakib]

Hello!

Tried to replicate this. I was also not able to see alerts in the dashboard.

When I checked the Filebeat logs. I noticed there are logs related to a mapping error in Filebeat.

cat /var/log/filebeat/filebeat* | grep -iE "error|warn"

Timestamp:time.Time{wall:0xc29328689d448132, ext:237117813971634, loc:(*time.Location)(0x42417a0)}, TTL:-1, Type:"log", Meta:map[string]string(nil), FileStateOS:file.StateOS{Inode:0x411930c, Device:0x801}, IdentifierName:"native"}, TimeSeries:false}, Flags:0x1, Cache:publisher.EventCache{m:common.MapStr(nil)}} (status=400): {"type":"illegal_argument_exception","reason":"can't merge a non object mapping [data.params.value] with an object mapping"}


You are getting this error as updatePipelineSchedule, [FILTERED], [FILTERED] is a nested object and the filebeat cannot process it.



To resolve this.


Find the data section in the /etc/filebeat/wazuh-template.json file, and add the green-highlighted custom fields to the data properties section:

{

 "order": 0,

 "index_patterns": [

    "wazuh-alerts-4.x-*",

    "wazuh-archives-4.x-*"

  ],

 "settings": {

   ...

  },

 "mappings": {

    "dynamic_templates": [

      {

   ...

 "data": {

   "properties": {

          "params": {

            "type": "object",

            "enabled": false

          },

          "audit": {

            "properties": {

Now load the configuration and restart Filebeat.

sudo filebeat setup -index-management

sudo systemctl restart filebeat

This will make sure that fields start with data.params will not be indexed and create conflict.


This is a test result from my end.



Let me know if this works for you.

[doc dodo]

Hello,

I have cluster docker multi node and I add changes to  wazuh-template.json.

Also I add to docker compose.yml:

      - ./config/wazuh_cluster/wazuh-template.json:/etc/filebeat/wazuh-template.json

and restart cluster.  But after restarting the cluster, changes to the file wazuh-template.json  are deleted. 

The file state returns to its original position:

ls -l | grep json
-rw------- 1 root root            84275 Jan  1  1970 wazuh-template.json

пятница, 31 июля 2026 г. в 16:53:28 UTC+3, Md. Nazmur Sakib:

[Md. Nazmur Sakib]

For this config file to persist even after the configuration changes, you can bind the file to an external config file. Create a Filebeat config file in this folder.

And mount it like this. - ./config/wazuh_cluster/wazuh-template.json:/etc/filebeat/wazuh-template.json:ro

services:

  wazuh.manager:

    image: wazuh/wazuh-manager:4.14.1

    hostname: wazuh.manager

    restart: always

-------------------------

    volumes:

      - wazuh_api_configuration:/var/ossec/api/configuration

  -----------------------------

      - ./config/wazuh_cluster/wazuh_manager.conf:/wazuh-config-mount/etc/ossec.conf

      - ./config/wazuh_cluster/wazuh-template.json:/etc/filebeat/wazuh-template.json:ro

Now the configuration on the wazuh-docker/single-node/config/wazuh_cluster/filebeat.yml should be persisted to /etc/filebeat/filebeat.yml

Check these documents to learn more about Docker volume mounts. https://docs.docker.com/engine/storage/bind-mounts/ https://docs.docker.com/engine/storage/volumes/

Let me know if this works for you.