[07:37:30] I should be sleeping, but I decided to check on commons reindexing.. and of course it failed (on codfw) after 16 hours or so. Here's hoping eqiad pulls through! [10:18:34] dcausse: fyi, I've re-opened T355451, elasticsearch.org is a redirect to elastic.co, we should use the target URL as proposed in the task. (sorry, that should have come as part of the CR review, I'm late) [10:18:35] T355451: Update URLs on MediaWiki:Elastica-desc - https://phabricator.wikimedia.org/T355451 [10:30:07] status update: https://wikitech.wikimedia.org/wiki/Search_Platform/Weekly_Updates/2024-03-08 [10:38:53] hm... totally missed that, thought it was just the http*s* bits [11:07:49] lunch [14:14:51] o/ [15:06:52] dcausse I'm working on Flink alerts in https://gerrit.wikimedia.org/r/c/operations/alerts/+/1009359/4/team-search-platform/cirrus_streaming_updater_test.yaml#7 and was wondering where jobName comes from. Is it the same value as the output of `kubectl get flinkdeployments.flink.apache.org -o yaml | grep jobName`? [15:07:39] * Trey314159 hates deleting failed indexes in production... so much 𝒻ℯ𝒢𝓇 and 𝕯𝕽𝕰𝕬𝕯... [15:07:43] I nuked the commons index that failed last night, and a year-old wikidata index [15:09:10] inflatador: yes these should be the same value, the one in prometheus via "flink_jobmanager_job_uptime" comes directly from the flink job being polled by prometheus [15:11:13] :) [15:14:29] dcausse cool, thanks! I wonder if it would be worth it to relabel to something less generic [15:14:43] inflatador: what do you mean? [15:16:20] Like, it we could relabel "job.Name" to "flinkdeployment.job.Name" in prometheus...just to make it more obvious where the value comes from. Of course, I might be the only one having this problem ;) [15:17:20] oh you mean the label name of the prometheus metric itself like instead "job_name" have "flink_job_name" or the line? [15:17:24] s/line/like [15:17:58] Yeah, that's what I was thinking...but again, I might be the only one struggling w/this [15:18:01] these label are decided by flink I don't think we can alter them [15:18:49] the metric name is pretty flink specific tho, should always start with "flink" ("flink_jobmanager_job_uptime") [15:19:59] I think you can relabel within prometheus itself...but yeah, the metrics themselves are OK [15:20:47] re job_name and your patch beware that it's not Cirrus_Streaming_Updater and the pod="1" might not be correct, you can use thanos to explore this: [15:20:49] https://thanos.wikimedia.org/graph?g0.expr=flink_jobmanager_job_uptime%7Bkubernetes_namespace%3D%22cirrus-streaming-updater%22%2C%20release%3D%22producer%22%7D&g0.tab=1&g0.stacked=0&g0.range_input=1h&g0.max_source_resolution=0s&g0.deduplicate=1&g0.partial_response=0&g0.store_matches=%5B%5D [15:21:41] cool, thanks for the advice. That should make things much easier [15:22:15] already fixed the job name, will look at the pods [15:23:17] re label name I don't have strong opinions about renaming those if possible but I'm afraid that it might be adding another level of complexity and confusion [15:23:42] Yeah, this could be a one-time problem...will forget about it for now [15:47:32] errand [16:01:43] \o [16:13:21] o/ [16:13:31] dcausse: are you around? I played around with a MWE for the new ES sink to better understand all the parameters and noticed an unexpected effect on checkpoints. [16:15:09] heading to my work-share place, back in ~30 [17:02:09] back [17:15:58] pfischer: I'm around but about to be afk soon to prep my bag [17:17:10] No worries, maybe next week or async [17:17:58] sure [17:53:05] I have a very simple class with two elements and i want to add an equality check. The problem is one of those two elements is a Consumer, a lambda that gets created in a static factory method on the class. Whats best bet for adding equality? I guess i could make actual objects instead of lambdas and get equality that way [17:54:03] Yeah, otherwise that lambda is a black box [17:55:00] ok, sounds reasonable. [17:56:32] Is the factory creating an instance of a FunctionalInterface? Otherwise, you could declare an interface for whatever the factory creates with a default implementation for equals(Object other) but so be on the safe side, you’d also have to provide a default implementation of hashCode() [17:56:50] s/so/to/ [17:57:41] factory is creating a plain pojo object, so i have the equality there. I'm not sure when it breaks down, but i've been using lombok @EqualsAndHashCode where i need equality checks [17:58:09] That should suffice for POJOs [17:58:36] As long as any reference inside the POJOs adheres to the equals/hashcode contract [17:58:42] me realizes he somehow expanded pojo on both sides of the acronym... plain plain old java object object [17:59:19] ok, should be reasonable. Really i only need the equality checks for test cases anyways [17:59:21] It’s truely plain