// the find
google/mtail
extract internal monitoring data from application logs for collection in a timeseries database
mtail runs alongside your application, tails its log files, and extracts metrics by running small programs you write in its own DSL. It then exposes those metrics via Prometheus, StatsD, collectd, or Graphite. The target audience is ops teams working with legacy or third-party software that logs but doesn't instrument itself.
The DSL is genuinely well-designed — it compiles to bytecode and runs in a VM, so programs are safe to hot-reload without restarting the process. The toolchain is complete: parser, type checker, optimizer, and a formatter (mfmt) and linter (mgen) are all included. OSS-Fuzz coverage on the compiler is a meaningful commitment to correctness that most similar tools skip. The example library covers real-world formats (Apache, MySQL slow queries, ntpd, postfix) and doubles as working integration tests.
The DSL is another language to learn and maintain — your log parsing logic lives in .mtail files that aren't Go, aren't regex, and aren't widely understood outside this project, which is a hiring and onboarding liability. Windows support exists in theory but the test suite has explicit unix-only gates on many integration tests, so expect rough edges there. Metric cardinality control is primitive; it's easy to accidentally create high-cardinality label sets from log fields with no built-in safeguards. Last meaningful activity was March 2026 but the pace has been slow for a while, and with Google's track record on infrastructure tooling, long-term maintenance is a real concern.