submit on behalf of @abwaheed
- Added graceful handling of apiserver errors with unexpected responses,
i.e., anything other than 200, 404, or 429. Idea is that apiserver
transient error state will recover. We don't want mmkubernetes to miss
metadata resolution for containers that don't have cached metadata.
During these transient error states, mmkubernetes will provide basic
container file path based resolution of namespace and pod metadata for
new pods whose metadata is not yet cached. After this error state
recovers, mmkubernetes is expected to resume its metadata resolution as
expected.
- Added a unit test case for apiserver return 500 with changes to mock server
- Fixed existing unit test that was failing due to missing expected results file
- Added mmkubernetes unit tests to testbench
- drain librdkafka queues and retry later during rsyslog restart or hup.
- add statsname on per kafka instance for better visibility
- omkafka - count errors related ssl as "errors_ssl"
Brief overview:
TO configure tracking percentile metrics in rainerscript:
User would need to define:
- which percentile to track, such as [p50, p99, etc.]
- window size - note, this correlates directly with memory usage to
track the percentiles.
To track a value, user would call built-in function `percentile_observe()` in their configurations to
record an integer value, and percentile metrics would be emitted every
impstats interval.
The Travis definitions and environments are heavily outdated. Also,
Travis is doing changes to their systems.
This is a good time to disable Travis builds, as everything is
covered by other CI runs as well. We need to reconsider if we
update Travis or keep working within the bounds of the rest of
the CI system. In other words: is Travis still worth it?
When batchmode was used, the templates could not be used to
expand dynrestpath. We are now storing the restpath param
within the batch data if we are in batch mode.
- testbench: Added tests for omhttp dynrestpath param
Testing setting the restpath by template - one with batch mode
and one without batch mode
- When we are in batch mode, and the restpath value changes, the
batch is submitted and reinitialized
closes: https://github.com/rsyslog/rsyslog/issues/4567
This is essentially the same as RSYSLOG_SyslogProtocol23Format with
a better name and a fix to remove the unnecessary LF at the end of
the message.
The different name also enables us to fix the LF issue without
any concern about backwards compatibility.
closes https://github.com/rsyslog/rsyslog/issues/4384
This permits to turn off rsyslog's single-message compression extension
when it interferes with non-syslog message processing (the parser
subsystem expects syslog messages, not generic text)
closes https://github.com/rsyslog/rsyslog/issues/4598
Previously, a single server was used to run all imtcp inputs. This
had a couple of drawsbacks. First and foremost, we could not use
different stream drivers in the varios inputs. This patch now
provides a baseline to do that, but does still not implement the
capability (in this sense it is a staging patch).
Secondly, we now ensure that each input has at least one exclusive
thread for processing, untangling the performance of multiple
inputs from each other.
This is part of the patch series to enable different driver
configurations for imtcp.
see also: https://github.com/rsyslog/rsyslog/issues/3727
tcpsrv is used by multiple other modules (imtcp, imdiag, imgssapi, and,
in theory, also others - even ones we do not know about). However, the
internal synchornization did not properly take multiple tcpsrv users
in consideration.
As such, a single user could hang under some circumstances. This was
caused by improperly awaking all users from a pthread condition wait.
That in turn could lead to some sluggish behaviour and, in rare cases,
a hang at shutdown.
Note: it was highly unlikely to experience real problems with the
officially provided modules.
This patch corrects the situation.
