before the
> backlog has become shorter (Q4+ 2015 I guess).
>
> Sorry I have no better answer, but you see yourself what all is going
> on and I really need to make sure I can follow at least the bare
> essentials.
>
> Rainer
>
> 2015-06-04 5:53 GMT+02:00 singh.janmejay :
>
Will merge master.
On Thu, Jun 4, 2015 at 2:15 PM, Rainer Gerhards
wrote:
> 2015-06-04 10:41 GMT+02:00 singh.janmejay :
>> Cool, thanks, I'll start using it then.
>
> Note that there was a problem if empty lines were present. Patch is
> available on github and also merged
Ref-count increment is not required because callers are supposed to
pass exclusive ownership while setting value of a key. What you are
seeing is result of bad-usage (where caller probably free'ed up the
json_object after setting it as value of some key).
To understand this better, look at some ca
Once I have a little bit more time, I'll go through the thread and try
to help find the offender.
On Thu, Jun 11, 2015 at 10:16 AM, singh.janmejay
wrote:
> Ref-count increment is not required because callers are supposed to
> pass exclusive ownership while setting value of a key. W
hoose to fix it, _please do write a test to cover the bug_, and run
tests with valgrind before applying the fix to prove to yourself that
it is indeed broken.
On Thu, Jun 11, 2015 at 10:18 AM, singh.janmejay
wrote:
> Once I have a little bit more time, I'll go through the thread and try
>
Its easy, I remember missing it too :-)
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Jun 11, 2015 3:40 AM, "Micah Yoder" wrote:
> On 6/9/15 2:05 PM, David Lang wrote:
>
> > This is already
The foreach assuming json_object shouldn't be a problem, because it
checks for the same before invoking the loop. All I can commit to is I
can re-look at it once I have some time at hand.
Which version of json-c are you using?
On Fri, Jun 12, 2015 at 1:28 AM, David Lang wrote:
> Just a note that
ES uses worker-pool for indexing(there is a worker-pool for
bulk-indexing too). Prioritizing approach may not be easy, and
possibly a little dangerous too, but sizing that thread-pool is
definitely easy. Just size it to your need and it'll shape the
batch-size optimally when under pressure (like Da
Sorry for the delay, here it is: https://github.com/rsyslog/rsyslog/pull/410
On Tue, May 26, 2015 at 7:20 PM, singh.janmejay
wrote:
> Ok, rand(max) it is then.
>
> --
> Regards,
> Janmejay
>
> PS: Please blame the typos in this mail on my phone's uncivilized soft
>
Do we recommend using stunnel?
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Jul 16, 2015 4:04 AM, "Saurabh Shukla" wrote:
> Hi David,
>
> Thanks for the detailed explanation. I understand t
t; 2015-07-16 8:21 GMT+02:00 singh.janmejay :
> > Do we recommend using stunnel?
>
> no, because it increases message loss potential. What's the problem with
> GnuTLS?
>
> Rainer
> >
> > --
> > Regards,
> > Janmejay
> >
> > PS: Please blame the typos
I will have a quick look at it once I get to work. But can't spend too much
time on it today. If it's too involved, I'll be able to help only by end of
this month.
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assis
Write a test(see mmnormalize tests) and run with valgrind.
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Aug 19, 2015 1:18 PM, wrote:
> Hello,
> I wrote a new rsyslog mm-modul and now I want
What is the effect of loading a module multiple times? Two variants:
- What would happen if its loaded with exactly the same config-params?
- What would happen if config params are changed?
--
Regards,
Janmejay
http://codehunk.wordpress.com
___
rsyslo
cond time.
>
> 2015-09-14 13:25 GMT+02:00 singh.janmejay :
> > What is the effect of loading a module multiple times? Two variants:
> >
> > - What would happen if its loaded with exactly the same config-params?
> > - What would happen if config params are
Oh, I sent a PR for this. I ran into this yesterday.
On Wed, Sep 23, 2015 at 11:38 AM, Rainer Gerhards
wrote:
> 2015-09-23 7:10 GMT+02:00 chenlin rao :
>> Hello all:
>> I try to upgrade from 8.11.0 to 8.13.0, but got configuration parse
>> fail. I search the github issue and find that this fa
Rainer/David,
Exactly how much of lookup_table functionality is implemented?
What can I not do with it? (you mentioned something about single table
in this thread, can you please elaborate?).
On Tue, Mar 31, 2015 at 7:23 PM, Rainer Gerhards
wrote:
> 2015-03-31 15:46 GMT+02:00 :
>> Hi,
>> Do yo
I implemented what currently is there. It should be
> relatively solid with probably some minor glitches. It provides the code
> functionality as far as I remember.
>
> Rainer
>
> Sent from phone, thus brief.
> Am 29.09.2015 20:07 schrieb "singh.janmejay" :
&
quot;Rainer Gerhards" wrote:
> 2015-09-29 20:58 GMT+02:00 singh.janmejay :
> > Sweet, plan on playing with it tomorrow.
>
> If you have verified that the current functionality works fine after
> your patch, I wouldn't object if you modify the doc to tell the world
>
grow or reduce sometimes, so maybe this has
> something do with it (or the processing delay).
>
> regards
> Chris
>
>
> -Ursprüngliche Nachricht-
> Gesendet: Donnerstag, 01 Oktober 2015 um 10:57:37 Uhr
> Von: christopher.ra...@web.de
> An: "singh.ja
Yes, if you build off master, that problem should go away (if it was due to
lookup-table).
On Thu, Oct 1, 2015, 7:00 PM Rainer Gerhards
wrote:
> 2015-10-01 15:14 GMT+02:00 singh.janmejay :
> > If you can share output of all thread backtrace we can confirm if this
> > is the c
file (save of value)
> Arround line 243 of lookup.c file (search in lookuptable fails, so return
> nomatch value.
>
>
> regards
> Chris
>
>
> > Gesendet: Donnerstag, 01. Oktober 2015 um 16:57 Uhr
> > Von: "singh.janmejay"
> > An: rsyslog-users
>
; > ready to take a risk.
> > >
> > > If there is sufficient interest, we can consider officially adding
> > > this feature to the January 8.15 release iff it is ready by then.
> > > @janmejay: please let me know if you would like to continue with your
> >
Let us ship a full implementation in 8.14, let us not remove it.
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 6, 2015 1:19 PM, "singh.janmejay" wrote:
> How
Ok. But we'll have to keep merging master into master-insecure going forward.
Im ok working on it off any branch.
On Tue, Oct 6, 2015 at 3:14 PM, Rainer Gerhards
wrote:
> 2015-10-06 9:51 GMT+02:00 singh.janmejay :
>> Let us ship a full implementation in 8.14, let us not remove it.
Hi,
I am working on support for stats with dynamic-name. This comes handy
in situations where metric-name is dependent upon value of a certain
attribute of the message.
Say, for a central log-aggregation service, its valuable to know what
is inbound message-count distribution across application-c
nce (lockless handling of
increment). So it will be governed by impstat schedule. May be I
should change name to better name (equivalent of
purge_known_keys_after_they_have_been_reported_N_times).
On Tue, Oct 6, 2015 at 4:30 PM, David Lang wrote:
> On Tue, 6 Oct 2015, singh.janmejay wrote:
>
ding more functionality. And make sure that everything works smooth
> in all use cases. While anything else may take care for some use
> cases, I fear we may get too fragmented. At least this is what I
> learned in the past months discussions.
>
> Anyone else?
>
> Rainer
>
&g
015-10-06 18:04 GMT+02:00 singh.janmejay :
>> Rainer,
>>
>> I see this as something completely outside the scope of variables.
>> Building stats collector over variables is possible, but then we are
>> then talking about a general purpose language which allows buil
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 6, 2015 10:32 PM, "David Lang" wrote:
>
> On Tue, 6 Oct 2015, singh.janmejay wrote:
>
>> It is poss
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 7, 2015 3:26 AM, "David Lang" wrote:
>
> On Wed, 7 Oct 2015, singh.janmejay wrote:
>
>> --
>> Regard
It'll support dynamic-key, so any property will work.
On Wed, Oct 7, 2015 at 2:38 PM, chenlin rao wrote:
> I hope there is a stats about metrics based on $programname, $severity,
> $fromhost-ip etc, extends the ruleset(impstats).
>
> 2015-10-07 16:19 GMT+08:00 singh.janmejay :
&
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Oct 7, 2015 11:25 PM, "David Lang" wrote:
>
> On Wed, 7 Oct 2015, singh.janmejay wrote:
>
>> --
>> Re
t; 2015-10-08 8:30 GMT+02:00 singh.janmejay :
> >> Similarly, when one thread goes to output the stats, you need to lock
> > them so that there isn't a lost increment between the time that you read
> > the stat and the time you zero it.
> >
> > No, this involves
Yep, makes sense. I second your opinion, absolute consistency between
metrics is not that valuable.
On Thu, Oct 8, 2015 at 8:57 PM, Rainer Gerhards
wrote:
> 2015-10-08 17:19 GMT+02:00 singh.janmejay :
>> Did you mean it's not atomic across different metrics? That I think should
&g
you are thinking of, and
> atomic ops can't operate on all sizes of data (for example, 32 bit systems
> probably can't update a 64 bit value atomically)
We should eventually move to thread-level accumulators for all metrics
(static or dynamic).
>
> David Lang
>
>
>
gt; branch. Then I'll remove the lookup table code, so that the code base
>>> > matches the documentation. I really don't want to create a general
>>> > principle here that we need to create CVEs (and patched) for something
>>> > that was just add
Will cross-reference in the kill-feature PR.
On Tue, Nov 3, 2015 at 7:37 PM, singh.janmejay wrote:
> Sorry for the delay. Here is the PR:
> https://github.com/rsyslog/rsyslog/pull/578
>
> On Tue, Nov 3, 2015 at 6:02 PM, Rainer Gerhards
> wrote:
>> 2015-11-03 12:54 G
nchmarking both we'll be in a better
position to decide which one should be kept.
On Fri, Oct 9, 2015 at 3:20 AM, singh.janmejay wrote:
> On Thu, Oct 8, 2015 at 11:07 PM, David Lang wrote:
>> Atomic ops are actually rather expensive (almost as expsnsive as full
>> locks).
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Nov 21, 2015 3:52 AM, "David Lang" wrote:
>
> by default, mmnormalize only parsed $msg, it has an option to let you
parse anything else. I posted
ote destination.
if (not reload_lookup_table("foo")) then {
action(type="omfile"...)
}
Functionally, this is all that matters.
Have a look at PR(comments) for details (backward compatibility issue etc).
On Tue, Nov 3, 2015 at 7:37 PM, singh.janmejay wrote:
> Will cross-reference in t
uot;, "reload_failed")
}
On Thu, Nov 26, 2015 at 8:16 PM, singh.janmejay
wrote:
> Resurrecting this thread for a discussing a deviation from old
> lookup_table proposal.
>
> The PR doesn't include load_lookup_table (a rainerscript statement
> that is supposed to relo
I designed the sparse table type
> is geoip lookup, using a table such as the one provided by MaxMind (some
> for free, some at some costs), this can be a multi GB table that's being
> loaded, so we don't want to halt log processing while the table is loading
>
>
> On Fri, 18 D
will be queries against it
> (from other worker threads is nothing else), and such queries should return
> the data from the old version of the table.
>
> David Lang
>
> On Sat, 19 Dec 2015, singh.janmejay wrote:
>
> Date: Sat, 19 Dec 2015 20:43:41 +0530
>> From: singh
Done.
On Sun, Dec 20, 2015 at 8:52 PM, singh.janmejay
wrote:
> That is already the case.
>
> --
> Regards,
> Janmejay
>
> PS: Please blame the typos in this mail on my phone's uncivilized soft
> keyboard sporting it's not-so-smart-assist technology.
>
>
Does it go parallel to basic_structure or action etc?
And where all should we link it from?
--
Regards,
Janmejay
http://codehunk.wordpress.com
___
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professiona
Also, FYI, I am planning to copy over large portion of doc from
lookup-table proposal.
On Mon, Feb 8, 2016 at 2:59 PM, singh.janmejay wrote:
> Does it go parallel to basic_structure or action etc?
>
> And where all should we link it from?
>
> --
> Regards,
n add link
to a page that talks about the declaration (and explains how it works
etc).
On Mon, Feb 8, 2016 at 5:15 PM, David Lang wrote:
> On Mon, 8 Feb 2016, singh.janmejay wrote:
>
>> Does it go parallel to basic_structure or action etc?
>>
>> And where all should w
I guess everyone is OK with putting it in as a function and linking out to
details.
--
Regards,
Janmejay
PS: Please blame the typos in this mail on my phone's uncivilized soft
keyboard sporting it's not-so-smart-assist technology.
On Feb 8, 2016 7:50 PM, "singh.janmejay"
gt; clause as opposed to a different type of statement? the initial
> lookup-table writeup was done a long time ago, before action() became a
> significant part of the config languange.
>
> David Lang
>
> On Tue, 9 Feb 2016, singh.janmejay wrote:
>
> I guess
those standard things.
>
> we do have a handful of other non-action/input/module statements. The
> parser and global declarations are examples. the only thing that is unique
> in table lookups is the ability to trigger the reload based on runtime
> logic.
>
> David Lang
>
>
Done. PR: https://github.com/rsyslog/rsyslog-doc/pull/215
On Wed, Feb 10, 2016 at 2:31 PM, singh.janmejay
wrote:
> Makes sense.
>
> I'll link the PR here once done.
>
> --
> Regards,
> Janmejay
>
> PS: Please blame the typos in this mail on my phone's unci
Inviting ideas.
Has anyone tried to quantify log-loss (#number of lines lost per day
per sender etc) for a log-store?
Let us consider the following setup:
- An environment has several application nodes. Each app node
hands-over its logs to local Rsyslog daemon(let us call it Ra,
Rsyslog-applicati
The ideal solution would be one that identifies host, log-source and
time of loss along with accurate number of messages lost.
pstats makes sense, but correlating data from stats across large
number of machines will be difficult (some machines may send stats
slightly delayed which may skew aggrega
avior which is accounted for during
measurement).
On Sat, Feb 13, 2016 at 5:13 AM, David Lang wrote:
> On Sat, 13 Feb 2016, singh.janmejay wrote:
>
>> The ideal solution would be one that identifies host, log-source and
>> time of loss along with accurate number of messages lost.
&
This is a bug, here is the fix: https://github.com/rsyslog/rsyslog/pull/863
Workaround(in the meanwhile): Since you are not using dynstats, its
safe to ignore that line (everything it reports is related to dynstats
buckets).
On Wed, Mar 9, 2016 at 9:34 PM, Andrew Davidoff wrote:
> On Tue, Mar 8,
Inline.
On Tue, Mar 22, 2016 at 5:01 AM, David Lang wrote:
> I added this to my configs
>
> # grep -B 1 -A 1 dyn_ /etc/rsyslog.conf
> # custom stats to track in rsyslog
> dyn_stats(name="msgs_per_host" resettable="on" maxCardinality="3000"
> unusedMetricLife="1200")
> dyn_stats(name="msgs_per_edg
How about this: we support a new flag in impstats which allows
json-formatted stats-line to optionally use
encapsulated/wrapped-layout?
impstats(format="json" ...) generates
{"name":"msg_per_host","origin":"dynstats.bucket","z-scribe1r-b":80,"SWEB10":67}
however,
impstats(format="json/w" ...) ge
u
are working with?
On Tue, Mar 22, 2016 at 8:38 PM, David Lang wrote:
> On Tue, 22 Mar 2016, singh.janmejay wrote:
>
>> On Tue, Mar 22, 2016 at 5:01 AM, David Lang wrote:
>>>
>>> I added this to my configs
>>>
>>> # grep -B 1 -A 1 dyn_ /et
.
On Wed, Mar 23, 2016 at 12:32 AM, David Lang wrote:
> On Wed, 23 Mar 2016, singh.janmejay wrote:
>
>> On my cluster, each node (those 66 nodes) have 4 threads for ruleset
>> (it does everything, lognorm based parsing, lookups using loopup
>> table, re_extract, string conca
y.
- enhancing foreach to work with {a: 10, b: 20...}
On Wed, Mar 23, 2016 at 12:26 AM, David Lang wrote:
> On Tue, 22 Mar 2016, singh.janmejay wrote:
>
>> How about this: we support a new flag in impstats which allows
>> json-formatted stats-line to optionally use
>
gt; 0 0 62280 3203132584 2677066400 0 0 132 218 0 0
> 100 0 0
> 0 0 62280 3203912584 2677066800 0 8 203 347 0 0
> 100 0 0
>
>
> things just are not running with it uncommented.
>
> I'm going to send you my config di
It seems mostly idle(off cpu). Have you seen sched:off-cpu backtraces
and backtrace-wise latency?
On Wed, Mar 23, 2016 at 12:51 AM, singh.janmejay
wrote:
> You meant the first one was with "commented out" version right? (you
> said uncommenting edge_relay, so double-checking).
&g
ang wrote:
> On Wed, 23 Mar 2016, singh.janmejay wrote:
>
>> Foreach can only work with arrays as of now. It can't work with
>> objects (key-value pairs). So [{name: ... value: ...}, {..},...] is
>> the only format that will work as of now.
>>
>> We can enhan
edge relays.
>
> David Lang
>
> On Wed, 23 Mar 2016, singh.janmejay wrote:
>
>> Date: Wed, 23 Mar 2016 00:51:18 +0530
>> From: singh.janmejay
>> Reply-To: rsyslog-users
>> To: rsyslog-users
>> Subject: Re: [rsyslog] dynastats problems with user
Makes sense.
..."counters":["a":80,"b":67] won't work, I think you meant
..."counters": [{"a" : 80}, {"b": 67}].
So it boils down to foreach handling object or not.
Thoughts?
On Wed, Mar 23, 2016 at 1:18 AM, David Lang wr
, 2016 1:56 AM, "David Lang" wrote:
> On Wed, 23 Mar 2016, singh.janmejay wrote:
>
> Makes sense.
>>
>> ..."counters":["a":80,"b":67] won't work, I think you meant
>> ..."counters": [{"a" : 80}, {"
proach)
is worse than first-class support (purely because of it using a
round-about way of working).
On Wed, Mar 23, 2016 at 3:01 PM, Rainer Gerhards
wrote:
> 2016-03-22 20:34 GMT+01:00 singh.janmejay :
>> What about wrapDynamicObjects="on|off"? That is required regardless,
ist. Which in
turn requires ways to work with that data-type.
Doesn't it?
On Wed, Mar 23, 2016 at 4:58 PM, singh.janmejay
wrote:
> In-code footprint of foreach enhancement (to handle object in addition
> to array) will be fairly small (I am thinking under 40 lines?).
> Majority of ad
if they have no takers.
On Wed, Mar 23, 2016 at 5:30 PM, Rainer Gerhards
wrote:
> 2016-03-23 12:42 GMT+01:00 singh.janmejay :
>> From variable-management pov, loop as a construct will be required as
>> long we have array, associative-array etc.
>>
>> But logs do hav
Yes, that is the right way to do it.
We should put in work at some point to make it thread-local counters. It'll
be a bigger code-change though.
The current interface that dyn-stats and statsobj(static counters) expose
allow us to ship the change transparently.
It's one of those things that I ev
This is a bug. I'll provide the fix on Monday(or in the worst case in a few
days, in case I don't get a chance to work on this on Monday).
Basically, I was supposed to have a shadow table to mark used counters, and
kill unused counters in next run of metric-ttl-cycle which wasn't present
in first
_per_program.ops_overflow":0,"msgs_per_program.new_metric_add":0,"msgs_per_program.no_metric":0,"msgs_per_
p!
>
> rogram.metrics_purged":0,"msgs_per_program.ops_ignored":0,"msgs_per_program.purge_triggered":0,"msgs_per_tag.ops_overfl
t; David Lang
>
> On Fri, 25 Mar 2016, singh.janmejay wrote:
>
> This is a bug. I'll provide the fix on Monday(or in the worst case in a few
>> days, in case I don't get a chance to work on this on Monday).
>>
>> Basically, I was supposed to have a shadow table to
Rainer
>
> Sent from phone, thus brief.
> Am 25.03.2016 06:21 schrieb "David Lang" :
>
> > As I understand Rainer, go .
> >
> > David Lang
> >
> > On Fri, 25 Mar 2016, singh.janmejay wrote:
> >
> > Makes sense. So final call on for
I run it without forking with daemontools.
On Mar 25, 2016 3:52 PM, "Rainer Gerhards" wrote:
> 2016-03-25 0:56 GMT+01:00 Kane Kim :
> > Our module spawns some threads on initialization and it can't work with
> > damonized rsyslog (only with rsyslog in foreground).
>
> The activate entry point is
't seem to be resetting for me.
>
> David Lang
>
> On Fri, 25 Mar 2016, singh.janmejay wrote:
>
> Well, the bug is metric-ttl ends up killing all metric instead of
>> unused-metrics. This works for resettable counters, but for non-resettable
>> counters it kills
David,
You have resetting turned-off in the config you shared with me. That
would prevent resetting of counters.
On Fri, Mar 25, 2016 at 8:21 PM, singh.janmejay
wrote:
> That is not supposed to happen. Although very unlikely, it may be an
> environment specific bug. Do all dyn-stats test
"msgs_per_edge_relay" resettable="on" maxCardinality="3000"
> unusedMetricLife="1200")
> dyn_stats(name="msgs_per_core_relay" resettable="on" maxCardinality="3000"
> unusedMetricLife="1200")
> dyn_stats(name=
Sorry, I meant and'ed not or'ed.
On Mon, Mar 28, 2016 at 11:02 PM, singh.janmejay
wrote:
> No, this reset mechanism is no different than the mechanism that
> static-counters use. If you turn it off at impstats level, it won't
> reset.
>
> This flag basically sets C
again.
>
> David Lang
>
> On Mon, 28 Mar 2016, singh.janmejay wrote:
>
>> Date: Mon, 28 Mar 2016 23:59:46 +0530
>>
>> From: singh.janmejay
>> Reply-To: rsyslog-users
>> To: rsyslog-users
>> Subject: Re: [rsyslog] another dyn_stats question
>>
>> S
two switches that get ANDed together for
> resetting things? I could see two independent controls, or I could see the
> pstats setting controlling everything, but I don't understand two getting
> ANDed together.
>
> David Lang
>
>
> On Tue, 29 Mar 2016, singh
Makes sense.
We probably don't even need to go as far as compiling. If we haven't tuned
it in significant amount of time, we'll likely have big wins if we just
invest in most significant PGOs.
Compile to C will be hard, because it'll then require compiler and linker.
Many environments will have p
d may manipulate
it with dyn_inc and dyn_dec.
Resettable flag in dyn-stats bucket does the same thing as
resettable-flag in statsobj static-counter.
On Tue, Mar 29, 2016 at 3:13 AM, David Lang wrote:
> On Tue, 29 Mar 2016, singh.janmejay wrote:
>
>> Well, from counter pov, some counters by
(counter) (or do they want it as a perpetual counter).
In our case, the end-user control is very coarse-grained, where one
can either get all counters as perpetual or all as resetting.
On Wed, Mar 30, 2016 at 1:41 AM, David Lang wrote:
> On Wed, 30 Mar 2016, singh.janmejay wrote:
>
>> Cons
this?
For static counters though, the problem still remains. If you want to reset
omkafka resettable counters, but don't want resetting for imudp resettable
counters, as of now we have no way to configure it like that.
On Mar 30, 2016 2:06 AM, "David Lang" wrote:
> On Wed, 30 M
t and not worry about backward compatibility
of its behavior.
On Mar 30, 2016 2:55 AM, "David Lang" wrote:
> On Wed, 30 Mar 2016, singh.janmejay wrote:
>
> Metric owner is the subsystem (action is a perfect example). End-user is
>> author of the config.
>>
>
&
PR created (not complete yet, not ready for merge):
https://github.com/rsyslog/rsyslog/pull/931
Have a quick look to get a feel for namespaced reporting of dyn-stats counters.
On Fri, Mar 25, 2016 at 4:25 PM, singh.janmejay
wrote:
> Cool. Will fix both stats representation and foreach in one
Have opened a PR for this. Will fold it with other changes in the same
area. Here is the PR: https://github.com/rsyslog/rsyslog/pull/931 (not
ready for merge yet)
On Wed, Mar 30, 2016 at 8:01 AM, singh.janmejay
wrote:
> Cool, I'll make dyn-stats bucket resettable flag the only th
Complete, ready for merge.
On Thu, Mar 31, 2016 at 12:54 AM, singh.janmejay
wrote:
> PR created (not complete yet, not ready for merge):
> https://github.com/rsyslog/rsyslog/pull/931
>
> Have a quick look to get a feel for namespaced reporting of dyn-stats
> counters.
>
>
Ready for merge now.
On Thu, Mar 31, 2016 at 12:55 AM, singh.janmejay
wrote:
> Have opened a PR for this. Will fold it with other changes in the same
> area. Here is the PR: https://github.com/rsyslog/rsyslog/pull/931 (not
> ready for merge yet)
>
> On Wed, Mar 30,
We use SolrCloud for accessing last 0 to 4 hours of data(accessed using
banana/silk). Older data is kept on hadoop, fronted by hive, accessed
through either hue(for humans) or hive2 protocol, partitioned by date+hour.
We ingress at an aggregate event rate of ~2M/sec or 7.2B/hr. Event sz
~1.5kb.
On
Will create a separate PR for unused-metric-ttl change. That is not
included in the PR I posted above.
On Fri, Apr 1, 2016 at 1:22 AM, singh.janmejay wrote:
> Ready for merge now.
>
> On Thu, Mar 31, 2016 at 12:55 AM, singh.janmejay
> wrote:
>> Have opened a PR for this. Will
The actual implementation details deviate from proposal page at times. It's
best to use documentation.
At a high level, proposal describes it quite accurately though.
On Apr 4, 2016 7:23 PM, "Christian Ramseyer" wrote:
> Great thanks Rainer, I'll check it out.
>
>
> On 04/04/16 15:38, Rainer Ger
http://www.rsyslog.com/doc/v8-stable/configuration/lookup_tables.html
I think something went wrong with that link, we need to clean-up.
On Tue, Apr 5, 2016 at 1:41 AM, Christian Ramseyer wrote:
> On 04/04/16 21:48, singh.janmejay wrote:
>> The actual implementation details deviate from
This page is the best starting point for all things configuration:
http://www.rsyslog.com/doc/v8-stable/configuration/index.html
On Tue, Apr 5, 2016 at 1:58 AM, singh.janmejay wrote:
> http://www.rsyslog.com/doc/v8-stable/configuration/lookup_tables.html
>
> I think something went w
I have a convention of making loggers slap a special tag "obj@"
where = a key based namespace.
So obj@w3 would have website logs, obj@oms would have
order-management-system logs etc.
I extract the ns, and generate objects in the form: {host: ...,
severity: , obj..x : ..., obj..y: ... }
So al
ng (and some accidental stuff), is it possible that
> it's running into grief if the contents of the variable are not a simple
> word (spaces or other funny characters in the value)?
>
> David Lang
>
> On Wed, 23 Mar 2016, singh.janmejay wrote:
>
>> Date: Wed
h
run regardless of edge and core relay counters being incremented. It
was ~ 45k / sec (but again, neither the load profile, not the machine
is not exactly like yours), so its not apples to apples.
On Fri, Apr 8, 2016 at 12:15 PM, singh.janmejay
wrote:
> It doesn't treat them any different. It
I cooked up this little systemtap script to track cause of off-cpu
latency (with latency quantification). It identifies latencies by
userspace-backtrace, kernel-backtrace and thread-id.
It'll give us very useful data when you see low-TP with
processing-backlog while CPU runs cold.
Run it as $ sud
1 - 100 of 320 matches
Mail list logo
