Pith. sign in

REVIEW 3 major objections 6 minor 91 references

Lost in Translation? Converting RegExes for Log Parsing into Dynatrace Pattern Language

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A hybrid rule-based and large-language-model converter raises the share of log-parsing RegExes convertible safely from 1.7% to 73.7%.

desk verdict The 73.7% 'safe' conversion rate is not established: the paper's key NGQ rule has a counterexample, so the headline claim needs rework before it can be trusted. read the letter →

arxiv 2506.19539 v1 pith:JIUSDDVX submitted 2025-06-24 cs.SE cs.AI

Julian Fragner , Christian Macho , Bernhard Dieber , Martin Pinzger This is my paper
classification cs.SEcs.AI
keywords logparsingregularexpressionsDynatracePatternLanguageconversionquantifiersemanticequivalencelargemodeloptimizationmigration
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

REPTILE is a tool for migrating regular expressions (RegExes) used in log parsing into the Dynatrace Pattern Language (DPL), a pattern language whose quantifiers behave possessively rather than with backtracking. The paper's central claim is that a rule-based converter, extended with strategies for recognizing when greedy and lazy quantifiers need no backtracking, raises the share of RegExes that can be converted automatically and safely from 1.7% to 73.7% on a real-world set of 946 RegExes from a retail company. For the roughly 26% it cannot convert safely, the tool still produces a best-effort pattern and highlights the exact fragments needing human review. A second phase uses a large language model to suggest high-level DPL matchers (IP addresses, integers, timestamps, and so on), achieving an average F1-score of 0.91 and Matthews correlation coefficient of 0.92 across five matchers on 23 RegExes from 13 technologies. If these numbers hold, companies migrating between observability platforms can automate most of the tedious, error-prone pattern conversion work.

What carries the argument

The load-bearing mechanism is a set of quantifier-conversion rules built on a single observation: a greedy or lazy quantifier can be replaced by its possessive DPL counterpart without changing the language when backtracking could never affect the outcome. The rules are named strategies for fixed repetition, last position in an alternative, non-intersecting successor (checked by computing intersection non-emptiness), and the special case of a lazy dot-matcher followed by exactly one final matcher, which maps to DPL's lazy-like LD matcher. Validation uses random test-case generation from the RegEx and its complement, and optimization uses a zero-shot-prompted large language model constrained to output JSON suggestions for five selected high-level matchers.

What would settle it

Take any RegEx from the 697 reported as safely converted and construct adversarial strings at the boundary of a quantified matcher's language, for instance strings where the successor matcher could consume a character the quantifier would release under backtracking, or where capture-group contents would change. If even one such string matches the original RegEx but not the converted DPL pattern, or produces different captured values, the safe-conversion claim fails for that case; a cheaper check is to re-run the validation with a larger, coverage-guided sample or a different random seed.

Watch

Extended reading notes

Core claim

The discovery is that practical RegEx-to-DPL conversion is mostly a matter of deciding when a greedy or lazy quantifier can be made possessive without changing the recognized language. REPTILE proves safety for a quantifier when it has fixed repetition, when it is the last matcher in its alternative, when its language does not intersect the language of its next non-optional successor (checked via regular-language intersection), or, for lazy dot-matchers, when the successor is the final matcher. Applying these rules to 946 real-world RegExes, 697 of them (73.7%) convert automatically; the remaining 26.1% receive best-effort conversions with the unsafe fragments flagged. Correctness is checked not by proving language equivalence, because the paper asserts that no DPL-to-DFA conversion algorithm exists, but by generating 1,000 random strings per RegEx from the RegEx and its complement, all 897,000 of which passed. The optimization phase then asks a large language model to propose high-level matchers for pattern fragments, with high precision and recall.

Load-bearing premise

The central claim counts a conversion as safe when it passes 1,000 randomly generated test cases, not when language equivalence is proven, and the formal route via deterministic automata is unavailable because DPL cannot be converted to a DFA, as asserted rather than proven.

Editorial extensions

If this is right

  • Three-quarters of the RegExes in the studied dataset can be converted without human review, so a migration team's remaining work concentrates on the flagged unsafe fragments.
  • Best-effort conversions keep the user in the loop only where needed, with each unsafe fragment highlighted together with the reason, such as an intersecting successor.
  • High-level matcher suggestions arrive with few false positives, with precision of 0.85 or higher for all five matchers, so users can adopt them without re-checking every fragment.
  • The same conversion strategies apply to any target pattern language with possessive quantifier semantics, opening a path beyond the specific platform studied.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A coverage-guided test generator targeting quantifier-release boundaries would likely catch cases that the uniform random sample misses, so the 73.7% figure is best read as an upper bound on provably safe conversions until such tests pass.
  • The non-backtracking safety analysis transfers naturally to converting RegExes into other possessive-semantics pattern languages, which could let future tools reuse the same safety classification.
  • Because the optimization prompt relies on export names and surrounding literals, matcher prediction accuracy may drop for patterns with non-English or generic capture names; this is testable by renaming groups in the 23-pattern benchmark and re-measuring F1.
  • If DPL ever gains a formal semantics or an automata-compilation path, the entire safe-conversion count could be re-verified exactly, shifting the meaning of 'safe' from sample-passing to language equivalence.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents REPTILE, a two-phase approach for converting regular expressions (RegExes) used in log parsing into the Dynatrace Pattern Language (DPL). The first phase is a rule-based AST-to-AST translation, with special strategies for greedy and lazy quantifiers based on a stated observation about disjointness of matcher languages. The second phase uses GPT-4 with a zero-shot prompt to suggest replacements by high-level DPL matchers. The evaluation uses 946 real-world RegExes from a retail company: the paper reports that the fraction of safely convertible RegExes rises from 1.7% to 73.7%, with all 897,000 generated positive and negative test cases passing. A separate evaluation on 23 RegExes from 13 technologies reports average F1-score 0.91 and MCC 0.92 for five high-level matchers predicted by GPT-4.

Significance. If the conversion guarantees were sound, this would be a practically significant contribution: it provides a rare large-scale study of RegEx features used for log parsing, a modular converter design, an LLM-based optimizer with a public dataset and prompt repository, and a transparent testing methodology. The paper is clearly written and the empirical scale is impressive. However, the central guarantee of 'safe' conversion is undermined by an unsound quantifier-conversion rule and by the reliance on random sampling instead of semantic equivalence; the reported numbers are therefore conditional on fixing those issues.

major comments (3)
  1. [§4.2 and §5.1] The Observation in §4.1.1 is false. Let P = (ab)*abc, with u = (ab)* and v = abc. Then L(u) = {(ab)^n | n ≥ 0} and L(v) = {abc} are disjoint, so the stated condition is satisfied. Yet the string 'ababc' is accepted by P: after the greedy (ab)* consumes 'abab', backtracking releases 'ab' so that v matches 'abc'. The possessive version (ab)*+abc consumes 'abab' and then cannot match 'abc', so it rejects. The implementation is even weaker, because intersection is only checked against the first non-optional successor matcher, which in this example is 'a' and is also disjoint from (ab)*. Since Table 3 attributes 1,546 NGQ quantifiers in 386 RegExes to this rule, the unsoundness directly threatens the 73.7% safe-conversion claim. The rule needs a correct sufficient condition (e.g., accounting for suffixes of the quantified subpattern that can serve as prefixes of the remaining pattern), and the evaluation must be redone under that corrected rule.
  2. [§4.2 and §5.1] 'Safe' is defined in §4.2 as passing a fixed number of randomly generated test cases, and the paper itself concedes that such tests cannot formally prove semantic equivalence. Nevertheless, §5.1 concludes that the results 'indicate full semantic congruence'. Randomly generated strings have very low probability of hitting the specific backtracking-sensitive inputs that distinguish a greedy quantifier from a possessive one, as the counterexample in my previous comment shows. To support the central RQ2 claim, either the conversion must be verified by a formal language-equivalence procedure for the supported subset, or the claims must be explicitly limited to 'passed 1,000 sampled test cases' and the term 'safe' must be redefined accordingly.
  3. [§5.2.2, Table 7] The TIMESTAMP evaluation relaxes the correctness criterion: a prediction is counted as a true positive if it is made for any fragment matching a timestamp, even when the default date format is wrong. A wrong format means the optimized DPL pattern will not extract the expected fields from actual logs, so such predictions do not satisfy the all-test-cases-passed criterion used for the other matchers. Because Table 7's averages include this relaxed TIMESTAMP metric, the reported average F1 of 0.91 and MCC of 0.92 are inflated. The TIMESTAMP results should be reported without this exception, or excluded from the averaged metrics.
minor comments (6)
  1. [§4.2] The sentence 'such test cases cannot formally proof semantic equivalence' contains a typo: 'proof' should be 'prove'.
  2. [§7] The phrase 'in it's entirety' should be 'in its entirety'.
  3. [§5.1, §6.1, §8] The percentage of RegExes that receive a best-effort conversion is reported inconsistently: 26.1% in §5.1, 26.5% in §6.1, and 26.3% in §8. These numbers should be reconciled.
  4. [Abstract and §5.2.3] The abstract states 'F1-score and MCC above 0.91', but Table 7 shows DOUBLE with F1=0.83 and MCC=0.84. The claim should explicitly say 'average' across the five matchers, as done in the RQ3 answer.
  5. [§4.2] The assertion that 'no algorithm exists that converts DPL to DFA' is stated without proof or citation. This is a strong claim; it should be rephrased as an observation about the current DPL implementation or supported by evidence.
  6. [§3.2] The text says quantified named capturing groups are 'ignored', but they are listed and counted in Table 2. Please clarify that they are excluded from the conversion strategies while still being counted in the feature frequency study.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the conversion claims are checked against externally generated test strings and external logs, not against REPTILE's own output.

full rationale

The paper's central claims do not reduce to their inputs by construction. The 73.7% safe-conversion figure is a coverage count: REPTILE classifies each quantifier as FGQ/LGQ/NGQ (or lazy equivalents) and the paper counts how many RegExes have no remaining unsupported or unsafe quantifier. The correctness of those conversions is then checked against 1,000 randomly generated strings per RegEx, with positive cases generated from the original RegEx via reregexp and negative cases from its complement via greenery; these generators are external to the converter and do not depend on the DPL output. The paper explicitly concedes in Section 4.2 that such test cases cannot formally prove equivalence, so the 'safe' label is an acknowledged operational definition rather than a hidden restatement of the conclusion. The RQ3 matcher-prediction evaluation is likewise grounded in external data: 23 RegExes and real logs from 13 technologies, with predictions judged by replacing the fragment and executing the pattern on those logs. There are no load-bearing self-citations; the only self-references are the tool's GitHub repository and in-house Dynatrace services, which do not supply any uniqueness theorem or ansatz. The shared dependency on the greenery library for both intersection checking and negative-test generation is a potential common-mode validity threat, but it is not a logical reduction of the result to its own input. Potential concerns such as the Boolean intersection criterion for possessive-quantifier conversion in Section 4.1.1 being unsound for examples like (ab)*abc, or the relaxed TIMESTAMP true-positive rule in Section 5.2.2, are correctness or measurement threats rather than circularity: they do not identify an equation or parameter that is equivalent to its own input by construction.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

No new entities, particles, or forces are introduced. The work is a software engineering tool, so the axioms are engineering assumptions about the correctness of third-party libraries (greenery, reregexp), the semantics of DPL as described, and the representativeness of random test generation. There are no fitted parameters in the conversion algorithm itself; the only free choices are the validation sample sizes, which do not affect the conversion logic but do affect the evidence strength.

free parameters (3)
  • Number of randomly generated test cases per RegEx = 1000
    Chosen by the authors as the validation budget; not fitted to data, but it is an arbitrary threshold that determines the strength of the 'safe' claim.
  • Random sample of RegExes for negative tests = 200
    The authors chose 200 as a 'sufficiently large' random sample for negative test generation, but only 200 of 697 RegExes were validated with negative tests.
  • Limit of positive test cases per RegEx in RQ3 = 1000
    Log entries were randomly sampled and limited to 1,000 for RegExes with more than 1,000 test cases (marked with * in Table 6).
assumptions (4)
  • domain assumption The greenery library correctly checks intersection non-emptiness of regular expressions.
    Used in Section 4.1 and 4.5 to decide NGQ and NLQ conversions; the paper notes greenery has undocumented escaping behavior, so its correctness is not fully verified.
  • domain assumption The reregexp library generates random strings that are representative of a RegEx and its complement.
    Used in Section 4.2 to generate positive and negative test cases; the paper does not analyze the coverage of these generated samples.
  • domain assumption The DPL engine behavior is as described, including possessive quantifiers and no backtracking.
    Stated in Section 2.2.2, based on public documentation and discussions with DPL authors; this is assumed true for the conversion correctness argument.
  • domain assumption Randomly generated test cases are sufficient evidence of semantic equivalence.
    The paper admits in Section 4.2 that generated tests 'cannot formally prove semantic equivalence'; the entire 73.7% safe-conversion claim depends on this assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Lost in Translation? Converting RegExes for Log Parsing into Dynatrace Pattern Language." pith.science (2026). https://pith.science/paper/JIUSDDVX

@misc{pith2026250619539,
  author       = {Pith},
  title        = {Pith review of: Lost in Translation? Converting RegExes for Log Parsing into Dynatrace Pattern Language},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JIUSDDVX}},
  note         = {Machine review of arXiv:2506.19539}
}
read the original abstract

Log files provide valuable information for detecting and diagnosing problems in enterprise software applications and data centers. Several log analytics tools and platforms were developed to help filter and extract information from logs, typically using regular expressions (RegExes). Recent commercial log analytics platforms provide domain-specific languages specifically designed for log parsing, such as Grok or the Dynatrace Pattern Language (DPL). However, users who want to migrate to these platforms must manually convert their RegExes into the new pattern language, which is costly and error-prone. In this work, we present Reptile, which combines a rule-based approach for converting RegExes into DPL patterns with a best-effort approach for cases where a full conversion is impossible. Furthermore, it integrates GPT-4 to optimize the obtained DPL patterns. The evaluation with 946 RegExes collected from a large company shows that Reptile safely converted 73.7% of them. The evaluation of Reptile's pattern optimization with 23 real-world RegExes showed an F1-score and MCC above 0.91. These results are promising and have ample practical implications for companies that migrate to a modern log analytics platform, such as Dynatrace.

Figures

Figures reproduced from arXiv: 2506.19539 by the authors.

Figure 7
Figure 7. Overview of the Reptile approach User 1 2 4 3 it is necessary to identify situations where no backtracking is required. In the following, we present these situations and our conversion strategies. 4.1.1. Greedy Quantifiers We identify three cases where greedy quantifiers do not require backtracking and therefore can be converted to DPL. Fixed Greedy Quantifier (FGQ). The first case of quan￾tifiers without backtracki… view at source ↗
Figure 10
Figure 10. Unsafe greedy quantifier: followed by intersecting character class \w+[a-z] Hello-Muehlviertel! ----- [PITH_FULL_IMAGE:figures/full_fig_p007_10.png] view at source ↗
Figure 11
Figure 11. Unsafe greedy quantifier: followed by optional matcher and character class \w+\s?[a-z] Hello-Muehlviertel! ----- essential, all following ones may be released again. In the quantifier with fixed repetition {x} however, all x characters are essential, and therefore, there is no backtracking, i.e., no characters are released. Last Greedy Quantifier (LGQ). The second case, where no backtracking can happen, is when the … view at source ↗
Figures from the paper (5 more)
Figure 13
Figure 13. Figure 13: Unsafe lazy quantifier: followed by intersecting character class \w+?[a-z] Hello-Lavanttal! -- [PITH_FULL_IMAGE:figures/full_fig_p008_13.png]
Figure 14
Figure 14. Figure 14: Safe lazy quantifier: dot-matcher followed by exactly one matcher .+?! Hello! Zillertal! ------ 4.1.2. Lazy Quantifiers Most strategies for converging greedy quantifiers pre￾sented in the previous section also apply to lazy quantifiers. Fixed Lazy Quantifier (FLQ). As…
Figure 16
Figure 16. Figure 16: , i.e., a "perfect" translation), high-level matchers can still be employed. After this, the defined languages of the REGEX and DPL pattern may differ (right part of [PITH_FULL_IMAGE:figures/full_fig_p009_16.png]
Figure 15
Figure 15. Figure 15: presents two illustrative REGEX examples. Both examples extract an IP port, which can be matched by INT in DPL. Line 2 illustrates a variant that precisely matches one to five digits, which is less than what would be matched by the INT matcher. Line 5 depicts a varian…
Figure 18
Figure 18. Figure 18: shows an example where the escaping of the dot in HTTP\/1.1 is missing. This error remained undetected, as the dot-matcher matches everything, including the desired literal dot. This resulted in an incorrect count of the matcher as dot￾matcher in Section 3, despite it…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

91 extracted references · 73 canonical work pages

  1. [1]

    Zhang, H

    T. Zhang, H. Qiu, G. Castellano, M. Rifai, C. S. Chen, F. Pianese, System Log Parsing: A Survey, IEEE Transactions on Knowledge and Data Engineering 35 (2023) 8596–8614

    2023

  2. [2]

    P. He, J. Zhu, Z. Zheng, M. R. Lyu, Drain: An Online Log Parsing Approach with Fixed Depth Tree, in: 2017 IEEE International Conference on Web Services (ICWS), 2017, pp. 33–40. doi:10.1109/ ICWS.2017.13

    2017

  3. [3]

    Q. Fu, J. Zhu, W. Hu, J.-G. Lou, R. Ding, Q. Lin, D. Zhang, T. Xie, WhereDoDevelopersLog?AnEmpiricalStudyonLoggingPractices in Industry, in: Companion Proceedings of the 36th International Conference on Software Engineering, ICSE Companion 2014, As- sociation for Computing Machinery, 2014, p. 24–33. URL:https: //doi.org/10.1145/2591062.2591175. doi:10.114...

    work page arXiv 2014

  4. [4]

    B.Debnath,M.Solaimani,M.A.G.Gulzar,N.Arora,C.Lumezanu, J. Xu, B. Zong, H. Zhang, G. Jiang, L. Khan, LogLens: A Real-Time LogAnalysisSystem, in:2018IEEE38thinternationalconferenceon distributedcomputingsystems(ICDCS),IEEE,2018,pp.1052–1062

    2018

  5. [5]

    V.-H. Le, H. Zhang, Log Parsing with Prompt-based Few-shot Learning, in: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), 2023, pp. 2438–2449. doi:10.1109/ ICSE48619.2023.00204

    arXiv 2023

  6. [6]

    H.Mi,H.Wang,Y.Zhou,M.R.-T.Lyu,H.Cai,TowardFine-Grained, Unsupervised,ScalablePerformanceDiagnosisforProductionCloud Computing Systems, IEEE Transactions on Parallel and Distributed Systems 24 (2013) 1245–1255

    2013

  7. [7]

    R.Vaarandi,M.Pihelgas, UsingSecurityLogsforCollectingandRe- portingTechnicalSecurityMetrics, in:2014IEEEMilitaryCommu- nications Conference, 2014, pp. 294–299. doi:10.1109/MILCOM.2014. 53

    work page doi:10.1109/milcom.2014 2014

  8. [8]

    Hamooni, B

    H. Hamooni, B. Debnath, J. Xu, H. Zhang, G. Jiang, A. Mueen, LogMine:FastPatternRecognitionforLogAnalytics,in:Proceedings of the 25th ACM international on conference on information and knowledge management, 2016, pp. 1573–1582

    2016

Show all 91 references
  1. [9]

    [Online; accessed 2024- 02-22]

    Splunk Inc., About Splunk regular expressions, https: //docs.splunk.com/Documentation/SCS/current/Search/ AboutSplunkregularexpressions, 2023. [Online; accessed 2024- 02-22]

    2023

  2. [10]

    Zhong, J

    Z. Zhong, J. Guo, W. Yang, T. Xie, J.-G. Lou, T. Liu, D. Zhang, Generating Regular Expressions from Natural Language Specifica- tions:AreWeThereYet?, in:WorkshopsattheThirty-SecondAAAI Conference on Artificial Intelligence, 2018

    2018

  3. [11]

    1477–1478

    A.Bartoli,G.Davanzo,A.DeLorenzo,M.Mauri,E.Medvet,E.So- rio, Automatic Generation of Regular Expressions from Examples with Genetic Programming, in: Proceedings of the 14th annual conference companion on Genetic and evolutionary computation, 2012, pp. 1477–1478

    2012

  4. [12]

    Bartoli, G

    A. Bartoli, G. Davanzo, A. De Lorenzo, E. Medvet, E. Sorio, Auto- matic Synthesis of Regular Expressions from Examples, Computer 47 (2014) 72–80

    2014

  5. [13]

    A.Bartoli,A.DeLorenzo,E.Medvet,F.Tarlao, InferenceofRegular Expressions for Text Extraction from Examples, IEEE Transactions on Knowledge and Data Engineering 28 (2016) 1217–1230

    2016

  6. [14]

    J. E. F. Friedl, Mastering Regular Expressions, 3rd ed., O’Reilly Media, Inc., 2006

    2006

  7. [15]

    Y. Li, S. Li, Z. Xu, J. Cao, Z. Chen, Y. Hu, H. Chen, S.-C. Cheung, TransRegex:Multi-modalRegularExpressionSynthesisbyGenerate- and-Repair, in: 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), IEEE, 2021, pp. 1210–1222

    2021

  8. [16]

    X.Ye,Q.Chen,X.Wang,I.Dillig,G.Durrett,Sketch-DrivenRegular ExpressionGenerationfromNaturalLanguageandExamples, Trans- actions of the Association for Computational Linguistics 8 (2020) 679–694

    2020

  9. [17]

    Q.Chen,X.Wang,X.Ye,G.Durrett,I.Dillig, Multi-modalSynthesis of Regular Expressions, in: Proceedings of the 41st ACM SIGPLAN conference on programming language design and implementation, 2020, pp. 487–502. Fragner et al.:Template by Elsevier Page 16 of 18 Converting RegExes int...

    2020

  10. [18]

    Y. Li, Z. Xu, J. Cao, H. Chen, T. Ge, S.-C. Cheung, H. Zhao, FlashRegex: Deducing Anti-ReDoS Regexes from Examples, in: Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 659–671

    2020

  11. [19]

    J.C.Davis,L.G.MichaelIV,C.A.Coghlan,F.Servant,D.Lee, Why Aren’tRegularExpressionsaLinguaFranca?AnEmpiricalStudyon the Re-use and Portability of Regular Expressions, in: Proceedings of the 2019 27th ACM Joint Meeting on European Software Engi- neering Conference and Symposium o...

    2019

  12. [20]

    L. G. Michael, J. Donohue, J. C. Davis, D. Lee, F. Servant, Regexes are Hard: Decision-Making, Difficulties, and Risks in Programming RegularExpressions, in:201934thIEEE/ACMInternationalConfer- enceonAutomatedSoftwareEngineering(ASE),2019,pp.415–426. doi:10.1109/ASE.2019.00047

    2019

  13. [21]

    Zhang, X

    S. Zhang, X. Gu, Y. Chen, B. Shen, InfeRE: Step-by-Step Regex GenerationviaChainofInference, in:202338thIEEE/ACMInterna- tionalConferenceonAutomatedSoftware Engineering(ASE),2023, pp. 1505–1515. doi:10.1109/ASE56229.2023.00111

    2023

  14. [22]

    Chapman, P

    C. Chapman, P. Wang, K. T. Stolee, Exploring Regular Expression Comprehension, in:201732ndIEEE/ACMInternationalConference on Automated Software Engineering (ASE), 2017, pp. 405–416. doi:10.1109/ASE.2017.8115653

    2017

  15. [23]

    [Online; accessed 2024-02-22]

    Elasticsearch B.V., Grok processor, https://www.elastic.co/guide/ en/elasticsearch/reference/current/grok-processor.html, 2024. [Online; accessed 2024-02-22]

    2024

  16. [24]

    [Online; accessed 2024-02-22]

    Datadog Inc., Parsing, https://docs.datadoghq.com/logs/log_ configuration/parsing/, 2024. [Online; accessed 2024-02-22]

    2024

  17. [25]

    dynatrace.com/docs/platform/grail/dynatrace-pattern-language,

    Dynatrace LLC., Dynatrace Pattern Language, https://docs. dynatrace.com/docs/platform/grail/dynatrace-pattern-language,

  18. [26]

    dynatrace.com/docs/platform/grail/dynatrace-query-language/ commands/extraction-and-parsing-commands, 2024

    Dynatrace LLC., Extraction and parsing commands,https://docs. dynatrace.com/docs/platform/grail/dynatrace-query-language/ commands/extraction-and-parsing-commands, 2024. [Online; accessed 2024-02-22]

    2024

  19. [27]

    Siegfried, P

    G. Siegfried, P. Byrne, M. Bangera, M. Crossley, 2024 Gartner® Magic Quadrant™ for Observability Platforms, Technical Report, Gartner, Inc., 2024

    2024

  20. [28]

    Fitzgerald, Introducing Regular Expressions, O’Reilly Media, Inc., 2012

    M. Fitzgerald, Introducing Regular Expressions, O’Reilly Media, Inc., 2012

    2012

  21. [29]

    S. C. Kleene, Representation of Events in Nerve Nets and Finite Automata, Princeton University Press, 1956, pp. 3–42. doi:doi:10. 1515/9781400882618-002

    1956

  22. [30]

    Chomsky, Three Models for the Description of Language, IRE Transactions on Information Theory 2 (1956) 113–124

    N. Chomsky, Three Models for the Description of Language, IRE Transactions on Information Theory 2 (1956) 113–124

    1956

  23. [31]

    P. Linz, S. H. Rodger, An Introduction to Formal Languages and Automata, Jones & Bartlett Learning, 2022

    2022

  24. [32]

    Moseley, M

    D. Moseley, M. Nishio, J. Perez Rodriguez, O. Saarikivi, S. Toub, M. Veanes, T. Wan, E. Xu, Derivative Based Nonbacktracking Real- WorldRegexMatchingwithBacktrackingSemantics, Proceedingsof the ACM on Programming Languages 7 (2023) 1026–1049

    2023

  25. [33]

    org/, 1997

    P.Hazel,PCRE-PerlCompatibleRegularExpressions, https://pcre. org/, 1997. [Online; accessed 2024-07-10]

    1997

  26. [34]

    Fujinami, I

    H. Fujinami, I. Hasuo, Efficient Matching with Memoization for Regexes with Look-around and Atomic Grouping, in: European Symposium on Programming, Springer, 2024, pp. 90–118

    2024

  27. [35]

    Berglund, F

    M. Berglund, F. Drewes, B. van der Merwe, Analyzing catastrophic backtrackingbehaviorinpracticalregularexpressionmatching, Elec- tronic Proceedings in Theoretical Computer Science 151 (2014) 109–123

    2014

  28. [36]

    dynatrace.com/docs/platform/grail/dynatrace-pattern-language/ log-processing-grammar, 2024

    Dynatrace LLC., Log processing grammar, https://docs. dynatrace.com/docs/platform/grail/dynatrace-pattern-language/ log-processing-grammar, 2024. [Online; accessed 2024-09-14]

    2024

  29. [37]

    Splunk Inc., About the search language, https://docs.splunk.com/ Documentation/SplunkCloud/latest/Search/Aboutthesearchlanguage,

  30. [38]

    [Online; accessed 2024-03-29]

    Splunk Inc., rex, https://docs.splunk.com/Documentation/ SplunkCloud/latest/SearchReference/Rex, 2023. [Online; accessed 2024-03-29]

    2023

  31. [39]

    [Online; accessed 2024-03-29]

    The regexpp authors, regexpp, https://github.com/mysticatea/ regexpp, 2021. [Online; accessed 2024-03-29]

    2021

  32. [40]

    W.Su,R.Li,C.Peng,H.Chen, AlgorithmsforCheckingIntersection Non-emptiness of Regular Expressions, in: Theoretical Aspects of Computing – ICTAC 2023, Springer Nature Switzerland, 2023, pp. 216–235

    2023

  33. [41]

    The greenery authors, greenery, https://github.com/qntm/greenery,

  34. [42]

    M.Almeida,N.Moreira,R.Reis, TestingtheEquivalenceofRegular Languages, in: Electronic Proceedings in Theoretical Computer Science, volume 3, 2009, pp. 47–57. doi:10.4204/EPTCS.3.4

    2009 doi

  35. [43]

    Zhong, J

    Z. Zhong, J. Guo, W. Yang, J. Peng, T. Xie, J.-G. Lou, T. Liu, D. Zhang, SemRegex: A Semantics-Based Approach for Generating Regular Expressions from Natural Language Specifications, in: Proceedings of the 2018 Conference on Empirical Methods in Nat- ural Language Processing, ...

    2018 doi

  36. [44]

    [Online; accessed 2024-04-19]

    2024

  37. [45]

    Neelakantan, P

    T.Brown,B.Mann,N.Ryder,M.Subbiah,J.D.Kaplan,P.Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al., Language Models are Few-Shot Learners, Advances in neural information processing systems 33 (2020) 1877–1901

    2020

  38. [46]

    Fragner, log-regex, https://github.com/fragjulian/log-regex,

    J. Fragner, log-regex, https://github.com/fragjulian/log-regex,

  39. [47]

    OpenAI, GPT-4 Technical Report, arXiv preprint arXiv:2303.08774 (2023)

    2023 arXiv

  40. [48]

    com/reference/design-system/,2024.[Online;accessed2024-04-07]

    DynatraceLLC.,Stratodesignsystem, https://developer.dynatrace. com/reference/design-system/,2024.[Online;accessed2024-04-07]

    2024

  41. [49]

    com/en-us/azure/ai-services/openai/concepts/models, 2024

    Microsoft, Azure OpenAI Service models,https://learn.microsoft. com/en-us/azure/ai-services/openai/concepts/models, 2024. [Online; accessed 2024-05-18]

    2024

  42. [50]

    [Online; accessed 2024-06-17]

    2024

  43. [51]

    dynatrace.com/reference/app-toolkit/, 2024

    Dynatrace LLC., Dynatrace App Toolkit, https://developer. dynatrace.com/reference/app-toolkit/, 2024. [Online; accessed 2024-04-07]

    2024

  44. [52]

    [Online; accessed 2024-05-18]

    The Regex101 community, Regex101 Community Patterns,https: //regex101.com/library, 2024. [Online; accessed 2024-05-18]

    2024

  45. [53]

    [Online; accessed 2024-06-07]

    ChaosSearch Inc., Regex Support, https://docs.chaossearch.io/ docs/regex-support, 2024. [Online; accessed 2024-06-07]

    2024

  46. [54]

    Thereregexpauthors,reregexp, https://github.com/suchjs/reregexp,

  47. [55]

    [Online; accessed 2024-06-07]

    Elasticsearch B.V., Elastic examples, https://github.com/elastic/ examples/tree/master, 2023. [Online; accessed 2024-06-07]

    2023

  48. [56]

    [Online; accessed 2024-03-24]

    Dynatrace LLC., DPL Architect, https://docs.dynatrace.com/docs/ platform/grail/dynatrace-pattern-language/dpl-architect, 2024. [Online; accessed 2024-03-24]

    2024

  49. [57]

    Srinivasan, Sample cloudfront access logs, https://github

    R. Srinivasan, Sample cloudfront access logs, https://github. com/aws-samples/amazon-cloudfront-log-analysis ,2018.[Online;ac- cessed 2024-06-07]

    2018

  50. [58]

    aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html,

    AmazonWebServicesInc.,PublicDNSquerylogging, https://docs. aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html,

  51. [59]

    A. A. Chuvakin, Public Security Log Sharing Site, https:// www.chuvakin.org/and https://log-sharing.dreamhosters.com/,2010. [Online; accessed 2024-05-18]

    2010

  52. [60]

    aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples

    AmazonWebServicesInc.,Flowlogrecordexamples, https://docs. aws.amazon.com/vpc/latest/userguide/flow-logs-records-examples. html, 2024. [Online; accessed 2024-06-07]. Fragner et al.:Template by Elsevier Page 17 of 18 Converting RegExes into Dynatrace Pattern Language

    2024

  53. [61]

    J. Zhu, S. He, P. He, J. Liu, M. R. Lyu, Loghub: A Large Collection of System Log Datasets for AI-driven Log Analytics, in: 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE), IEEE Computer Society, 2023, pp. 355–366. URL:https: //doi.ieeecomput...

    2023

  54. [62]

    [Online; accessed 2024-06-07]

    Pluralsight LLC., Working with AWS VPC Flow Logs for NetworkMonitoring, https://www.pluralsight.com/cloud-guru/labs/ aws/working-with-aws-vpc-flow-logs-for-network-monitoring , 2021. [Online; accessed 2024-06-07]

    2021

  55. [63]

    Lentz, Key metrics for CoreDNS monitoring, https://www

    D. Lentz, Key metrics for CoreDNS monitoring, https://www. datadoghq.com/blog/coredns-metrics/,2023.[Online;accessed2024- 06-07]

    2023

  56. [64]

    [Online; accessed 2024-06-07]

    2024

  57. [65]

    html, 2024

    Amazon Web Services Inc., Amazon S3 server access log format, https://docs.aws.amazon.com/AmazonS3/latest/userguide/LogFormat. html, 2024. [Online; accessed 2024-06-07]

    2024

  58. [66]

    microsoft.com/en-us/azure/ai-services/openai/how-to/fine-tuning ,

    Microsoft, Customize a model with fine-tuning, https://learn. microsoft.com/en-us/azure/ai-services/openai/how-to/fine-tuning ,

  59. [67]

    [Online; accessed 2024- 06-07]

    kyhau, VPC Flow Log examples, https://kyhau.github.io/ aws-notebook/VpcFlowLogs.html, 2021. [Online; accessed 2024- 06-07]

    2021

  60. [68]

    V. M. Glushkov, The abstract theory of automata, Russian Mathe- matical Surveys 16 (1961) 1

    1961

  61. [69]

    Ziadi, J.-M

    D. Ziadi, J.-M. Champarnaud, An optimal parallel algorithm to convertaregularexpressionintoitsglushkovautomaton, Theoretical computer science 215 (1999) 69–87

    1999

  62. [70]

    [Online; accessed 2024-06-07]

    DigitalOcean LLC., How to Customize CoreDNS for Kuber- netes Clusters, https://docs.digitalocean.com/products/kubernetes/ how-to/customize-coredns/, 2024. [Online; accessed 2024-06-07]

    2024

  63. [71]

    [Online; accessed 2024-10-25]

    Coding Assistant, https://prollm.toqan.ai/leaderboard/ coding-assistant, 2024. [Online; accessed 2024-10-25]

    2024

  64. [72]

    B.Ford, Parsingexpressiongrammars:arecognition-basedsyntactic foundation, in: Proceedings of the 31st ACM SIGPLAN-SIGACT symposiumonPrinciplesofprogramminglanguages,2004,pp.111– 122

    2004

  65. [73]

    [Online; accessed 2024-06-12]

    2024

  66. [74]

    J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V. Le,D.Zhou,etal., Chain-of-ThoughtPromptingElicitsReasoningin Large Language Models, Advances in neural information processing systems 35 (2022) 24824–24837

    2022

  67. [75]

    S.Tariq,T.A.Rana, Automaticregexsynthesismethodsforenglish: a comparative analysis, Knowledge and Information Systems (2024) 1–31

    2024

  68. [76]

    J. R. Koza, Genetic Programming as a Means for Programming Computers by Natural Selection, Statistics and computing 4 (1994) 87–112

    1994

  69. [77]

    Bhargava, G

    S. Bhargava, G. Purohit, Construction of a minimal deterministic finite automaton from a regular expression, International Journal of Computer Applications 15 (2011) 16–27

    2011

  70. [78]

    Kumar, A

    A. Kumar, A. K. Verma, A novel algorithm for the conversion of parallel regular expressions to non-deterministic finite automata, Applied Mathematics & Information Sciences 8 (2014) 95

    2014

  71. [79]

    M. Lee, S. So, H. Oh, Synthesizing Regular Expressions from Examples for Introductory Automata Assignments, in: Proceedings ofthe2016ACMSIGPLANInternationalConferenceonGenerative Programming: Concepts and Experiences, 2016, pp. 70–80

    2016

  72. [80]

    Oikawa, R

    M. Oikawa, R. Ierusalimschy, A. Moura, Converting regexes to parsing expression grammars, in: Proceedings of the 14th Brazilian symposium on programming languages, SBLP, volume 10, 2010

    2010

  73. [81]

    Medeiros, F

    S. Medeiros, F. Mascarenhas, R. Ierusalimschy, From regexes to parsing expression grammars, Science of Computer Programming 93 (2014) 3–18

    2014

  74. [82]

    Crosby, Denial of service through regular expressions, USENIX Association, Washington, D.C., 2003

    S. Crosby, Denial of service through regular expressions, USENIX Association, Washington, D.C., 2003

    2003

  75. [83]

    J.Kirrage,A.Rathnayake,H.Thielecke,Staticanalysisforregularex- pressiondenial-of-serviceattacks, in:J.Lopez,X.Huang,R.Sandhu (Eds.), Network and System Security, Springer Berlin Heidelberg, Berlin, Heidelberg, 2013, pp. 135–148

    2013

  76. [84]

    X. Wang, S. Gulwani, R. Singh, FIDEX: Filtering Spreadsheet Data using Examples, ACM SIGPLAN Notices 51 (2016) 195–213

    2016

  77. [85]

    Q. Chen, A. Banerjee, Ç. Demiralp, G. Durrett, I. Dillig, Data extraction via semantic regular expression synthesis, Proceedings of the ACM on Programming Languages 7 (2023) 1848–1877

    2023

  78. [87]

    6425–6431

    J.-U.Park,S.-K.Ko,M.Cognetta,Y.-S.Han, SoftRegex:Generating Regex from Natural Language Descriptions using Softened Regex Equivalence, in: Proceedings of the 2019 conference on empirical methodsinnaturallanguageprocessingandthe9thinternationaljoint conferenceonnaturallanguagep...

    2019

  79. [88]

    C.Hahn,F.Schmitt,J.J.Tillman,N.Metzger,J.Siber,B.Finkbeiner, Formal Specifications from Natural Language, arXiv preprint arXiv:2206.01962 (2022)

    2022 arXiv

  80. [91]

    Wüstholz, O

    V. Wüstholz, O. Olivo, M. J. Heule, I. Dillig, Static detection of dos vulnerabilities in programs that use regular expressions, in: Tools and Algorithms for the Construction and Analysis of Systems: 23rd International Conference, TACAS 2017, Held as Part of the European Joint...

    2017

  81. [2017]

    [Online; accessed 2024-03-29]

    2024

  82. [2018]

    [Online; accessed 2024-04-14]

    2024

  83. [2024]

    [Online; accessed 2024-02-22]

    2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.