[20:00:54] <hashar>	 herron: thank you for the addition of Prometheus / alarms etc for arclamp1001 :] (was T348756)
[20:01:06] <herron>	 hashar: you bet!
[20:01:09] <hashar>	 and if you or cwhite know, I am wondering which version of OpenSearch dashboards we are using
[20:01:17] <hashar>	 I found trace of a 2.6.0 in puppet but I am not sure
[20:02:37] <herron>	 hashar: 2.7.0 
[20:03:06] <hashar>	 great thanks! :-]
[20:03:50] <herron>	 np!
[20:05:30] <hashar>	 and I guess the Dashboards version is tied to the underlying OpenSearch version being used isn't it?
[20:11:57] <cwhite>	 hashar: We keep them synchronized because there's really no reason not to, but the hard version sync is not required according to upstream.
[20:12:01] <cwhite>	 Why do you ask?
[20:13:31] <hashar>	 for my education I guess
[20:13:47] <hashar>	 but really I could use a way to easily add a filter that combines two filters
[20:14:51] <hashar>	 something like `error.message=foobar`  AND  `filename=whatever.php`
[20:15:18] <hashar>	 we currently edit the filter in DSL mode and have to input a bunch of random json payload to achieve the boolean AND
[20:15:33] <hashar>	 s/random json/opensearch json query/
[20:16:07] <cwhite>	 Yes, that is the way I was about to suggest.  Upstream might be interested in an improved filter tool :)
[20:16:11] <hashar>	 so I want to check whether upstream has that in their latest version, if not I will a feature request to upstream 
[20:16:25] <hashar>	 I am too old to write json
[20:16:31] <hashar>	 I wanna click through it :-]
[20:17:15] <hashar>	 else I write a python tool that adds the filter to the object but I feel like I will certainly screw up something on the way
[20:17:15] <cwhite>	 you can have a look at the latest dashboards version on playground.opensearch.org for a peek, though
[20:17:27] <hashar>	 oh
[20:17:51] <hashar>	 that saves from having to install it locally to figure out what is available!! \o/
[20:27:32] <hashar>	 thank you cwhite ! :)
[20:27:47] <cwhite>	 <3
[20:41:23] <hashar>	 I have one last unrelated question. We have some MediaWiki logs that are too large and end up being truncated somewhere
[20:41:49] <hashar>	 I can see them under the jsonTruncated channel, and I am wonder what causes it (logstash or a limit in opensearch)
[20:42:02] <hashar>	 and potentially what the threshold is
[20:43:06] <hashar>	 but most probably the issue is to be fixed in mediawiki/core , it sometimes log some full sql query which can be arbitrarily large (for example saving a wikitext to the external storage MySQL).  I filed it as https://phabricator.wikimedia.org/T349140
[20:51:32] <hashar>	 I bet it is syslog
[21:40:53] <cwhite>	 I've dug for the answer to that one a few times and consistently forgot where that truncation occurs.  I'd guess it's between MediaWiki, UDP, and rsyslog, but I'm not 100% sure.
[21:47:04] <herron>	 sounds like 64k udp limit