$ ls blog/

Notes on parsing logs

Field detection, named capture groups, decoder dialects, and the small gotchas that break a parser in production — from the people building LogForge.

• July 5, 2026 groklogstashelasticsearchgraylogdatadogparsing

  Grok is not one language: Logstash, Elasticsearch, Graylog and Datadog compared

  Four tools all say they use "grok," and all four behave differently — pattern libraries, custom-pattern handling, the named-capture default, and Datadog's entirely separate matcher set.

  read →

• July 5, 2026 splunkelasticsearchgraylogdatadogvectorlokiparsing

  One log line, eight SIEMs: what field extraction actually looks like in each

  The same nginx line, expressed as a parser for Splunk, Elasticsearch, Graylog, Datadog, Fluent Bit, Vector, Loki and syslog-ng — and why the field-extraction syntax is different in every one.

  read →

• July 5, 2026 vectorlokiregexre2parsing

  RE2 has no lookahead: why your Vector and Loki regex silently fails

  Go and Rust use RE2, which has no lookaround or backreferences. That is fine until you parse key=value logs whose fields reorder — then the regex you would naturally write is one RE2 refuses to compile. Here is the fix.

  read →

• July 3, 2026 regexgrokwazuhparsing

  Turning a raw log line into a working regex (and Grok, and a Wazuh decoder)

  How field detection turns one log line into a named-capture regex, a Grok pattern, and a Wazuh decoder — and why the same idea is spelled three ways.

  read →