-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exporter enters high CPU state and stops processing log lines #58
Comments
Config for the instance that enters high CPU state global: |
This sounds like a hard-to-find bug. There are two main parts in As a first step we need to find out which of those parts is the culprit. Could you configure |
I'm seeing the same issue so I tried: But the metric that generally fluctuates around 100-500 new entries per second, the total seems to be getting stalled. memory usage appears to be high so the strings are definitely getting "cached/stored/queued" but not getting matched. Verified there is a full line match for the filter and the message with http://grokconstructor.appspot.com/do/match |
I'd love to reproduce it. Could you post the match and an example line? Maybe if I write a small test that runs the line through the match 500 times/second I can reproduce it. |
The logs are pretty large so I've included a subset (can't attach a file. Can upload elsewhere too): Filters with lower than expected matches:
|
I still cannot reproduce it. I created a
With the Prometheus query Do you have any idea how I could reproduce the error? |
I'm using file as input instead of stdin. Would you recommend using stdin? |
No, I would not recommend it. It's just for debugging. It would be interesting to know if the error persists with |
Used the command After seeing multiple the relevant log messages that should have matched, verified http://grokconstructor.appspot.com/do/match#result detects match on eatch one. But the counter below still showed 0 count:
|
I have a fairly high number of counters and use |
If you see the error with Then you could attach the |
Unable to upload the config with the |
The log file is very small subset of the actual log |
Thanks for the example files. I will create a new release with an updated Oniguruma version, then you patterns should work. However, it will take two weeks. In the meantime, you could either build |
Attempted to run
|
The |
The official golang |
If you want to build with You could have a look at the commands in I currently have limited Internet so I cannot check what's in the |
Makes sense. It'll be easier for me to wait since I don't have permissions to the |
Sorry that it took so long, but I finally found the time to make rel 0.2.8. It uses Oniguruma 6.9.2. |
I have installed 0.28 and am no longer seeing the issue. Thank you for the fix! |
Issue observed with 0.26, 0.27 and source build from master on April 25.
I have configured 3 instances of grok_exporter on CentOS. 2 instances run without issue, but 1 will only export metrics for a few minutes before entering a high CPU state. In high CPU state the exporter still responds to scrape requests. The backlog is growing at 3-4 rows per second. While operating normally, the "bad" instance grok_exporter_lines_processing_time_microseconds_total is < 500 µs, and this metric drops to 0 once the instance enters high cpu state.
What debug information can I collect to help investigate this issue?
The text was updated successfully, but these errors were encountered: